3 ms·

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

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.

holoduke 3y ago
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.
- egeozcan 3y ago
  Let me introduce you to JSF and the magic templates. Not all old code is equal, and not all JS-heavy projects are bloated.
hu3 3y ago
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.
- nextworddev 3y ago
  It’s like dealing with the old Angular 1 and Meteor projects from 2015
  - egeozcan 3y ago
    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.
    - nextworddev 3y ago
      JqueryUI… that’s a blast from the past. I’m guessing it’s still used out there.
      - egeozcan 3y ago
        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).
    - neonsunset 3y ago
      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.
- deleted 3y ago
  [deleted]
- rezonant 3y ago
  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.
- Xeronate 3y ago
  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.
  - bornfreddy 3y ago
    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.
spookie 3y ago
I've worked on one last year. A JS developer was surprised at how fast everything was.
dakiol 3y ago
> 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.

holoduke 3y ago

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.

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

hu3 3y ago

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.

nextworddev 3y ago
It’s like dealing with the old Angular 1 and Meteor projects from 2015
- egeozcan 3y ago
  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.
  - nextworddev 3y ago
    JqueryUI… that’s a blast from the past. I’m guessing it’s still used out there.
    - egeozcan 3y ago
      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).
  - neonsunset 3y ago
    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.
deleted 3y ago
[deleted]
rezonant 3y ago
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.
Xeronate 3y ago
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.
- bornfreddy 3y ago
  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.

spookie 3y ago

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

dakiol 3y ago

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