Are you using the same version of React that you started 10 years ago? More importantly can you use the React version that was 10 years ago ? Can you even build a 10 year project ?
At a previous job, the frontend was a ClojureScript codebase dating back to around 2013, with a React-based UI. The codebase survived a decade of major upgrades to ClojureScript and React, and many chunks of code in git blame dated back to 2013 - 2014. For reference, ClojureScript's first public release was in 2011, and the React wrapper the codebase used dates back to December 2013.
I think the strong focus on backwards compatibility is what helped ClojureScript (and CLJS libraries we used) stay largely unchanged, but we had plenty of "React code" that wasn't changed at all between 2013 and 2022 since it met business requirements and "just worked".
Unfortunately, I don't work there anymore, but I don't see why it'd be impossible to build the early version of that frontend today. Recently, I've been using TypeScript for frontend, and the codebase is still surviving major upgrades to React, TypeScript, and the various libraries we use.
However, I will admit that the pace at which libraries release is extremely fast compared to other ecosystems I'm familiar with (Clojure, Java, Rust, etc.).
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.
Webpack existed 10 years ago, and that was after Browserify had already existed for a bit, too. The era of bundling was already in full swing in 2015, and React gained support for ES Classes, too.
React wasn't really terribly usable without bundling. Prior to bundling, there were multiple competing adhoc module systems, but obviously this wasn't fantastic for a variety of reasons. AngularJS 1.0 was great in part because the dependency injection system kind of took care of a lot of trouble; you could have a workflow in Gulp/Grunt concatting your JS together, and the order didn't really matter a ton since dependency injection would largely handle it.
React moved relatively quickly in the first few years, but 10 years ago was already not the very beginning of React. It was starting to mature by that point.
