Hacker News Reader

Comment by sergiomattei | Hacker News Reader

Dumb question incoming… Why not formalize TypeScript into the ECMAScript spec?

Some FAQ items address this:

https://github.com/giltayar/proposal-types-as-comments#why-n...

Various good reasons, like how it would hinder TS evolution and you'd end up having to compile TS to whatever older version of TS the slowest implementors support anyways.

But one interesting point is that type analysis is for the developer's benefit. What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine?

> What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine?

Is that even a question?

If more people adopt TS because it's native in browsers, producing less bugs means more user satisfaction.

Why would more people adopt TS because it's native in browsers, which won't enforce specifying type annotations anyway?

No compiling process = easier?

But how does the end-user care about static type analysis and why is it being done on their client? What exactly does this UX look like for them?

If you push TS source that you didn't bother tsc'ing on your machine because hey it runs on the client, does it simply fail to run for the user even though the program would have worked? I don't see how pushing TS source is better than pushing compiled JS.

Why does Javascript have to have all of Typescript brought into it? The browser has supported multiple scripting languages before. Not unprecedented.

Unfortunately, the HTML5 spec dropped the language option for the script tag, so browsers will only ever natively support javascript now and in the future. We're not going to get multiple languages back until something like runtime embedding through WASM becomes commonplace.

Google controls JS to the point of being able to ignore the spec (e.g. that time they left TCO behind an experimental flag and it just went away despite being in the spec).

As long as node and chrome are so dominant, we're probably not going to see big shake-ups in JS that aren't driven by Google themselves.

JS is flexible, you can cover up a lot with polyfills, but not completely different syntax. Doing that without Google's buy in would create a rift in the internet that would either end with browser specific web pages, or with the complete loss of power for the committee that sets the ECMAScript spec as JS officially goes from being a language that is defined by a spec to a language defined by a canonical implementation (in this case V8).

This actually isn't dumb question.

Nothing precludes Typescript from becoming another ECMA spec. It's just not going to be ECMAScript.

Nothing precludes Microsoft from allowing Typescript to run directly in the browser either. Nothing. Just that nothing forces any other browser to support Typescript as well.

Nobody has to follow standards if they don't want to, in practice...

Yeah, isn't TypeScript without enums and decorators already kind of "types as comments"?

TypeScript does support JSDoc type annotations and will use them to validate types in a JS project.

https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

If only the ECMAScript/JavaScript community were this sensible.

Reply on news.ycombinator.com