this!!! I have a site I personally use daily. it's using react 17 and is built with node 16. upgrading either breaks it and I don't have the
time to fix the issues. It's got 3 components that break as well. And the CRA build script breaks if you update it as well.
I've spent several hours trying 3 different times to upgrade it but I run out of time and give up. So I limp along with tiny changes now and then. I don't know at what point it will become unmaintainable
I have a similar problem with an electron app. it's super frustrating.
I kind of wish the upstream devs got billed for all the extra work they cause. Then maybe they'll take the pain they create a little more seriously.
The latest is eslint which recently broke everything and now 15 or so projects I run will need several hours of maintenance each. work I'd like to put into new features but instead I have to waste on refactoring configuration
This is one of the reasons all of the little tools I've been building on https://tools.simonwillison.net/ are Vanilla JavaScript, no React or anything that needs a build tool and only using dependencies if they can't be skipped.
I'm a server-side developer by trade, but there's something REALLY neat about being able to build a useful interactive thing as static HTML+JavaScript and know that it will effectively never stop working and is entirely self-contained.
I’m having the same issue as you but for a React 16 Node 12 web app. Building it was great and good fun but after neglecting updating the dependencies it has become almost impossible to upgrade after 5 years.
I really wish developer put more effort into developing web tech that would last more in time.
> I kind of wish the upstream devs got billed for all the extra work they cause.
This is actually very easy to do!
Surely you’re already donating generous sums to these open source projects - you can simply let them know you’ll reduce your contribution until the problem is fixed.
This is a snarky reply and I’m sorry for that, but seriously why do you feel entitled to anything? Receiving any free software in the first place is more than sufficient.
My first decade of software development was on the Flash platform. Don't get me started. When I began building what I considered "Flash-caliber" HTML+CSS+JS things in 2015, I knew to avoid everything that wasn't TIG-welded to Firefox, Webkit and Chromium. I'm reluctant even about using three.js and regl instead of rolling my own little bit of WebGL.
Docker, React and TypeScript pay my bills. But they will rip away from the world, along with everything built on top of them, as soon as discourse around WASM gels into a sexy low-sodium panacea with a meaningless two-syllable name. Web devs guzzled kool-aid before and they will again, and like hell will I toss any personal code in with it.
I've spun up an old ubuntu laptop recently for.. reasons. I think the last time that machine was in use was in the late 2000s. Poking around on it, I was blown away how simple and resilient the infrastructure of some of my old projects was. Things just build, things just work -- after over a decade of being mothballed.
Did the projects work in just the laptops? Or did they work elsewhere also? I think its fairly easy for existing old projects to work, as long as the hardware it lived in is easily replicated. Not so if you have to port it to modern hardware
Nix is a possible solution to stack rot (at least in the realm of "things breaking against each other", not "things that had critical bugs or security holes discovered later")
Yeah, I've had this happen to me. I wrote a directory in cakephp and neglected to update it. Eventually the ROI to me of updating it wasn't worth the hassle.
The one exception is if you outsource the stack updating. For example, https://letterstoanewdeveloper.com/ runs on wordpress.com. In this case, I don't have to worry about stackrot, I just have to pay the bill. If/when the bill becomes too much, then I'll convert it to HTML and host it somewhere. (And yes, if I'd done it as HTML first, I wouldn't have to make the effort.)
WordPress might indeed be a good choice for a CMS.
How well does self-hosted WordPress (without plugins) behave when updating? I would think that even major releases can be updated with a simple click and don't break anything?
This is a problem for any project, and yet another reason to prefer static files for as much as your stack as possible and do not follow the latest tech-stack trends too closely. It is called the bleeding edge because it is covered in the blood of dead projects that cannot be maintained.
My advice is to use as few technologies in your stack as possible. Sure, your project might work best with a relational db and a dedicated document store but it might be less ongoing effort to emulate one with the other.
And freeze (or at least document) the versions of any dependencies for release. Your project runs fine with CoolTech.1.4 now but in 5 years when you come to rebuild you will find that the interface to CoolTech.6.44 is completely different.
And even then things might fail. 20+ years ago I made some Java applets that were well received and useful. Technically they still work (I think) but nobody runs Java in the browser so those projects have been unusable for years. We can be smug about our pure HTML5 static sites now but who knows what the browser landscape will be like in 2050.
> Pure HTML probably has the best chance of surviving.
If you took that thought seriously you'd do HTML3 with nested tables and font tags, that stuff is going to last forever. But HN fashion says Javascript bad CSS good.
Regarding them java applets, it seems it's possible to make them run using webassembly or a "google web toolkit" (what the fabulous https://github.com/pfalstad/circuitjs1 simulator uses)..
This happens to every developer once we get over like 20yrs experience doing side projects. Invariably the dependencies and technologies of any app become obsolete over time, and you either do a massive rewrite or else give it up.
I've always had one primary side project of my own that's consumed 95% of all my time over the years, and so I've rewritten it from scratch at least 5 times as technologies (libraries, databases, languages, etc) have evolved. Not many people are lucky enough to love one app so much you'll do this, so your other side projects just die off, because they're not worth a rewrite.
Adjacent points: I also think that selecting mature projects for your dependencies matters significantly. My old couchdb or early node work is generally defunct. On the other hand, I have some dotnet projects that are still functional with zero updates from a decade or more ago.
Additionally, it's reasonable to keep a copy of your dependencies somewhere in case the vendor dies, the licensing changes, or something else catastrophic happens. Even if you just image dev's machines when they offboard. There have been a few times this has prevented permanent project death or rewrite emergencies for me.
I have more than 50 projects and find myself often bogged down by fixes and updates. This can creep up on you. Going back to older code bases (even ones you
wrote) can be daunting and annoying. One customer email can ruin the whole day. AI has definitely made this easier but it's still challenging.
I've now started to be more ruthless in cutting older projects that aren't going anywhere (or are not 100% automated) and I also try and consolidate new project ideas as a features to existing products.
One of my production web-based projects managing critical transit data hit the 12 year mark. It was based on straight HTML/CSS, plain Javascript, Knockout.js (yeah, this was before ReactJS and friends), JQuery, Bootstrap CSS, and with a Play Java backend on Centos Linux against a Oracle 11 DB. It needed minimal maintenance and updates, only when the spec versions changed. It has reached its end of rope when it failed the new security audit in that the software versions being too old, i.e. Oracle, Linux and JDK being too old. The customer comes up with the funding to do a rewrite rather than spending the money in retrofitting the old code. You bet one of the main goals of the new tech stack is reducing 3rd party dependencies and choosing dependencies carefully.
That's one of the reasons I'm starting to move away from JS on the server and instead use dotnet. It's super mature and you can build something with close to zero deps. You can be certain it will still be there 10 years from now. The performance (7-10x better than JS) is the cherry on top.
Still haven't figured out which would be a good long term solution for frontend. For the moment I'll keep using Svelte which I really like but I have doubts about it's longevity.
Readit News
Keep your stack flat.
Most projects of my web developer friends died after months or a few years. None survived for decades. And the reason was always stack rot.
Multiple parts of their stack became outdated and so hard to update that they quit.
I've spent several hours trying 3 different times to upgrade it but I run out of time and give up. So I limp along with tiny changes now and then. I don't know at what point it will become unmaintainable
I have a similar problem with an electron app. it's super frustrating.
I kind of wish the upstream devs got billed for all the extra work they cause. Then maybe they'll take the pain they create a little more seriously.
The latest is eslint which recently broke everything and now 15 or so projects I run will need several hours of maintenance each. work I'd like to put into new features but instead I have to waste on refactoring configuration
I'm a server-side developer by trade, but there's something REALLY neat about being able to build a useful interactive thing as static HTML+JavaScript and know that it will effectively never stop working and is entirely self-contained.
Maybe someone enjoys fixing breaking changes in layers of dependencies, but it isn't me.
This is actually very easy to do!
Surely you’re already donating generous sums to these open source projects - you can simply let them know you’ll reduce your contribution until the problem is fixed.
This is a snarky reply and I’m sorry for that, but seriously why do you feel entitled to anything? Receiving any free software in the first place is more than sufficient.
My first decade of software development was on the Flash platform. Don't get me started. When I began building what I considered "Flash-caliber" HTML+CSS+JS things in 2015, I knew to avoid everything that wasn't TIG-welded to Firefox, Webkit and Chromium. I'm reluctant even about using three.js and regl instead of rolling my own little bit of WebGL.
Docker, React and TypeScript pay my bills. But they will rip away from the world, along with everything built on top of them, as soon as discourse around WASM gels into a sexy low-sodium panacea with a meaningless two-syllable name. Web devs guzzled kool-aid before and they will again, and like hell will I toss any personal code in with it.
For a large project (with years of manpower baked in) I would expect about a day of maintenance work per year. Assuming you have good test coverage.
The one exception is if you outsource the stack updating. For example, https://letterstoanewdeveloper.com/ runs on wordpress.com. In this case, I don't have to worry about stackrot, I just have to pay the bill. If/when the bill becomes too much, then I'll convert it to HTML and host it somewhere. (And yes, if I'd done it as HTML first, I wouldn't have to make the effort.)
How well does self-hosted WordPress (without plugins) behave when updating? I would think that even major releases can be updated with a simple click and don't break anything?
Some pages still use JQuery, but I wouldn't use it in new projects. Browsers are a joy to work with these days, no more need for any libraries.
My advice is to use as few technologies in your stack as possible. Sure, your project might work best with a relational db and a dedicated document store but it might be less ongoing effort to emulate one with the other.
And freeze (or at least document) the versions of any dependencies for release. Your project runs fine with CoolTech.1.4 now but in 5 years when you come to rebuild you will find that the interface to CoolTech.6.44 is completely different.
And even then things might fail. 20+ years ago I made some Java applets that were well received and useful. Technically they still work (I think) but nobody runs Java in the browser so those projects have been unusable for years. We can be smug about our pure HTML5 static sites now but who knows what the browser landscape will be like in 2050.
Pure HTML probably has the best chance of surviving.
If you took that thought seriously you'd do HTML3 with nested tables and font tags, that stuff is going to last forever. But HN fashion says Javascript bad CSS good.
I've always had one primary side project of my own that's consumed 95% of all my time over the years, and so I've rewritten it from scratch at least 5 times as technologies (libraries, databases, languages, etc) have evolved. Not many people are lucky enough to love one app so much you'll do this, so your other side projects just die off, because they're not worth a rewrite.
Adjacent points: I also think that selecting mature projects for your dependencies matters significantly. My old couchdb or early node work is generally defunct. On the other hand, I have some dotnet projects that are still functional with zero updates from a decade or more ago.
Additionally, it's reasonable to keep a copy of your dependencies somewhere in case the vendor dies, the licensing changes, or something else catastrophic happens. Even if you just image dev's machines when they offboard. There have been a few times this has prevented permanent project death or rewrite emergencies for me.
I've now started to be more ruthless in cutting older projects that aren't going anywhere (or are not 100% automated) and I also try and consolidate new project ideas as a features to existing products.
Still its hard and everything is a balance. Some of my projects in case anyone's interested: https://www.hackyexperiments.com
Still haven't figured out which would be a good long term solution for frontend. For the moment I'll keep using Svelte which I really like but I have doubts about it's longevity.
Deleted Comment