Hacker News Reader

Comment by nox101 | Hacker News Reader

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

View on HN

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.

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

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/

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.

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.

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.

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.

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

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"?

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.

Maybe I'm cynical, but after 30 years in the open-source community, I think the true ethos of open-source is self-interest, and the disregard open-source maintainers feel for their users reflects this.

The point of free software is to allow users to have control over the software they use. There's no inherent connection to altruism, though that is part of why I open source the code that I can.

Plenty of individuals and companies release open source software that requires payment.

https://www.gnu.org/philosophy/free-sw.en.html

Anyway, I feel this is all tangential. My issue was mostly that the parent comment suggested that open source devs be billed for changing the software they create.

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.

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

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

Can't linting just be disabled ?

I think that is one of the steps towards tacitly admitting the project is no longer maintained/maintainable

My bad, I was tired and somehow thought of linting as "make that code pretty", not bug reporting.

Reply on news.ycombinator.com