Alternative approach: speccing browsers to handle content type `application/typescript`

[connorjclark]

Would speccing that browsers read application/typescript files in a type-ignoring manner solve the same issues, and be simpler by leaving the JS language untouched?

[ljharb]

The language specification does not have any concept of MIME types - that's mostly a browser-only thing.

Either way, there would need to be a parse goal defined, and the language (not the browser) is the place to define it.

[bradzacher]

This was one thing I was wondering as well.

In NodeJS you can currently achieve this spec by using a package like ts-node or @babel/register, and Deno works around this by just using its own TS-compatible parser to scrub types. Browsers don't have the same hooks, so you can't explicitly register a user-land hook to be run before a file is parsed by the engine.

Instead of attempting to specify all possible type annotations and how to parse them - would it be better to work on a specification to provide custom pre-parsers (or whatever name) to engines to allow the user to control how the code is converted to pure JS?

[connorjclark]

The language specification does not have any concept of MIME types - that's mostly a browser-only thing.

That's right, my thinking was maybe it'd be beneficial to keep them separate, such that anything defined as type syntax (which is just typescript syntax) doesn't potentially conflate with syntax the JS language might want to use in the future. But if the ecosystem benefits enough from JS directly allowing this "ignored typescript syntax", then the separation wouldn't be desired.

Either way, there would need to be a parse goal defined, and the language (not the browser) is the place to define it.

Ah, that makes sense. A big assumption I was making was that it might be simpler to specify type syntax outside TC39/just in the web standards by segregating javascript content from typescript/"javascript with types" content. If TC39 doesn't care for the loss of any potential syntax that would be given to enable "ignored types" (how I'm paraphrasing this proposal) then adding it to the JS language sounds best. And very exciting.

Besides, I'm probably misunderstanding the proper roles of the various standard bodies (like; why would w3c want to do this on their own?)

[giltayar]

Defining a mime type for TypeScript will keep JavaScript and TypeScript separate. This is not what I believe we should do. I believe the languages should converge, for the benefit of the JavaScript community.

[bradzacher]

I believe the languages should converge, for the benefit of the JavaScript community.

IMO this is the wrong take on this. Whilst TS may be the more common, it is not the only JS-extension language (flow and hegel are two examples).

As far as I understood it from the discussion last week - the intention of this proposal is to support all of these languages, rather than making TS the syntax everyone must conform to.

[junoatwork]

There is some precedence here with <script type="module">... - and I think this is an important approach to ensure backwards compatibility. However, I don't think it should directly specify application/typescript or any specific language; instead, maybe <script type="annotated"> (could bikeshed the name). <script type="annotated"> could also imply module.

[ljharb]

A separate script type attribute would only make sense if this was separate (third, and fourth since both Script and Module would need it) parse goals for Ecmascript. That seems like a wildly different proposal.

Short of that, this syntax would have to be supported in both existing script types.

[jimmywarting]

This is why browser have never adopted any other language: https://stackoverflow.com/a/8947021/1008999 it's either going to be wasm or javascript

I don't see TypeScript will never land in browser, only javascript can get better at supporting something more like a type system

[mindinsomnia]

I don't see why Typescript can't be added as an alternative since this proposal is already suggesting changing javascript interpreters everywhere to handle most of the syntax of typescript in the first place..

That being the case, why not add typescript as an alternative language of the web? It would simplify the rollout of this desired change and allow JS coders to keep using clean JS, and TS coders to use TS exactly as it is.

TS is effectively just JS with types, so any TS interpreter would be effectively the same as a JS interpreter with just optional typing, which is again, exactly what this proposal is already suggesting should be added to web browsers.

So really, why not?

application/javascript | .js -> Loaded as Javascript application/typescript | .ts -> Loaded with Javascript engine with typing enabled.

PS: Deno already handles this. Deno runs TS and JS as separate things. We're already talking about a proposal which is seeking to modify JS to support most of TS's syntax, so I don't think it's that crazy to just say 'Just add TS support to browsers'. This proposal effectively amounts to 'Just add about 75% of TS support into JS', so it's not exactly a leap.

[giltayar]

So really, why not?

https://github.com/giltayar/proposal-types-as-comments#should-typescript-be-standardized-in-tc39

This proposal effectively amounts to 'Just add about 75% of TS support into JS', so it's not exactly a leap.

https://github.com/giltayar/proposal-types-as-comments#does-this-proposal-make-all-typescript-programs-valid-javascript

[dgp1130]

Just to hop in to this conversation, I recently had a similar idea to this proposal where a browser could automatically transform TypeScript into JavaScript as a developer feature and achieve many of the same tooling benefits without modifying the JavaScript standard.

https://tweets.dwac.dev/1513416629752762370/

I just prototyped this out as a browser extension which effectively watches the network for TypeScript files and transforms them to JavaScript automatically, so no custom build tooling is required to run TypeScript for development. This works, but falls over a bit because there's no clear mechanism for determining which files are real JavaScript and which ones are actually TypeScript and need to be transformed into JavaScript.

https://tweets.dwac.dev/1581678102731579394/ https://github.com/dgp1130/ts-transformer-extension/

The three approaches I identified include:

• Use file extension (*.ts URLs are treated as TypeScript).
  • Browsers typically don't use URL file extensions to determine behavior.
  • Putting <script src="/index.ts /> into source code would diverge the development build from the production build.
  • import '/index.ts'; is disallowed by TypeScript.
• Use an attribute on the script tag (<script src="/index.ts" type="typescript" />).
  • Also diverges the development and production builds, since you need to replace this with a different <script /> tag for production which is not a common operation to do.
• Use Content-Type: application/typescript.
  • The dev server needs to know that any request for *.js should actually return the *.ts file with Content-Type: application/typescript. If the dev server knows to do this, it may as well transform it for you just like Vite or other ESM dev servers.

My main takeaway is that I think it should be the dev server's responsibility to transform TypeScript in JavaScript just like existing ESM dev servers already support. They have more context to do this more effectively and have all the same usability benefits since they don't require an distinct build step. Everything is done at serve-time, and both the type annotations proposal and this issue's suggestion still require an HTTP server. This issue could use any static file server (I used http-server), which is one benefit, but there's not much usability difference between npm install http-server and npm install vite, so I don't see a major benefit there.

Anyways, I thought this prototype was interesting to this discussion and just wanted to share it more broadly. Hope this is helpful in some way. Maybe it would be worth a separate discussion about the usability benefit of the type annotations proposal compared to ESM dev servers which automatically transpile to JS at serve-time? As of right now, it seems to me like the dev server approach has all the same tooling benefits with far less complexity. 🤔

https://github.com/dgp1130/ts-transformer-extension/