3 ms·

Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barre

by roqi 3y ago

Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barreling, is becoming daunting.

Cthulhu_ 3y ago
Deno is a nice project for running TS without a separate transpile process, but that's server-side only. Browser-side, they tried to add support for a second language via Dart, but that didn't work out.
mcluck 3y ago
You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
- jeroenhd 3y ago
  I like the idea of JS modules but they don't entirely negate the need for bundling. Sending a single compressed, tree shaken, minified JS file down the pipe can be a lot more efficient than waiting for the browser to load all those files. Theoretically HTTP/2 push could've helped here, forcing the necessary files into the browser cache, but that's been removed from browsers.
  - mcluck 3y ago
    Agreed. To me, browser support for modules is great for debugging but is not a suitable replacement for producing an optimized set of bundles
wffurr 3y ago
No, but the TypeScript compiler will also check types specified in JSDoc: https://devclass.com/2023/05/11/typescript-is-not-worth-it-for-developing-libraries-says-svelte-author-as-team-switches-to-javascript-and-jsdoc/ https://devclass.com/2023/05/11/typescript-is-not-worth-it-f... https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
nosianu 3y ago
> Is there any effort to get browsers to support typescript You may want to read https://news.ycombinator.com/item?id=35187377 https://news.ycombinator.com/item?id=35187377 https://news.ycombinator.com/item?id=35653653 https://news.ycombinator.com/item?id=35653653 Transpiling is entirely optional. Choose "esnext" as target and don't use the old and no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations. If you write Typescript you already write pure Javascript, you just add type annotations, which are not part of the code and don't make it into the code. Typescript mixes type checking and transpiler (Babel) and a few other thing in one big "blob" of a tool - unfortunately, the Unix way would have been to have separate tools. Which you can do and many do: Don't use "tsc" to create your .js code, only use it (through the IDE or standalone) to check types, and let Babel do any transpilations. It's much more flexible than "tsc" too. What you are really asking is "Is there an effort to add types to ECMAscript" - and that does not look likely, because a) the existing solution already works well enough, and b) if you look at all the troubles and limitations you get when you use types you realize adding types is nearly impossible if you want to remain backwards compatible. If you use typed code, e.g. by using Typescript or Flow, you either end up with a lot of "any" types, or you have to code for the type checker. You cannot add reliable types to any previously pure Javascript code base. The code itself would have to change. Also, enough people don't want any types with their JS.
- duped 3y ago
  > no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations. Both these things are needed. The workarounds you listed are not equivalent and not drop in replacements.
  - nosianu 3y ago
    No they are not needed. See these and many similar statements/posts. https://michelenasti.com/2019/01/23/is-typescript-namespace-feature-deprecated.html https://michelenasti.com/2019/01/23/is-typescript-namespace-... https://stackoverflow.com/questions/64495793/typescript-namespaces-to-be-discontinued https://stackoverflow.com/questions/64495793/typescript-name... https://github.com/microsoft/TypeScript/issues/30994#issuecomment-492017219 https://github.com/microsoft/TypeScript/issues/30994#issueco... (link to a specific comment) > Namespaces are probably never going away and, simultaneously, you probably shouldn't use them, since better, more standard and modern patterns exist through the use of modules. If you have code that you feel needs to use a namespace, more power to you and go for it, but most of the time you don't need one, as we now have a different conceptual organizational model recommended for large-scale JS (modules). That's why @DanielRosenwasser (Program Manager of TypeScript) said namespaces are not a huge loss - most new TS code should probably never need to use them, and should think hard about if they really need to. Sure, you can use them, enums as well still provide a few more options than object literals, and since those features are in TS anyway and will remain like everything in JS always remains for backwards compatibility... - but they are not needed. There even is a sentence in the TS documentation (under Namespaces and Modules) that starts with "If you’re converting a program from namespaces to modules,..." (see https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html#needless-namespacing https://www.typescriptlang.org/docs/handbook/namespaces-and-...) This is distorting my post's point, which was Typescript is ECMAscript, and I did mention the two big exceptions, and I said they are not needed - which is just truth. They were necessary before ES 2015, which is the reason they exist to begin with. Other than that, Microsoft's explicitly stated goal is to keep Typescript perfectly aligned with ECMAScript, and to only add types. Now that the language has all the minimum features they don't make any more changes that require actual transpiling because the code itself - not the types - is "Typescript only" and not part of ECMAScript. They will, however, leave in anything that is already there, just like ECMAScript does, because backwards compatibility trumps all. Also note that you can have types-only namespaces that only contain type definitions, which are entirely different: They fall exactly under what I said, types are just removed in the .js file generation step. Those kinds of "namespaces" don't lead to any executable code. Not to mention that you could easily just write the tiny bit of JS yourself instead of using the namespace keyword, because namespaces are simply named JavaScript objects in the global namespace. -- This is all it does: https://www.typescriptlang.org/play?noUnusedLocals=true&noUnusedParameters=true&preserveConstEnums=true&target=99&jsx=0&pretty=true&q=283#code/HYQwtgpgzgDiDGEAEARCYD2A5Aykg3gLABQSS8GwUGANhAHQ0YDmAFACwBMAlANwkBfEkA https://www.typescriptlang.org/play?noUnusedLocals=true&noUn... So if you want the same thing as TS namespaces with just JS code, all you need is a global object and then assign stuff to it, from one or from several modules.
sroussey 3y ago
On the server side, you can use bun instead of node.

