Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

Who here wants to work on a minimally-maintained PHP project from 2011?

Nobody?

In 10 years from now, this JavaScript crap will be just like that PHP project is perceived today. Except it will be much worse, because the PHP project didn’t have dependency hell like this. At least the PHP project wasn’t also your phone app.

View on HN

The future is already here. As a tech lead, consulting for one of my clients, I have to oversee the maintenance of three JS-heavy projects (backend too) that are imploding under their own weight of technical debt. And a good part of that are dependencies.

It’s like dealing with the old Angular 1 and Meteor projects from 2015

Those are actually easy. The ones using the first versions of React with custom state management and weird conventions however, are a different story.

Those, and debugging jQuery UI problems.

I digress but in my career of using every technology possible, the pain I had debugging a huge (HUGE) jQuery UI project could perhaps only be matched by trying to make NHibernate (Hibernate ORM but for .NET) behave in some complicated (but CRUD after all) data-heavy projects.

JqueryUI… that’s a blast from the past. I’m guessing it’s still used out there.

Yes. Perhaps not in the public web but there are so many internal tools using it. It has a lot of issues but the average jQuery UI project is so old that some users will actually complain if you fix bugs because it breaks their workflow (speaking from personal experience)(there was an xkcd for this I think).

NHibernate, the codebase must have been ancient. What is surprising it is still actively being maintained but the documentation examples look just as old and alien.

For a long time I worked at a client driven development shop, and we picked up lots of codebases from other developers. There were apps in PHP, Java, .NET. All of them were buried in technical debt. You can take any programming language and build a project buried in technical debt.

What is the alternative to dependencies if you are making a highly interactive web app? Large/old apps being a pain to maintain isn't something unique to javascript.

The same as in other languages. Avoid dependencies whenever you can, and only add them when really needed. And only if you are fairly certain that the dependency a) will still be there in a few years time and b) developers take backwards compatibility seriously.

> Who here wants to work on a minimally-maintained PHP project from 2011?

In a more serious note: I don't think the language matters that much when working in legacy codebases. What matters the most is the (usually undocumented) business logic that one needs to decipher based on the code. I'll take any day of the week a documented PHP project from 2011 than any Go/Rust/TS/Kotlin undocumented project of 2024.

I like to work on old legacy systems from the 00s. They are all relatively simple without too many dependancies. Code is often spaghetti, but its often also not having 20 layers of abstraction. Nowadays code is so damn abstract with layers of enheritance, delegates, messaging etc. Very difficult to understand apart from the makers. Give me old code. I like it.

Let me introduce you to JSF and the magic templates. Not all old code is equal, and not all JS-heavy projects are bloated.

I've worked on one last year. A JS developer was surprised at how fast everything was.

Reply on news.ycombinator.com