I work on a large code base that was built in .NET 4 with a lot of jQuery for the front end. We’re modernizing it, but it’s very slow work. A significant part of the work is improving the organization of scripts, of which there are thousands. We’re not even prioritizing getting rid of jQuery, because it works. To rewrite all the stuff that works, instead of focusing on structural matters, dependency management, maintainability and security, would be insane. (And that’s just the JS bits, on top of which there’s all the legacy .NET stuff to do.) We aim to get it into a state that will leave it working and maintainable in future without excessive effort.
Sometimes I wonder who these people are who always promote this year’s library or framework, then next year promote something newer. Do they work in real companies with real applications under heavy use? Have they ever had to maintain a codebase that was written more than 6 months ago? Or do they just build proofs of concept and small apps and pontificate a lot, then move on to the next job before things get serious?
We did a full rewrite of our site years ago going from backbone to react and TS. We just did it page by page, clean sweep on each page, all new work done on a fresh slate with the old code base being abandoned page by page but otherwise left alone until all the pages were migrated at which point we could just completely drop the old code base. We’re so much more productive now and happy working on the code base. Refactors are much easier than before as well.
I’ve worked on massive jQuery code bases before and they turn into worthless spaghetti code in no time at all. Dynamically altering html with no source of truth is the worst pattern you could have on a frontend. I have a ton of respect for what the jQuery library introduced but it was never a framework and was used in a terrible patchwork way. I wouldn’t even bother trying to save any of it. Clean split and keep that codebase tightly quarantined behind lock and key and don’t let it even touch the new code base. The spaghetti code it creates is like a virus.
I work on marketing websites which are essentially disposable. So every 3 years you start over from scratch (in a new version of some CMS). So I don’t get to build super cool functionality much, but I do get to work with newer tech stack. (I still don’t need 99.99% of the js frameworks flavors of the week)
That makes sense. If you’re pumping out websites it’s quite a different situation from developing large applications that need to run for many years. Same if you’re developing lots of little apps.
I work on a large code base that was built in .NET 4 with a lot of jQuery for the front end. We’re modernizing it, but it’s very slow work. A significant part of the work is improving the organization of scripts, of which there are thousands. We’re not even prioritizing getting rid of jQuery, because it works. To rewrite all the stuff that works, instead of focusing on structural matters, dependency management, maintainability and security, would be insane. (And that’s just the JS bits, on top of which there’s all the legacy .NET stuff to do.) We aim to get it into a state that will leave it working and maintainable in future without excessive effort.
Sometimes I wonder who these people are who always promote this year’s library or framework, then next year promote something newer. Do they work in real companies with real applications under heavy use? Have they ever had to maintain a codebase that was written more than 6 months ago? Or do they just build proofs of concept and small apps and pontificate a lot, then move on to the next job before things get serious?
We did a full rewrite of our site years ago going from backbone to react and TS. We just did it page by page, clean sweep on each page, all new work done on a fresh slate with the old code base being abandoned page by page but otherwise left alone until all the pages were migrated at which point we could just completely drop the old code base. We’re so much more productive now and happy working on the code base. Refactors are much easier than before as well.
I’ve worked on massive jQuery code bases before and they turn into worthless spaghetti code in no time at all. Dynamically altering html with no source of truth is the worst pattern you could have on a frontend. I have a ton of respect for what the jQuery library introduced but it was never a framework and was used in a terrible patchwork way. I wouldn’t even bother trying to save any of it. Clean split and keep that codebase tightly quarantined behind lock and key and don’t let it even touch the new code base. The spaghetti code it creates is like a virus.
Yeah that would be great to do but we are very underresourced so the technical debt just keeps building up.
I work on marketing websites which are essentially disposable. So every 3 years you start over from scratch (in a new version of some CMS). So I don’t get to build super cool functionality much, but I do get to work with newer tech stack. (I still don’t need 99.99% of the js frameworks flavors of the week)
That makes sense. If you’re pumping out websites it’s quite a different situation from developing large applications that need to run for many years. Same if you’re developing lots of little apps.