by roqi 3y ago

Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barreling, is becoming daunting.

Cthulhu_ 3y ago

Deno is a nice project for running TS without a separate transpile process, but that's server-side only. Browser-side, they tried to add support for a second language via Dart, but that didn't work out.

mcluck 3y ago

You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

jeroenhd 3y ago
I like the idea of JS modules but they don't entirely negate the need for bundling. Sending a single compressed, tree shaken, minified JS file down the pipe can be a lot more efficient than waiting for the browser to load all those files. Theoretically HTTP/2 push could've helped here, forcing the necessary files into the browser cache, but that's been removed from browsers.
- mcluck 3y ago
  Agreed. To me, browser support for modules is great for debugging but is not a suitable replacement for producing an optimized set of bundles

wffurr 3y ago

No, but the TypeScript compiler will also check types specified in JSDoc: https://devclass.com/2023/05/11/typescript-is-not-worth-it-for-developing-libraries-says-svelte-author-as-team-switches-to-javascript-and-jsdoc/ https://devclass.com/2023/05/11/typescript-is-not-worth-it-f... https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

nosianu 3y ago

> Is there any effort to get browsers to support typescript You may want to read https://news.ycombinator.com/item?id=35187377 https://news.ycombinator.com/item?id=35187377 https://news.ycombinator.com/item?id=35653653 https://news.ycombinator.com/item?id=35653653 Transpiling is entirely optional. Choose "esnext" as target and don't use the old and no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations. If you write Typescript you already write pure Javascript, you just add type annotations, which are not part of the code and don't make it into the code. Typescript mixes type checking and transpiler (Babel) and a few other thing in one big "blob" of a tool - unfortunately, the Unix way would have been to have separate tools. Which you can do and many do: Don't use "tsc" to create your .js code, only use it (through the IDE or standalone) to check types, and let Babel do any transpilations. It's much more flexible than "tsc" too. What you are really asking is "Is there an effort to add types to ECMAscript" - and that does not look likely, because a) the existing solution already works well enough, and b) if you look at all the troubles and limitations you get when you use types you realize adding types is nearly impossible if you want to remain backwards compatible. If you use typed code, e.g. by using Typescript or Flow, you either end up with a lot of "any" types, or you have to code for the type checker. You cannot add reliable types to any previously pure Javascript code base. The code itself would have to change. Also, enough people don't want any types with their JS.

duped 3y ago
> no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations. Both these things are needed. The workarounds you listed are not equivalent and not drop in replacements.
- nosianu 3y ago
  No they are not needed. See these and many similar statements/posts. https://michelenasti.com/2019/01/23/is-typescript-namespace-feature-deprecated.html https://michelenasti.com/2019/01/23/is-typescript-namespace-... https://stackoverflow.com/questions/64495793/typescript-namespaces-to-be-discontinued https://stackoverflow.com/questions/64495793/typescript-name... https://github.com/microsoft/TypeScript/issues/30994#issuecomment-492017219 https://github.com/microsoft/TypeScript/issues/30994#issueco... (link to a specific comment) > Namespaces are probably never going away and, simultaneously, you probably shouldn't use them, since better, more standard and modern patterns exist through the use of modules. If you have code that you feel needs to use a namespace, more power to you and go for it, but most of the time you don't need one, as we now have a different conceptual organizational model recommended for large-scale JS (modules). That's why @DanielRosenwasser (Program Manager of TypeScript) said namespaces are not a huge loss - most new TS code should probably never need to use them, and should think hard about if they really need to. Sure, you can use them, enums as well still provide a few more options than object literals, and since those features are in TS anyway and will remain like everything in JS always remains for backwards compatibility... - but they are not needed. There even is a sentence in the TS documentation (under Namespaces and Modules) that starts with "If you’re converting a program from namespaces to modules,..." (see https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html#needless-namespacing https://www.typescriptlang.org/docs/handbook/namespaces-and-...) This is distorting my post's point, which was Typescript is ECMAscript, and I did mention the two big exceptions, and I said they are not needed - which is just truth. They were necessary before ES 2015, which is the reason they exist to begin with. Other than that, Microsoft's explicitly stated goal is to keep Typescript perfectly aligned with ECMAScript, and to only add types. Now that the language has all the minimum features they don't make any more changes that require actual transpiling because the code itself - not the types - is "Typescript only" and not part of ECMAScript. They will, however, leave in anything that is already there, just like ECMAScript does, because backwards compatibility trumps all. Also note that you can have types-only namespaces that only contain type definitions, which are entirely different: They fall exactly under what I said, types are just removed in the .js file generation step. Those kinds of "namespaces" don't lead to any executable code. Not to mention that you could easily just write the tiny bit of JS yourself instead of using the namespace keyword, because namespaces are simply named JavaScript objects in the global namespace. -- This is all it does: https://www.typescriptlang.org/play?noUnusedLocals=true&noUnusedParameters=true&preserveConstEnums=true&target=99&jsx=0&pretty=true&q=283#code/HYQwtgpgzgDiDGEAEARCYD2A5Aykg3gLABQSS8GwUGANhAHQ0YDmAFACwBMAlANwkBfEkA https://www.typescriptlang.org/play?noUnusedLocals=true&noUn... So if you want the same thing as TS namespaces with just JS code, all you need is a global object and then assign stuff to it, from one or from several modules.

sroussey 3y ago

On the server side, you can use bun instead of node.