Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Polyfill. So new lib.

And even then. You need to encode params manually.

And of course no middleware, so for special decoding or repeating headers, you end up writting a wrapper.



Programming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces.

Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does not need to be a interface like jQuery to completely hide DOM API under another interface. It may be enough to extend the HTMLElement prototype a bit or write a function to "compress" the code a bit and make it more readable.


Just by making a function you're not creating a library.

Have you seen what passes for a library on npm?


Good point. :D


> it may be enough to extend the HTMLElement prototype a bit

You lost me here. Anybody extending standard objects cannot be taken seriously.


Do you realize JavaScript is a prototype based programming language? It is a major and very useful feature of the language. There's no reason not to use it. There are some things to be careful about with interop if you need it, but that's it.


We've already learned from our past mistakes changing the prototype of the standard library - the Ruby community learned the same thing with monkey patching their standard lib too. The maintenance overhead far outweighs any immediate benefits.


What maintenance overhead? Current and future costs are reduced by making code simpler and cleaner in the first place by using prototypes efficiently.

Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.


Applications may be able to do this in a controlled manner. Library authors never should.


> Polyfill. So new lib.

So, you don't like the polyfill, created to the specification. Fine, but depending who you target, you might not need it. Plenty of modern browsers have good support.

> And even then. You need to encode params manually.

Or use the Request constructor.

> And of course no middleware, so for special decoding or repeating headers, you end up writing a wrapper.

Request constructor will let you handle the headers quite nicely.


No, a polyfill is not a library. It's a dozen lines, not a thousand.


> No, a polyfill is not a library

Yes, it is.

> It's a dozen lines, not a thousand

A polyfill can be any size, but there's no size minimum to be a library.


Overly-literal response.

A polyfill is a short snippet to implement a missing feature. Notably almost all recent additions to JS and DOM have been designed to be polyfillable where possible. Generally that means under a thousand lines, by the way.

A library in this context means a set of functionality built on top of the platform, like jQuery, with its own API, etc. "Use a library" and "use a polyfill" are not the same advice.

A polyfill is not a library.


Some people are mistaking a book (actually a module) for a library.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: