> 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.
Author here, thank you for reading the article and taking the time to comment.
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".
You have to be the most sensible programmer I've run into here. If I could plus one a single section of your post it would be the "Good software is <bullets> none of which depends on the language". Had me nodding excitedly in agreement, subduing the urge to shout YES at my screen.
> 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.
This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.
I think Java and C# are indeed my favorite languages for huge projects with wildly varying developer competence. Python is probably my most hated for that situation.
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.
That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain.
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.
What websites are you working on that have 10+ people? In my nearly 25 years working as a web developer, I don't think I've ever worked with more than three other developers at one time.
Over 10 people worked on the solution for utility meter readings in the Netherlands. All PhP, MYSQL and jQuery. Over 80% of the utility companies were served through this platform.
Everything you say is well and good, but the businesses with the legacy codebase (PHP or Javascript) are still trying to pay someone to work on their systems, and quite frankly, their money is the same shade of green.
That's actually not my experience. I pretty much always had complete technical freedom when brought in as a freelance on e-commerce PHP applications. As long as it enables the business, they let the nerd do the gobbledigook.
If there is no pre-existing test suite, it is extremely difficult to know what is the right expected behavior that should be tested, and what is incidental to the implementation.
Hopefully there is a product team or actual internal users you can interface with to know the expected behavior. I'd expect to at least be able to write some integration-style tests that can ensure everything works from the user's perspective.
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!
Defining big obvious functionality is usually easy to get from people. It's all the finer details that people might not know. You might have a feature that's been relatively untouched for a while, but people still use, so the devs have either left or forgotten from their past "drive-by development".
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.
hella legacy js and php is the opposite of intertwined by it's very nature. every page is isolated. one php file per page. probably some inline js script tags. easy refactor.
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.