Comment by WorldMaker | Hacker News Reader

Comment by WorldMaker | Hacker News Reader

Parent Full thread

The tale of Typescript was that several of Microsoft's own JS codebases had gotten too huge to manage in just JS and Typescript was built to scratch their own itch first. Microsoft happened to have a smart developer-focused division that also realized that Microsoft's own customers could benefit from the tool, too.

Microsoft has invested quite heavily into some very large TS codebases: VS Code/Monaco, VSTS, the Azure portal, large components of Office, large components of Bing, and so forth. Given the scale of some of those projects (in terms of users at the very least, even before you get into metrics like lines of code or dollars generated), that is a lot of benefit to having a strong tool like Typescript to do that work in. Many of the same developers working in Typescript use C++ and/or C# daily, so they already understood the usefulness of things like static type checking. Releasing it to the public when they did seemed a very cogent realization that that "enterprise JS application problem" was far bigger than just Microsoft and they were in a good place to help with that, given it's long been a goal of the company to help developers.

As for a Typescript proposal for TC39, I'm willing to bet everyone is still worried about accidentally creating a second "ES4" debacle, including Microsoft. I'd love to see, and would much more expect at this point, a pragmatic compromise like Python's PEP 526 [0] / PEP 3107 [1] project, encouraging JS engines to syntactically accept things like Typescript's type annotations, but remaining agnostic to what the annotations represent semantically (giving other JS users the option of doing things with the annotations other than types, too, if they wished).

[0] https://www.python.org/dev/peps/pep-0526/ [1] https://www.python.org/dev/peps/pep-3107/

Even if JS engines were to accept the type annotation syntax, there would still be a need to strip out the types simply from the perspective of minimizing JavaScript bundle sizes.

Most Node code runs unminimized, and HTTP2 makes minimization less of a concern for the web. (It's still useful, of course, but less necessary.)

So sure it is likely that in many cases browsers will still mostly see JS with stripped annotations, but the reason to do it is the same as the debate over whether or not to strip comments and/or support sourcemaps. There's clear wins at the very least in debugging situations to allow unstripped type annotations all the way through to the dev tools. There are even cases where that may make sense even in a production environment, including things like metaprogramming if those annotations are reflectable.

This nice thing would be to have the option, whether or not most projects might still prefer to strip them out to optimize bundle sizes. As with almost all things, it's an interesting spectrum of tradeoffs.

How does HTTP2 make minimization less necessary?

There have been claims that http2 pipelining means it's more efficient to serve bundles as separate files, unminified so they can be downloaded in parallel. (I haven't yet seen numbers that show it's a benefit in practice though.)

Not just pipelining, but fewer more high-throughput connections, smaller HTTP header overhead, HTTP2 Push with the server being able to stream a "bundle equivalent" to the client in the background, and perhaps most importantly, Brotli compression which does pretty well with unminified JS.

Not necessarily, given that a binary representation is also being discussed (not to mix with WebAssembly).

https://github.com/binast/ecmascript-binary-ast

> there would still be a need to strip out the types simply from the perspective of minimizing JavaScript bundle sizes.

Are you really sure?

To me that attitude sounds awfully close to cargo-culting.

How is that cargo-culting? GP's comment doesn't even seem to come close to the meaning of cargo-culting. And yes, type definitions in my projects account for a good percentage, anywhere from 5-25% of each file, if you take into account all the interfaces, parameter definitions, class types... So that's removing 5-25% of your minified JS bundle, and if we're talking a 4mb bundle, that could be 1mb of type information, completely useless at runtime. If you needed to map that type information to your source code, this is what source maps are for!

Reply on news.ycombinator.com