Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
1–10 of 115 posts
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#2This is quite difficult to make sense of beyond the initial description so I’m not sure about the current status. But it would be a shame to lose valuable type info because compile times are long... isn’t there a tool out there that does nothing except strip types from TS files? If you used that you could get quick rebuilds when developing but retain type checking when you do a full build.
EDIT: Sucrase! That’s what I was thinking of:
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#3What is ‘deno code’?
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#4[deleted]
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#5What is ‘deno code’?
Deno [1] is a new JS runtime by one of the creators of NodeJS, Ryan Dahl.
He had a great talk [2] about the lessons he learned when creating/maintaining NodeJS. Many of these lessons are being applied to Deno.
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#6JS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#7It's important not to read this as a critique of Typescript. Rather, it's a note that it's not a good fit for this one particular performance critical piece of code.
It sounds like they are discussing the central code runner of deno. I would have expected this to be compiled to JS in any case, but it seems like they are compiling the runner, then compiling user code. Of course that's slow. It's also not representative of a normal TS use case, which is unfortunate because I expect we'll see this discussion shared all over the web as an argument for dropping TS.
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#8This doesn't seem all that odd. I read this as a temporary solution to the fact that there's some real problems that TypeScript causes for the way their project is laid out and used with regard to certain types of introspection (noting duplicate classes) and performance (it's damn slow).
It's like them running the TypeScript compiler to generate one large JS file and using that intermediate as what people build against instead of the original TypeScript source. I'm not sure if this is what they're actually doing (or if they're somewhat manually doing the equivalent of it), but as a hopefully short-term workaround that allows them to solve the problems, that doesn't seem too bad (but it does possibly highlight some TypeScript problems).
Even if they actually move to a large core JS file that is the active development target, as long as they keep track of the TypeScript specifics (and don't code themselves into a corner assuming something works that they find much later errors), it may not necessarily be hard to go back to TypeScript from that (possibly with a lot of it automated with a lot of structured comments).
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#9This doesn't seem all that odd. I read this as a temporary solution to the fact that there's some real problems that TypeScript causes for the way their project is laid out and used with regard to certain types of introspection (noting duplicate classes) and performance (it's damn slow). It's like them running the TypeScript compiler to generate one large JS file and using that intermediate as what people build again…
Part of what's slow is that they're type checking and compiling the code at the same time. Best practice for a project of this size would be to run type checking as a unit test and only transpile during the build. An incremental type check is also super fast, it's possible they don't have caching setup.
To me this reads more like a list of issues in the deno architecture, and how they integrated TypeScript, than any issue with TypeScript itself.
Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
#10JS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types
It's interesting, I wonder why the proposal doesn't talk about leaving TS code and simply ignoring the syntax using something like babel to preprocess it out (without needing to run the type checking outside of CI).