Re:Elm at Rakuten
by wk_end on Wednesday August 18, 2021 @04:34PM
(#28226749)
To play Devil's (Elm's?) Advocate here: sometimes I wonder if the TypeScript promise of incrementally adding types to an existing JS code base is wishful thinking.
I'm at a company that's transitioning to TypeScript, and the reality is that you can't just flip a switch and have a well-typed codebase: if we just turn `strict` on, `tsc` gives us thousands and thousands of errors. And as we've gone through trying to annotate things, it's clear that in order to get various components to a state where they're properly type-safe, we'll need to almost completely rewrite them.
Compared to Rakuten, our codebase isn't even that huge or legacy - it's often very poorly written, but it's less than 50K lines and less than a couple of years old. No doubt the situation for Rakuten would be even worse; I'm sure huge swaths of their code would need to be trashed anyway.
If TypeScript is ultimately going to force you to rewrite - and still leave you with a less-robust solution - I could see why starting with a clean-slate with Elm would be appealing.
I'm at a company that's transitioning to TypeScript, and the reality is that you can't just flip a switch and have a well-typed codebase: if we just turn `strict` on, `tsc` gives us thousands and thousands of errors. And as we've gone through trying to annotate things, it's clear that in order to get various components to a state where they're properly type-safe, we'll need to almost completely rewrite them.
Compared to Rakuten, our codebase isn't even that huge or legacy - it's often very poorly written, but it's less than 50K lines and less than a couple of years old. No doubt the situation for Rakuten would be even worse; I'm sure huge swaths of their code would need to be trashed anyway.
If TypeScript is ultimately going to force you to rewrite - and still leave you with a less-robust solution - I could see why starting with a clean-slate with Elm would be appealing.