5 ms·

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 iss

by nox101 2y ago

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

syx 2y ago
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.
johnchristopher 2y ago
Can't linting just be disabled ?
- burnished 2y ago
  I think that is one of the steps towards tacitly admitting the project is no longer maintained/maintainable
  - johnchristopher 2y ago
    My bad, I was tired and somehow thought of linting as "make that code pretty", not bug reporting.
heavyset_go 2y ago
I've been passing on clients' projects that use old versions of React/Node/etc. Maybe someone enjoys fixing breaking changes in layers of dependencies, but it isn't me.
simonw 2y ago
This is one of the reasons all of the little tools I've been building on https://tools.simonwillison.net/ 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.
- pdfernhout 2y ago
  Thanks for all the neat tools! I find Mithril simple enough to be low maintenance for Single Page Applications. We still use a version one of it on a project launched about ten years ago -- although I use version two for later things. And you can use it from plain JavaScript with no compile step. https://mithril.js.org https://mithril.js.org I also find Tachyons or similar Atomic CSS libraries to also simplify CSS issues in a more maintainable way -- also with no compile step. From 2017: https://css-tricks.com/growing-popularity-atomic-css/ https://css-tricks.com/growing-popularity-atomic-css/
- didgeoridoo 2y ago
  Hence the old African proverb: if you want to go fast, use a full-stack TypeScript framework with a highly opinionated build pipeline tied almost inextricably to a venture-backed PaaS. If you want to go far, use HTML and JavaScript.
  - anonzzzies 2y ago
    That first part is not fast either. The venture backed paas makes for a lot changes in the software (all those people need to do something right?) which you need to learn. Vanilla JS, CSS, ancient Lisp/PHP/Perl/C etc I am almost always faster with. A tell-tale sign is that even fast moving LLMs have issues keeping up with frameworks; they already changed so when you npx bla@latest create my-coolness, the LLM already is going to do things 'wrong' or different than intended as it simply doesn't know everything change yet again for no reason anyone but the most hardcore devs care about. The rest of us just want to get our work done and have it compile 3 weeks from now still.
shepherdjerred 2y ago
> 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.
- nox101 2y ago
  This has nothing to do with entitlement. Nothing about my post had to do with open source. The same issues apply to proprietary API changes. Further, I maintain 150 open source projects, 20+ of them active. I still take into account that making a change to an API effects every user downstream. You can spin this anyway you want. If you run an project (open or closed) and you make a change the costs 10s of thousands or million of hours of collective work downstream you just effectively burned down X amount of trees, put Y amount of carbon in the atmosphere, made Z number of people work late instead of being with friends and family, etc...
  - shepherdjerred 2y ago
    Your post mentioned five projects all of which are free and open source. You then mentioned that upstream devs should be billed. How can your post be read as anything other than "open source devs should be billed"?
- porridgeraisin 2y ago
  This argument always bothered me. For me, the ethos of open source and free software is altruism. The whole point is that the developers make the software to help users. There's nothing gained by developers thought-endingly stating that the users aren't entitled to anything. On the other hand though, it's not like users are saints either (for example, vanishingly few donate to the developers of the software they use) so it's a bit of a race to the bottom overall and I understand such sentiment.
  - 2y ago
jasfi 2y ago
This is the sort of thing that LLMs should excel at. An AI coding assistant should theoretically help you move through these issues very quickly.
- nox101 2y ago
  The LLM will just go in circles. ME: Where do I start? LLM: upgrade library X to v123 Me: Library Y complains it need v120 LLM: downgrade to V120 Me: I thought we were upgrading? LLM: upgrade Library X to v123 Me: You're repeating LLM: Sorry I couldn't help you I'm only an LLM
gr4vityWall 2y ago
I wonder what was the reasoning behind the last eslint update.

by nox101 2y ago

syx 2y ago

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.

johnchristopher 2y ago

Can't linting just be disabled ?

burnished 2y ago
I think that is one of the steps towards tacitly admitting the project is no longer maintained/maintainable
- johnchristopher 2y ago
  My bad, I was tired and somehow thought of linting as "make that code pretty", not bug reporting.

heavyset_go 2y ago

I've been passing on clients' projects that use old versions of React/Node/etc. Maybe someone enjoys fixing breaking changes in layers of dependencies, but it isn't me.

simonw 2y ago

This is one of the reasons all of the little tools I've been building on https://tools.simonwillison.net/ 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.

pdfernhout 2y ago
Thanks for all the neat tools! I find Mithril simple enough to be low maintenance for Single Page Applications. We still use a version one of it on a project launched about ten years ago -- although I use version two for later things. And you can use it from plain JavaScript with no compile step. https://mithril.js.org https://mithril.js.org I also find Tachyons or similar Atomic CSS libraries to also simplify CSS issues in a more maintainable way -- also with no compile step. From 2017: https://css-tricks.com/growing-popularity-atomic-css/ https://css-tricks.com/growing-popularity-atomic-css/
didgeoridoo 2y ago
Hence the old African proverb: if you want to go fast, use a full-stack TypeScript framework with a highly opinionated build pipeline tied almost inextricably to a venture-backed PaaS. If you want to go far, use HTML and JavaScript.
- anonzzzies 2y ago
  That first part is not fast either. The venture backed paas makes for a lot changes in the software (all those people need to do something right?) which you need to learn. Vanilla JS, CSS, ancient Lisp/PHP/Perl/C etc I am almost always faster with. A tell-tale sign is that even fast moving LLMs have issues keeping up with frameworks; they already changed so when you npx bla@latest create my-coolness, the LLM already is going to do things 'wrong' or different than intended as it simply doesn't know everything change yet again for no reason anyone but the most hardcore devs care about. The rest of us just want to get our work done and have it compile 3 weeks from now still.

shepherdjerred 2y ago

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

nox101 2y ago
This has nothing to do with entitlement. Nothing about my post had to do with open source. The same issues apply to proprietary API changes. Further, I maintain 150 open source projects, 20+ of them active. I still take into account that making a change to an API effects every user downstream. You can spin this anyway you want. If you run an project (open or closed) and you make a change the costs 10s of thousands or million of hours of collective work downstream you just effectively burned down X amount of trees, put Y amount of carbon in the atmosphere, made Z number of people work late instead of being with friends and family, etc...
- shepherdjerred 2y ago
  Your post mentioned five projects all of which are free and open source. You then mentioned that upstream devs should be billed. How can your post be read as anything other than "open source devs should be billed"?
porridgeraisin 2y ago
This argument always bothered me. For me, the ethos of open source and free software is altruism. The whole point is that the developers make the software to help users. There's nothing gained by developers thought-endingly stating that the users aren't entitled to anything. On the other hand though, it's not like users are saints either (for example, vanishingly few donate to the developers of the software they use) so it's a bit of a race to the bottom overall and I understand such sentiment.
- 2y ago

jasfi 2y ago

This is the sort of thing that LLMs should excel at. An AI coding assistant should theoretically help you move through these issues very quickly.

nox101 2y ago
The LLM will just go in circles. ME: Where do I start? LLM: upgrade library X to v123 Me: Library Y complains it need v120 LLM: downgrade to V120 Me: I thought we were upgrading? LLM: upgrade Library X to v123 Me: You're repeating LLM: Sorry I couldn't help you I'm only an LLM

gr4vityWall 2y ago

I wonder what was the reasoning behind the last eslint update.