Every software ecosystem has its values and culture. With Javascript and NPM, it is a high rate of change. This is good in that it brings improvements. It is bad for those of us who are occasionally front-end developers – we experience a fair amount of work or churn every time we touch a project. The Elm platform is a lot more stable in this regard.
Above all, this continual re-hashing and re-implementing likely indicates the foundation is unstable. There are likely multiple reasons we don’t see this level of churn in the Go and Elm communities – some of it is likely leadership and culture. But I think more than that, this rate of change does not happen because it is unnecessary. The foundation is good.
This appears to mean an imported thing no longer exists. It would be nice if it told me the file and line. Currently, it appears the only way to chase these down is to start at the top of the app, stub out parts until the error goes away, and then drill down until the problem is isolated. It does not take too long to track down, but in this age, I strongly recommended compiled languages – Elm, Svelte, or something. It is much nicer to work on these problems at the compiler level …
Chunking through this – wrote a script to search and replace a lot of the react-bootstrap components that have changed. At one point, I got the following:
This saga’s latest wrinkle is Meteor bundled with MongoDB 6.x. We are currently using the old mgo Mongo driver for our Go code (Mongo has since released its own Go package), and the mgo driver no longer works with MongoDB 6.x. We should have updated the Go code to use the driver a long time ago, but we’ve always had more pressing business problems/features to work on. This illustrates several things:
MongoDB is not concerned about backward compatibility. Their Atlas hosting platform routinely updates versions without concern about whether their customers are ready to update. This forced us off Atlas and we are now self-hosting Mongo, which works better anyway for our needs.
NPM and Mongo ecosystems are tightly coupled. There is only one path forward and that is to keep updating everything.
I will give another example – I’m currently locked to NodeJS v16 on my workstation because (I can’t remember what …) is not compatible with v18.
Other software systems offer different paradigms:
I’ve updated Wordpress on an old server for years where it updated itself – no problems. It recommended updating PHP, but kept working fine and never complained about old versions of MySQL, etc.
SQLite maintains file compatibility for very long periods
The Elm ecosystem is very stable – I think because they got the foundation and architecture right – perfection is reached where there is nothing more to take away.
Go – I’ve never had a problem with backward compatibility with the core language/tools – when a new version comes out I update to the latest on all of my projects and deploy without a thought.
