6 ms·

I love this. Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can c

I love this. Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time. Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.

bavell 4y ago
This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.
- IshKebab 4y ago
  That "optionally" is going to bite you in the arse as soon as you have more than one person working on the project.
redox99 4y ago
I don't see what the issue is. For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node). For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference. It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
- rektide 4y ago
  How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour? This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are. It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever? You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations. > "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json" The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over. This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options. Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs. JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy. [1] https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/ https://devblogs.microsoft.com/typescript/announcing-typescr...
88913527 4y ago
I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the browser can understand. I imagine most use cases today face this dilemma. It wasn't the type annotations holding me back for requiring pre-processing, it was the ecosystem around how JavaScript is written that is the primary factor.
- runarberg 4y ago
  I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these. Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.
  - 88913527 4y ago
    So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them. It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.
- afavour 4y ago
  That’s your use case, but it’s not the use case the standards bodies have in mind. ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.
runarberg 4y ago
I’ve been writing Vanilla JavaScript with JSDoc annotations and using TypeScript as a type checker (as opposed to a compiler) for some of my hobby-projects, and it is amazing breath of fresh air from the bundler tool chains of the past. As pointed out by this proposal the JSDoc annotations are—to put it mildly—a bit cumbersome. The more complicated types are close to impossible to figure out how to write, if they are possible to write at all. And on Q&A forums I constantly have to translate between the two syntaxes in my head, since most of the audience will probably not understand the JSDoc syntax. Having a unified type annotation syntax which the runtime ignores will definitely make my life easier.
justsomeuser 4y ago
esbuild works well.

bavell 4y ago

This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.

IshKebab 4y ago
That "optionally" is going to bite you in the arse as soon as you have more than one person working on the project.

redox99 4y ago

I don't see what the issue is. For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node). For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference. It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.

rektide 4y ago
How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour? This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are. It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever? You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations. > "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json" The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over. This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options. Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs. JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy. [1] https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/ https://devblogs.microsoft.com/typescript/announcing-typescr...

88913527 4y ago

I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the browser can understand. I imagine most use cases today face this dilemma. It wasn't the type annotations holding me back for requiring pre-processing, it was the ecosystem around how JavaScript is written that is the primary factor.

runarberg 4y ago
I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these. Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.
- 88913527 4y ago
  So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them. It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.
afavour 4y ago
That’s your use case, but it’s not the use case the standards bodies have in mind. ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.

runarberg 4y ago

I’ve been writing Vanilla JavaScript with JSDoc annotations and using TypeScript as a type checker (as opposed to a compiler) for some of my hobby-projects, and it is amazing breath of fresh air from the bundler tool chains of the past. As pointed out by this proposal the JSDoc annotations are—to put it mildly—a bit cumbersome. The more complicated types are close to impossible to figure out how to write, if they are possible to write at all. And on Q&A forums I constantly have to translate between the two syntaxes in my head, since most of the audience will probably not understand the JSDoc syntax. Having a unified type annotation syntax which the runtime ignores will definitely make my life easier.

justsomeuser 4y ago

esbuild works well.