← Back to context

Comment by phplovesong

14 hours ago

I know why typescript "succeeded", but always wonder what kind of web we would have if infact Haxe had become more popular for web in the early days. My guesstimate is we would have had bundlers in native code much, much earlier, and generally much faster and more robust tooling. Its only now we see projects like esbuild, and even TS being written in a compiled language (go), and other efforts in rust.

Also it would have been interesting sto ser what influence Haxe would have had on javascript itself

I assume you meant that the TypeScript compiler is being rewritten in Go. (At first I read it as something entirely different.)

Same could be said about Java Applets or Flash and, in a way, about Elm. We've been there and this approach doesn't work.

The creators of TypeScript realized early on that people don't need yet another ecosystem, but a migration path that won't pause development.

  • Thats true, but comes with a cost. TS has become an incredibly complex language, even it only provides types. Thats being said is will always lack features as it only "javascript".

    Haxe has a more robust, but simpler typesystem, that comes from ocaml.

    Haxe also compiles to C++ so making native tools would have been a breeze.

    TS sits at the top chair, but there is many "better" options out there, like Elm (even its kild of a dead languge) and ReScript/ReasonML etc.

    TS is good, but will never be a perfect language for javascript. It will always be a mediocre option, that is growing more and more complex in every new release.

    • Yes, amazing language - I recall having a look at it in 2013 when I was scrambling for a replacement for Flash (also amazing platform). Shame it doesn't solve the problem at hand.

      Hardly anyone cares TypeScript isn't perfect when they can migrate their (or anyone else's) terrible, but business-critial JS library to TS and continue development without skipping a beat.

      For the same reason ReasonML took years to overtake fartscroll.js in the number of stars on GitHub.

      A huge part of TS's complexity is there so that library authors can describe some exotic behaviours seen normally only in dynamically-typed languages. When you're writing an app you don't need the vast majority of those features. Personally I regret every usage of `infer` in application code.

      2 replies →