11 ms·
Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
- untog 6y agoThis 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: https://github.com/alangpierce/sucrase#transforms https://github.com/alangpierce/sucrase#transforms
- alangpierce 6y agoHi, Sucrase author here. I'm also having a hard time understanding the rationale here, but it looks like it's maybe a nuance around self-hosting. In general, for any regular TS project, I'd certainly recommend decoupling typecheck and transpile as separate operations and running typecheck alongside lint. IMO one of the nicest things about TypeScript is that you can run your code before you've figured out how to get the types to check out. They do consider swc (which has roughly the game goal as Sucrase) in the conversation, so it seems like there's some consideration of a transpile-only approach. TypeScript's built-in `transpileModule` is probably the most reliable and officially-supported way to get the equivalent, and is much faster than running TSC with typechecking.
- MBCook 6y agoWhat is ‘deno code’?
- azemetre 6y agoDeno [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. [1] https://deno.land/ https://deno.land/ [2] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
- mikewhy 6y agoAs mentioned, Deno is the new project from the creator of NodeJS. Here, as far as I can tell, "Deno code" specifically related to the code shipped to the developer / user using Deno, the compiler / runtime.
- csours 6y agodeno de no no de node heh.
- deleted 6y ago[deleted]
- dfabulich 6y agoJS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types https://github.com/samuelgoto/proposal-pluggable-types
- CGamesPlay 6y agoIt'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).
- mikewhy 6y agotsc can also do that, but I think there's something else here. I'm not really sure what this post is getting at. I trust Ry knows the issue better, but from what I've read I have the same questions as everyone else here: - Why is Deno defining interfaces and classes like that? - Will this mean losing type checking in projects using deno? - Why not strip types in development and only check at commit/push/build times?
- hn_throwaway_99 6y agoFWIW Flow actually let you write type annotations as comments so that the code was syntactically valid JavaScript. I'm not sure if TS ever had something like this. https://flow.org/en/docs/types/comments https://flow.org/en/docs/types/comments
- mikewhy 6y agoFor a while, TypeScript has been able to check types using JSDoc. Since 2.3 I think, back in 2017.
- esperent 6y agoIt'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.
- _bxg1 6y agoa) Any static type system has things that it can't express elegantly or maybe at all. In my experience, the more "meta" your project is, the more you're going to run up against these bounds. So it makes sense that this could be the wrong use-case for TypeScript. b) There is a valid, broader point to be made here that while TypeScript itself doesn't carry any runtime overhead (by design), it can in some cases force you to contort your code, so that it can be type-verified, in ways that have a runtime impact. In my experience (a couple of years writing TypeScript professionally) this is uncommon and not a huge problem, but does happen occasionally. It's also worth noting that the vast majority of these cases can be papered-over using //@ts-ignore, "as" casting, etc. if necessary.
- austincheney 6y agoI don’t read that as a criticism of TypeScript at all. That is entirely self inflicted due to a name collision between an identity in their definition file and some weird class extension insanity. I don’t use classes or inheritance in my own code and it’s incredibly liberating. The result is data structures and interfaces that are primitive and independent, which removes so much fragility.
- deleted 6y ago[deleted]
- hkai 6y agoIn my entire experience as a programmer, I can't recall writing a prototype that was not eventually used as production code. If I wrote prototypes in JavaScript, I'd have to start all over again to rewrite them in TypeScript. Meanwhile, people would be on my ass trying to understand why I can't just simply hook up that decent looking prototype to API and release it.
- kbenson 6y agoThis 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).
- esprehn 6y agoPart 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.
- temporallobe 6y agoThis cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain old JavaScript and have never really seen the benefits of DSLs like this. Coffeescript was especially pointless to me when I had to use it on a project. My reasons are simple: debugging becomes much more difficult when you add a layer of abstraction. It compiles to JavaScript anyway, and sometimes it does so in very odd ways that makes it difficult to understand the relationship between what you wrote and what it produced. IMO, straight JavaScript is more than adequate for most scenarios if you know the language well enough, especially with the powerful features built into the more recent versions. In my 20 years as a (mostly) front-end developer, I have not heard any convincing argument in favor of a transpiled JavaScript pseudo-language. Of course there are advantages, but most of these can be solved with better code organization and architecture. I will say I don’t quite feel as strongly about CSS pre-processors like SCSS, which I really enjoy, however I still prefer plain old CSS for the same basic reasons.
- tuckerconnelly 6y agoI feel the exact same. Reminds me too of Nassim Taleb's idea that, if something as already existed X years, it's likely to exist another X years. I'm skeptical of the staying power of these transpilers.
- francis36012 6y agoTypescript has been around since 2012. Going by the quote, it is likely to still be around in the next 8 years.
- AaronFriel 6y agoTypeScript has been around since 2012, and it has since won in the marketplace of ideas, becoming the single most popular language to transpile to ES# and beating a well-resourced competitor in Flow. The type war was "won" by TypeScript, and I expect it's just a matter of time before types make it into the standard. The benefit of winning so completely and having such enormous popularity is that its ideas are very likely to make it into the standard such that no transpilation will be necessary.
- fearingreprisal 6y agoAt what point are people going to just admit that implementing applications in Javascript outside the browser is a poor idea? The ecosystem has been in this poor state for years. It's not like the ecosystem is getting worse. This is the best it's ever been, and it's still horrible. There's so many better, more mature alternatives with much better ecosystems: Python, Java, C#, Ruby, Go, Haskell, Perl... The list goes on.
- hn_throwaway_99 6y agoYour comment is somewhat incomprehensible, because this article is not about building end user applications in Typescript. It's about building the container itself in Typescript. I switched to Node from Java a couple years ago, and to Typescript within the past year, and I have never been on a team that has had this level of productivity.
- fearingreprisal 6y agoWhat part of it couldn't you comprehend? I understand what the article is saying. I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript. In response to your personal experience, I'll share my own: I switched from C++ to Java, to .net, to Node.js, to Typescript. Working on Node/TS I have never been on a team that wastes so much time fixing silly problems that a better language would simply not allow to happen in the first place. I have also never worked on a team that spends so much time dealing with issues in poorly written community packages, or arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.
- untog 6y ago> I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript. Deno is, by definition, not Node.js. Typescript can live outside of Node (like when it's compiled for and runs in the browser). So I think you're getting downvotes because it reads like a generic rant about the same things we've already heard about in a context where it doesn't apply. I'm not going to argue with the notion that Node has many poorly written community packages, it does, but this core piece of Deno functionality does not use any.
- eatonphil 6y agoI started using Evan Wallace's TypeScript [0] implementation (and bundler) written in Go and it's pretty fast (there are benchmarks too). I'm surprised this kind of thing is not something Deno's pursuing. Having used esbuild I see the future of web tooling as not necessarily written in (or compiled to) JavaScript. [0] https://github.com/evanw/esbuild https://github.com/evanw/esbuild
- yawaramin 6y agoEsbuild isn't a typechecker, it's a bundler.
- uasi 6y agoThey are considering switching from tsc to a TypeScript compiler written in Rust[0][1], and `deno fmt` subcommand already uses it internally. [0] https://github.com/denoland/deno/issues/5432 https://github.com/denoland/deno/issues/5432 [1] https://github.com/swc-project/swc https://github.com/swc-project/swc
- yawaramin 6y agoswc is not a TypeScript compiler, it doesn't do any typchecking. It just strips out types and outputs JavaScript.
- yashap 6y agoThis makes me generally curious about Deno’s architecture/design. Anyone known much about it? Would love to learn more! I know the JS engine is V8 (C++), and the rest is Rust and TypeScript, but which parts are Rust, which parts TypeScript? Why 2 languages? Is it mostly Rust, mostly TypeScript, or a bit of both? Also, what are the hardest problems that Deno solves internally? Like if you’re working on Deno, are you mostly working on ... the dependency resolution/package management? Automatic compilation of user TypeScript code? The standard library? Something else entirely?
- Der_Einzige 6y agoAw, the famous game design YouTube channel "Design doc" is nowhere to be found here. I thought he was pivoting to dev advice...
- mcintyre1994 6y agoDoes this mean that their standard lib won’t have types, in the same way that Node’s doesn’t? I’m not entirely sure how it works but VSCode seems to have types for the Node standard library somehow and it’s really helpful. I assume that’s Microsoft’s work so does this basically mean that unless Microsoft do the same thing for Deno it’ll be a worse editing experience compared to Node in VSCode? Or would the Typescript internals not have been available in that way anyway? It just seems hard to compete on ease of use with Node in VSCode without whatever magic is making the editor so smart - which I assume is something to do with Typescript.
- davnicwil 6y agoNo - you don't have to write the code in Typescript to get types - you can manually write type definitions for Javascript code. In this case it would be even easier since it's already in Typescript and would presumably be a straight port, so all of those type definitions can be automatically generated from the existing code and will just work.
- mcintyre1994 6y agoI was going by this quote: > ry So - to make a long story short - we're removing the types from internal code and making it pure JS this reduces complexity and helps us ship a faster product. I acknowledge it's unfortunate to lose the type information, but it's really masking larger problems. It's not going to happen immediately tho. We have a bit more work to figure out how exactly it should be done. It's not going to be one big 9000 line file either. But it might not be ES modules. depending on if we can make that work or not. The “lose the type information” there suggested to me that they’re not planning to ship them at all.
- davnicwil 6y agoI think that's in reference to losing the type information for their own development of that code. I'm almost certain they don't mean they will stop shipping type definitions for the public APIs.
- errantspark 6y agoThis is amazing. I'm legitimately excited for Deno, I will start migrating all of my dependency-less node over soon.
- ecares 6y agoSo, you mean the people who were supposed to make the best choices to fix server-side JavaScript with the ultimate knowledge of what's best just realized that some of their pre-made opinions are actually not-silver bullet? Shocking