Well, that's just moving the goal posts. I never said you wouldn't have to do any maintenance at all, just that the floor doesn't just fall from under everyone every 5 years. Even outside of frontend, most ecosystems move fast enough that projects from 10 years ago would be in pretty bad shape. That's long enough that even many C/C++ projects will not compile, if nothing else, as a result of improvements to compilers.
As far as a React program from 2015, the maintenance required to get it working in modern React probably wouldn't be all that bad. The biggest transition in React's existence was the move from createClass to ECMAScript 2015 classes. React predates the existence of ECMAScript 2015 classes, having been released in 2013, but once they were available React 13 (2015) they were pretty quickly adopted for reasons obvious. So I'd expect a project from 10 years ago to probably still be using ECMAScript 2015 classes. If not, that transition is mostly mechanical. Definitely a few other potential compatibility breaks over the years, but they're all documented. None of them are going to require a full application rewrite.
Can you build a project from 10 years ago, using 10 year old React? Well, yeah, if you want to. You'll need to use an old version of Node.js most likely, but npm still has all of the old packages.
I don't think it's moving the goal posts. It's a very reasonable thing to ask. I have Go projects that are now 10 years old that require zero maintenance on my part.
I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react.
Sure if you were using just react that is okay, but how many frontend projects are JUST using react? The issue with react has always been the community surrounding it. Library recommendations that use to be "best practices" get churned into the next thing marketers want to push.
It's very wasteful in our community because we are just tilting at windmills rather than focusing on the harder problems we have to collectively sell. We should start shunning tools that enable this churn, not all frontend communities are like this either but the popular ones seem to be.
I don't really disagree that there is a lot of churn in frontend, but a lot of that comes down to simply picking up too many dependencies, a problem that isn't really that hard to avoid by simply not doing that. I have indeed had large projects where the list of direct dependencies was about a dozen, because if you are more judicious about dependencies, it's not so bad.
Go is a great example. Once Go hit 1.0, it gained very strong compatibility guarantees. Go has two properties that make it much better in terms of ecosystem stability than JS was:
- The Go standard library. For a long time JS lacked very basic functionality in its standard library. Go has a very nice standard library that not only covers essential algorithms and data structures, but also standard I/O interfaces, implementations of popular protocols and file formats, and a full cryptography suite. 10 years ago, JavaScript lacked much of this, so you often had to "roll your own". Today JS has standard modules, WebCrypto, the File System API, IndexedDB, bigint, ES Maps and Sets, and more. The problem is much alleviated.
- Go has an ethos of minimal dependencies, a la the famous Go proverb, "A little copying is better than a little dependency." JavaScript had virtually the opposite attitude; they were pushing for making every small thing a module. This was a terrible idea, and it has led to the unfortunate reality that your dependency trees in Node.JS grow uncontrollably. This has been somewhat alleviated, though there are still many projects with out-of-control module trees.
Mind you also, that React prior to v15 was also considered pre-1.0; the last relatively big transition (to ES classes) happened in v13, which was actually v0.13 at the time.
But come on. The quote I took issue with was:
> Whatever framework you choose will be obsolete in 5 years.
This is an exaggeration. Undoutedly the JS ecosystem is not as stable as the Go one, but I don't think dropping all frameworks because the ecosystem moves kind of fast is the right answer. There's a measure in the middle.
As far as a React program from 2015, the maintenance required to get it working in modern React probably wouldn't be all that bad. The biggest transition in React's existence was the move from createClass to ECMAScript 2015 classes. React predates the existence of ECMAScript 2015 classes, having been released in 2013, but once they were available React 13 (2015) they were pretty quickly adopted for reasons obvious. So I'd expect a project from 10 years ago to probably still be using ECMAScript 2015 classes. If not, that transition is mostly mechanical. Definitely a few other potential compatibility breaks over the years, but they're all documented. None of them are going to require a full application rewrite.
Can you build a project from 10 years ago, using 10 year old React? Well, yeah, if you want to. You'll need to use an old version of Node.js most likely, but npm still has all of the old packages.