3 ms·
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
by sametmax 9y ago
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.
- megous 9y agoProgramming 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.
- forgottenpass 9y agoJust by making a function you're not creating a library. Have you seen what passes for a library on npm?
- megous 9y agoGood point. :D
- sametmax 9y ago> it may be enough to extend the HTMLElement prototype a bit You lost me here. Anybody extending standard objects cannot be taken seriously.
- megous 9y agoDo 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.
- jamiepenney 9y agoWe'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.
- megous 9y agoWhat 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.
- ehsanu1 9y agoApplications may be able to do this in a controlled manner. Library authors never should.
- inimino 9y agoNo, a polyfill is not a library. It's a dozen lines, not a thousand.
- dragonwriter 9y ago> 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.
- AstralStorm 9y agoSome people are mistaking a book (actually a module) for a library.
- inimino 9y agoOverly-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.
- deleted 9y ago[deleted]
- shakna 9y ago> 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.