Every legacy codebase I have worked with was actually a successful business. That probably plays a big role in why I enjoy working with them. The job is not easy, and in one case (800kLOC of PHP without a single function), I had to rewrite everything from scratch.
Legacy JS with its strata upon strata of framework du jour and jquery and porous language are indeed notoriously annoying. To be fair, I just isolate the legacy JS to its own little DOM sections, and then introduce a new framework in parallel until I can nuke the old code out.
Revamping a legacy JS codebase often comes with a design revamp as well, so it often becomes a matter of strangling [1] out the old API. I do really enjoy how typescript allows me to gradually introduce typing and leverage static analysis for more adventurous refactoring.
I use golang, rust and typescript as my daily drivers lately, but I must admit that my most horrendous legacy codebase experience was a tiny 20kLOC go program that was just a mess of concurrency nonsense. PHP codebases have a certain "flatten it out and don't be clever" style to them that make for easy strangling [1]. Highly abstracted codebases where the abstraction doesn't fit the use case anymore, or the abstraction was thoroughly eroded by generations of misinformed developers are much trickier.
What language I would use to greenfield a new application would depend highly on the experience of the team, but my usual approach is "whatever we are already using".
[1]: https://www.redhat.com/architect/pros-and-cons-strangler-arc....
This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.
Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.
Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4.
Also, not just vulnerabilities. Bugs, whatever.
Wouldn't you just... make a test suite?
If you're so disconnected that you don't know the user's perspective or have no way to see the program in action, then ..best of luck!
Legacy code bases are more often that not huge monstrosities. Maybe you do start with some tests and increment, but there's no "just" involved.
I tried adding tests to a legacy AngularJS application (it was in the process of being phased out but was still business critical). I sunk days into trying to get a test to run, let alone pass, before giving up and deciding that eventual replacement was going to be quicker than finding good AngularJS documentation.
Not sure if sarcasm or serious.
and if they're actually using frameworks and libraries.. well that's just being a good programmer. if you don't know how it works, leave it alone and go rewrite a piece that doesn't require rewriting something core
> A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements.
Wow. This person must have worked on very different legacy codebases than me.
Legacy Javascript code, to me, is something that I do not want to touch with a 10 foot pole, because every little piece of it can be intertwined with and used by many other hidden places. Plus, I've never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify.
From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point.
Maybe if your target audience is genuinely 10 year olds learning to code, fine. But also if you're building a serious product for a company, please don't choose a "Janky programming language" because I really don't want to have to debug it after you left before really thinking about sanitizing user input.
I feel like, in the hands of a really talented programmer, they can be super productive in PHP or Javascript or really anything. But I've just had a lot of bad experiences with quickly written, undocumented code.