Everyone is making the point that using JavaScript on the server was a BIG mistake, with this ongoing rewrites.
We already had our bundlers in Java and .NET land, before nodejs came to be, and life was good.
We already had our bundlers in Java and .NET land, before nodejs came to be, and life was good.
People (re)write such tools either for fun or to solve a problem (or best: both). Apparently after so much re-writes the problems haven't been solved. To me, this indicates fundamental problems. I'm not familiar enough with the ecosystem to know what those would be, let alone how to truly solve them.
But the very fact that we see new builders, transpilers, bundlers every few months is enough to conclude we aren't solving the problems on the correct level or that maybe it cannot be solved at all. Because otherwise one of the many attempts would've solved the problem and "everyone" would be using that.
NextJS' documentation is also *terrible*. This situation is made all the worse by any material online about NextJS that's more than 3 months old being totally inapplicable because the framework changes so often.
It is marketed as the solution to slow starts but React is slow so the solution is terrible over-engineered.
A much better fix is to remove React and use something that is already fast like solidjs or Lit. There are much better UI Kits in Lit that I have seen in React and in the end it is just JS so the same people that can could React, can code Lit and SolidJS.
If you are happy with client-side rendering and do not desire React on the server, there is not a strong reason to use Next.js; it introduces complexity and churn.
It's a snow ball rolling down an infinitely long mountain. I believe this may never settle.
Mainstream browsers have already coalesced on a no build solution but it's profitable, by fame or fortune, to continue building solutions that require bundle and compile steps. Then others use those because off the shelf libs require them and save time and money.
Vite wrapps esbuild. Not sure what it provides itself.
Then there came several specialized (Rust) tools. For the same reason esbuild was made.
I think ultimately they try to solve the same issue:
JS is supposed to be a productivity gain over compiled languages. But with ultra slow builds that goes out of the window.
But what business problem are we solving? Why do we need compiles, transpiles and so, in a dynamic language in the first place¹? And if so, is compiling the right solution to that problem?
My point was mostly to question if we are solving the right problem. And if the direction in which we are solving it, is the right one. After some 20+ years we still haven't converged around a single solution. But instead we keep firing out "new" solutions and solutions to the problems that those solutions then introduce on an almost weekly basis.
To me that shows we are either simply looking in the wrong place, or have a much deeper, fundamental problem that simply cannot be solved. And should probably either stop looking for the solution or just abandon the whole stack.
¹ I'm not looking for an answer to this question. I know several reasons why we build, compile, transpile, minify and whatnot in JS. But all those are also solutions to deeper problems. Problem's that can be solved in several ways, only one of which is "compile pipelines".
Also if it is such a great experience, people wouldn't be rewriting the node ecosystem in Dart, Go and Rust.
In many cases you can achieve the same with a clearer separation, with data driven methods and by generally not running so much JS.
The typical example is input validation. You want immediate feedback on the client, but obviously you validate on the server.
But instead of running literally the same specific code twice, you can use json-schema or your own general data description of what valid input is. You move the specifics from code into data.