That's the reason TypeScript won. It intergrate with existing JavaScript seamlessly.
> Since July 2017, I’ve been leading the frontend rewrite of their flagship product. The codebase was at 16k LoC when I started. Since then, I’ve rewritten the various subsystems at least once (I'm looking at you generic form component). Now we hover around 45k LoC with most of the common SPA structures stabilizing. We are about a third of the way to completion.
I don't know if it's common for rewrites to triple the amount of code while being only 1/3rd complete, but it certainly doesn't feel like "these are the facts I should lead with."
Edit: I read more of the prologue, and it turns out that the initial 16kloc application was not complete.
The comment about 16k -> 45k LoC was to give an idea of how much we had added to the product over the last 10 months.
With Elm, I don't really feel like introducing it to my team before 0.19 hits, because it "feels" like it's around the corner, but it has felt like that for a while.
With Haskell, I'm not entirely happy with GHCJS and the tooling surrounding it. I'm dreaming of the WebGHC[0]/WASM being nicer, if it ever gets done.
I don't exactly know what keeps me off PureScript, perhaps that most frameworks just seem to compile to React, and that the community still hasn't settled on one (at least it seems so from the outside).
Honestly, Miso[1] is the one I feel the most optimistic about atm.
I'd like to point out two things here:
1. There are common library functions that we put in single files. These are imported by a lot of other files. The fact that these incur a large recompile cost is unfortunate and I think it doesn't have to be this way if dependencies were calculated at a more granular level.
2. The far larger implication to compile time becoming exponential is coupling of concerns. This is solely in the developer's responsibility. For a type system that guarantees correctness of code, there is no way around the fact that all affected modules must recompile. eg, if a fundamental law of physics were to change, the whole universe would have to recompute.
So I think for a 'substantial group of developers', the focus should be on helping people to recognise what is coupling and how to design de-coupled systems.
As far as Scala goes, Grzegorz Kossakowski has done work trying to get major performance improvements out of Scala type checking, and his numbers look very promising. Barring some Shapeless-style type level computations, Scala could compile quite fast.
I would be of the opinion that it is faster because if static compilation was a free lunch there would be no question
I definitely move faster in decent statically typed languages, but I did invest time in learning.
Also, some apps are just very difficult to code in Elm (interactive, lots of DOM manipulations, video, etc) and it's just not worth it.
The fixes need to be in the compiler & dev tools itself, or it needs to be a very obscure feature or obviously surfaced build time problem highlighted by the compiler.
> the technical trials and tribulations he faced, the euphoric and … not so euphoric bits of writing a SPA in Elm
What trials and tribulations did you picture that came with writing a single page application in an email client?
Seems like at least a few others have over time as well
It died 12 years ago.
