Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs.
In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest operating functions in libc.
There are a lot of ways for padding a number in JS and a decent dev would keep an own utility library or hell a function to copy-paste for that. But no. npm users are taught to fire and forget, and update everything, no concept of vendoring (that would have made incidents like left-pad, faker and colors less maddening, while vendoring is even bolt in npm and it's very good!). They for years copy-pasted in the wrong window, really, they should copypaste blocks of code and not npm commands. And God helps you if you type out your npm commands because bad actors have bought the trend and made millions of libraries with a hundred different scams waiting for fat fingers.
By understanding that JS in the backend is optimizing for reducing cost whatever the price, becoming Smalltalk for the browser and for PHP devs, you would expect some kind of standard to emerge for having a single way to do routine stuff. Instead in JS-world you get TypeScript, and in a future maybe WASM. JS is just doomed. Like, we are doomed if JS isn't, to be honest.
Current web stack is very complicated, HTML and CSS DOM is a rats nest and that's a superficial example. Adding asynchronous rpc pushes that way over the top. Luckily HTTP has been through the production crucible for 30 years. What I see is not a cost center but a reflection of basic truth:
- UI and data representation is hard.
- Developers use the tools they know about.
But about micro-libraries, the first point isn't very important because this is a social problem. There is no standard library for NPM that does what people need. There should be a curated function library of this crap.
In my imaginary vision there are several, and people would look askance when you don't use one without an obvious reason. I very much sympathize with the desire to burn-it-all, but I like that I can use LetsEncrypt and am cognizant that there is a lot of thought and raw technological progress bound up in all this.
They are not designed for modern use cases and certainly not well-designed according to modern understanding of this word. In fact they did not stood the test of time as something worthy of preservation, they only survived and mutated, because it is extremely hard to replace them.
And of course we should blame the technology: the sole purpose of a standard is to be used by people. If people struggle with it the standard is unfit for its purpose.
You are 100% right but it's no reason to pick on web in particular! When you hit a site, you may have a virtual HTML environment running a JIT virtual machine from a server that's running a virtual python environment on a virtual python environment on a virtual machine on a virtual machine, and all that runs on a virtual x86 processor which in reality is a series of microcode processors. Yes, yes, it would be so much simpler to have your web go straight to the source, microcode, and yes, things would be simple and fast... .. but ... but ABSTRACTION!!!! LETS ABSTRACT EVERYTHING EVER AS MANY TIMES AS POSSIBLE WITH AS MANY ABSTRACTION LAYERS AS POSSIBLE IT GENERALIZES TO THE GENERAL CASE ABSTRACTION GENERALIZES ALL CASES WOOOOWWWW THE COMPUTER SCIENCE OF IT ALL
> And of course we should blame the technology: the sole purpose of a standard is to be used by people. If people struggle with it the standard is unfit for its purpose.
'People' is equivocal here. While complex, and (as you point out, in so many words) an evolved standard, the HTML/CSS/JS stack is arguably one of humanity's greatest achievements, up there with the invention of paper, or perhaps cuneiform.
It's imperfect, like all living standards, but it manages to be ubiquitous, expressive, and _useful_. And for those of us who grew up with these standards, they are second nature.
Like piano, mastering these standards gives you the ability to express complex UI concepts with grace and alacrity.
Don't smash up your parents' piano simply because practicing scales is a chore :)
> Don't smash up your parents' piano simply because practicing scales is a chore :)
I witnessed evolution of UIs from Turbo Vision to modern web and mobile frameworks. My first commercial website went live in 1999. No, UI is not hard and doesn’t require any mastery. As a matter of fact, building decent UI for a client-server application is a simple task with the right tools and processes. Modern Web is not parents‘ piano - you can call it elegant only if you have seen nothing else. It’s a fridge with mostly expired cheap food, from which you have to cook a decent meal for a party. It is possible, no doubt. Without food we will die, so we have to cook it. Instead we could just go shopping.
QUIC is hilarious because they ended up fitting everything and the kitchen sink for any need in the proto, just because 15 years ago firewalls blocked this or that and the reimplementation with websockets of the thing that was blocked runs only in a browser.
First draft of HTTP/3 was called "HTTP/2 Semantics Using The QUIC Transport Protocol". I'm sorry, i should've laid that more shoddily and call that "GoogleHTTP".
I think that it's ugly but okay-ish right now. What is very very bad is the tooling, and someone should remember people that Facebook and Google do things that serves Facebook and Google-scale needs (billions of users, thousands of devs working asynchronously, no time).
What I end up thinking (maybe i'm wrong) is that node.js must be nuked out of backend and on frontend maybe some of the devs should use either a number of libraries under 15 and write custom code for the rest, or use a language that transpiles to JS like TS, flutter, nim, Go or what have you.
Maybe JS should be nuked out of tooling too, sometimes it's actively damaging and sometimes dead slow. Use something else if wrangling asset files are a problem.
If you want a DX where backend is frontend, you must use the only three mantained languages that can do that without trying to actively damage you or users, which are a Smalltalk (like Pharo), a Lisp (like Clojure/Clojurescript) or Java.
I‘d prefer to see a completely new renderer backed by containerized JVM with some DSL for UI as a replacement of modern browsers and application-first encrypted by default binary protocol replacing HTTP (one reference implementation for debugging it would fe fine).
Could you link to somebody who is teaching npm users to "fire and forget?" Someone who is promising a substitute for competence in basic programming theory? Clearly you and I do not consume the same content.
This is just a discourse based on "I need to churn out something, I need that fast and I didn't start in the web game when Backbone and E4X were solid corporate choices". If you are not in a hurry, work in a solid team and have a good attention span, a lot of clickbait idiocy around JS may not happen. It's just that the lone inexperienced guy is one of millions inexperienced guys who are taught the wrong ways everyday.
I'm presenting you one of countless examples: a lot of coding bootcamps teach React, maybe with TS, maybe with JS.
In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest operating functions in libc.
There are a lot of ways for padding a number in JS and a decent dev would keep an own utility library or hell a function to copy-paste for that. But no. npm users are taught to fire and forget, and update everything, no concept of vendoring (that would have made incidents like left-pad, faker and colors less maddening, while vendoring is even bolt in npm and it's very good!). They for years copy-pasted in the wrong window, really, they should copypaste blocks of code and not npm commands. And God helps you if you type out your npm commands because bad actors have bought the trend and made millions of libraries with a hundred different scams waiting for fat fingers.
By understanding that JS in the backend is optimizing for reducing cost whatever the price, becoming Smalltalk for the browser and for PHP devs, you would expect some kind of standard to emerge for having a single way to do routine stuff. Instead in JS-world you get TypeScript, and in a future maybe WASM. JS is just doomed. Like, we are doomed if JS isn't, to be honest.