[kerkeslager]

I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods...

Even a well-maintained project like React can't escape the squalor of its ecosystem.

I don't always have this option, but usually these days I choose vanilla JS, imported with no build system, do as much as I can with Python/Django on the backend, and opt out of the JavaScript ecosystem entirely. I haven't regretted it.

[PaulHoule]

Some of the problem with React and npm is that they are a victim of their own success.

React lets you suck in 80 components from 15 different vendors and it works. NPM lets you suck in more dependencies than many other systems because it deals with diamond dependencies better than other systems [1]

Because you can mix and match so many widget sets no wonder you will have trouble when those widget sets change.

[1] package A can import version B of package C, package D can import version E of package C -- so long as A and D don't exchange objects from package C there is never a problem, even if they do it might work.

[kerkeslager]

The problem is more cultural than technical. JavaScript folks see the ready availability of dependencies as a feature rather than a risk, including the creation of a plethora of micro-dependencies (such as the left pad fiasco).

React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.

You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.

Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.

[incrudible]

> To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility.

That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system - which is still possible with React, but not with Svelte, Vue or Angular.

My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.

[kerkeslager]

I just had a thought and decided to look it up.

This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years."

The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production?

So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.

[incrudible]

You are extrapolating from the past into the future, but a lot has consolidated in the last five years. You used to need babel to use crucial language features that are now supported across the board, at the same time the avalanche of new language features has subsided.

Conditional types (not statements) are not a basic feature.

[kerkeslager]

> You are extrapolating from the past into the future, but a lot has consolidated in the last five years.

I've been writing JavaScript that entire time, and the complete disregard for maintenance has gotten worse, not better.

You seem to be under the impression that because I also write other languages, I haven't been keeping track of what's happening in the JS ecosystem, but you're wrong--I still write JS, because I often don't have any other option.

The fact that I work in other languages means I get to see what I like about better-managed ecosystems. If you're writing JS on both frontend and backend and not using anything else, it's likely that you don't know how bad things are for you because the JS churn has been normalized for you.

[kerkeslager]

> That's a problem with your build system then, not React.

Did you read the sentence that you're "correcting"?

> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.

Your optimism is admirable.

[justinrubek]

If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.

[kerkeslager]

> If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools.

Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.

How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?

[agos]

wait, what package does no longer exist? is it something that has been unpublished from NPM?

[kerkeslager]

https://en.wikipedia.org/wiki/Npm_left-pad_incident

People arguing with me here don't seem to remember this breaking like 1/2 the JS builds in existence for a few days.