Hacker News Reader

Comment by dsego | Hacker News Reader

At this point why not just have browsers run TypeScript natively? Remember the <script type="text/javascript"></script>, maybe just put <script type="text/typescript"></script> and be done with it.

View on HN

Because it's a slippery slope that you can never get agreement on (even majority agreement on, let alone overwhelming agreement). Why TypeScript? Why not Flow, or even Python or ClojureScript, or (my vote...) PureScript?

Then what happens in 2 years when the "next big thing" comes out that is mind-boggling-ly awesome and obviously obsoletes TypeScript? The latest addition to JavaScript is Array.flat... it should be called Array.flatten, but there was a popular third-party library 15 years ago that used it and you can't go breaking the web every time there's a new "best way" to do things.

Each fan of each language will happily tell you why theirs is better than any others, and why it's the obvious choice to be the default in a browser. Everyone might agree they don't want JavaScript, but no one will ever agree on what should replace it. That's why your two options will only ever be "JavaScript" or "transformed/WebAssembly-fied other language".

Good example, imho better to stop adding stuff to JS, declare it legacy and leave support in browsers so old pages render fine. Then add a new language without compromises like `flat` or `includes`.

What's the point? If you're going to use typescript, you will want to do typechecking. And if you do typechecking, you might as well compile your project properly.

I'd honestly rather have browser support less than more and I'm happy with type annotations remaining a language superset. The current typescript situation is actually fantastic and as a python dev, I envy it a lot.

If TS becomes the majority, it seems to me like the browser debuggers could start using types at run time to catch some interesting things that aren't so obvious when compiling the pieces. I.e. help the people who add the final touches to a site check that they have not messed it all up without the project writer needing to decide how many guards to compile in to the project interfaces.

Probably the largest problem I have with modern projects is how unfriendly they are to experiment with on the page, even if there's no intention to prevent it.

Hmm, I can't quite see what kind of thing browsers could catch that typescript itself couldn't, since the whole point of types is to be useful at compile-time.

That said I could see some type introspection being useful in the devtools. This is probably already feasible though, as devtools are sourcemap aware. And typescript is written in typescript after all, so it couldn't be that hard to pull in support for it in the devtools, could it? :)

Cool idea!

In my uneducated opinion, I think this is the direction things will go. Typescript will steadily supplant JavaScript and browsers will eventually roll out native support for it, and JS will be relegated to a legacy language.

Having TypeScript support in the browser doesn't make sense as the idea behind TypeScript is to add a compilation step so that type errors can be caught at compilation time. eg. before the code runs.

The browser still has to parse the JS code before executing it. It will complain if you get the syntax wrong, type checking is the same thing.

>Typescript will steadily supplant JavaScript and browsers will eventually roll out native support for it, and JS will be relegated to a legacy language.

Typescript can't supplant javascript or relegate it to a legacy language... because typescript doesn't compile to bytecode or machine language, but to javascript. Browsers that support typescript natively must by definition also support javascript natively, and the more of the former you have, the more of the latter you have.

And C++ used to compile to C at first, I don't see your point.

Reply on news.ycombinator.com