> But, as many others have pointed out, if one has to maintain a project over the years, the breaking changes in the language would have caused great bouts of teeth gnashing.
This isn't just a problem for Elm but for front-end development in general. Not so much because of JavaScript the language, but because of the libraries and, to a much lesser extent, the browser APIs.
In the library and framework space many take semver as license to completely rework their APIs with every major version bump because they "got it wrong" last time around. It's pretty infuriating because in most cases whatever benefits the new API offers are generally fairly marginal and not worth the cost of all the reworking that needs to be done.
I'd always rather an API was stable than perfect because, for one thing, you're never going to achieve that perfection you dream of. There will always be some new use case or better conceptualisation that you didn't think of and, really, all you're doing much of the time is thrashing by pursuing this. To me it often seems like immature software engineering.
I haven't written any Java for a very long time, but I know that C# code I wrote back in 2004 targetting .NET 1.1 would still run substantially unmodified today on the latest .NET runtimes[1] - in fact I'm pretty sure some of it is.
[1] Possibly not .NET Core, but certainly the classic runtime.
A fantastic example of this _not_ happening in js libraries though is Plotly.js. It's still on a 1.x release and has maintained backwards compatibility (for the most part) with the original API for _years_.
Full disclosure, I used to work there (specifically, on plotly.js).
Both Plotly.js and KnockoutJS are great examples of stability.
I think KnockoutJS may still the only (formerly) major framework that focussed only on doing data-binding really well without adding in loads of other functionality. As you say, a shame it died out.
Agreed on all points, there is an advantage in using whatever is currently flavour of the month though (more documentation, components, better integration with dev tools and such) but I used KnockoutJS for a couple of years and really liked it, it was a massive upgrade over jquery for a lot of UI stuff and brought some much needed sanity.
These days I use either React or Vue in the same role as the world keeps turning.
It's amazing they are still putting work into it for those people with massive codebases dependent on it though, anyone picking that 7-8 years ago definitely made a good bet.
I haven't written any Java for a very long time, but I know that C# code I wrote back in 2004 targetting .NET 1.1 would still run substantially unmodified today on the latest .NET runtimes[1] - in fact I'm pretty sure some of it is.
Semver is fine it just slightly obscures the fact that sometimes language designers give up and abandon the language but don't want to give up the branding
This isn't just a problem for Elm but for front-end development in general. Not so much because of JavaScript the language, but because of the libraries and, to a much lesser extent, the browser APIs.
In the library and framework space many take semver as license to completely rework their APIs with every major version bump because they "got it wrong" last time around. It's pretty infuriating because in most cases whatever benefits the new API offers are generally fairly marginal and not worth the cost of all the reworking that needs to be done.
I'd always rather an API was stable than perfect because, for one thing, you're never going to achieve that perfection you dream of. There will always be some new use case or better conceptualisation that you didn't think of and, really, all you're doing much of the time is thrashing by pursuing this. To me it often seems like immature software engineering.
I haven't written any Java for a very long time, but I know that C# code I wrote back in 2004 targetting .NET 1.1 would still run substantially unmodified today on the latest .NET runtimes[1] - in fact I'm pretty sure some of it is.
[1] Possibly not .NET Core, but certainly the classic runtime.