> Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib.
Why doesn't fetch and its polyfill cut it?
Why doesn't fetch and its polyfill cut it?
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.
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.
Have you seen what passes for a library on npm?
You lost me here. Anybody extending standard objects cannot be taken seriously.
Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.
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.
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.
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.