❤
Our web needs better primitive libraries. We’ve been relying for too long – far too long – on jQuery. Most popular UI components are tied to jQuery, part of a comprehensive framework – and it’s usually hard to extract the component as a standalone library. Nowadays we may not develop as many jQuery plugins as we’ve used to, but the situation is far more severe now.
...
The point in question is that developing a library that specifically targets a framework is a waste of your time, because when you eventually move on to the next framework (this is JavaScript, you will) you’ll kick yourself over tightly coupling the library to the framework.
...
Portability isn’t just a matter of writing vanilla client-side JavaScript libraries. An equivalent case may be made for writing libraries that work well in both Node.js and the browser. Consider async: an amazing piece of software in Node.js, that’s just garbage in the client-side. Granted, it was written well before ES6 modules (or even Browserify) became a thing. A similar story can be told about fast-url-parser, a URL parser which underlies many server-side routers but is insanely large for the client-side. Talking about insane, I’ve used sanitize-html in countless opportunities to sanitize HTML on the server-side, but again – repeat with me:freaking huge for the client-side (depends on htmlparser2).
