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