3 ms·

From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I

From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.

cardanome 5y ago
TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
- toastal 5y ago
  Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
- leshow 5y ago
  If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
wk_end 5y ago
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.

cardanome 5y ago

TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.

toastal 5y ago
Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
leshow 5y ago
If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.

wk_end 5y ago

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.