[berkes]

The fact that people keep releasing new bundlers, minifiers, transpilers, package managers and so on, for JavaScript is a loud and clear warning that something is amiss.

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.

[samaltmanfried]

The situation with the tooling constantly changing isn't nearly as bad as the front-end frameworks themselves. I've been updating my knowledge of front-end, and it's an absolute shambles. The official React documentation(https://react.dev/learn/start-a-new-react-project) is telling me that in order to use their framework, I need to use another framework to solve (quote)"common problems such as code-splitting, routing, data fetching, and generating HTML"... At their suggestion I've picked NextJS, which is a "full-stack" React framework. This means that it has its own back-end which does most of the heavy lifting. So not only will our company have a traditional back-end, we'll also have a BFF (another thing the kids nowadays want), and a back-end that is actually our front-end application. At this point I've forgotten what problem we set out to solve.

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.

[meiraleal]

Nextjs is the trojan horse sent to destroy React and it worked

[samaltmanfried]

Is this how other people feel about NextJS? I've been trying to keep an open mind about it, but its entire design seems so antithetical to what I'm trying to accomplish. Is there a better mainstream alternative? From what I've seen NextJS is pretty commonly used.

[meiraleal]

The mainstream alternative is still to not have a "backend-for-the-frontend". If you use something like Rails, django, nodejs, use React connected to them. Or directly to something like supabase. NextJS is the extra complexity nobody needs.

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.

[samaltmanfried]

Thank you for the suggestions. Unfortunately, the only reason I'm writing React at all is because so many companies want React experience, and I figure I'd better stay up to date. If I was given the opportunity to choose technologies for myself all of the time, I'd steer clear of React at this point!

[anonzzzies]

Yep, it’s terrible and everyone is going for it.

[aaaaaaabbbbbb]

Next.js et al. provides a set of opinionated packages designed to enable a specific paradigm. For Next.js, that's server-side rendering. For Remix, that's progressive enhancement.

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.

[pjmlp]

Definitely, otherwise Netscape LiveWire would have been a huge commercial success.

[goosejuice]

I believe we see such diversity because of the unique environment in which JS has come to exist. Folks who are writing all these tools are trying too solve problems from the outside in for their small corner of an incredibly large ecosystem.

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.

[dgb23]

Esbuild did solve a major problem, which was very slow builds.

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.

[berkes]

> 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".