Hacker News Reader

Comment by threatofrain | Hacker News Reader

> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow.

> Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust.

> This will be a massive undertaking and will not happen any time soon; but it would provide order of magnitude performance improvements in a critical path experienced by developers. TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch.

View on HN

Deno really shouldn't run TypeScript files directly. Not only is TypeScript too slow for this, it receives far too many breaking changes.

How will Deno decide when to upgrade its TypeScript compiler version? Will Deno have to have breaking changes every three months or so?

Also, Deno appears to allow import TypeScript files with .ts extensions while tsc doesn't. This alone means the same code won't run in Deno and compile with tsc.

JavaScript at Stage 3 and above is a stable compile target, and Deno should just run that.

It's just compiling TypeScript into JS when you import it, and uses tsc to do it. It can load JS just fine as well if you want to use Babel or similar.

I realize that it loads JS.

The issue is that the TypeScript it loads today, it might not load in the future.

My workaround is to use //@ts-ignore above the import, but this is clunky. I just tried Deno and found that TypeScript doesn't support .ts extensions yet.

I would rather have Clojurescript than Typescript, but absolutely, less is more, and it feels like a bad idea to tie implementation of this runtime to another dependency.

My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt.

“C with classes” seemed like a good idea, we were told back in the 80s in school, since garbage collection is impractical. Er, yeah. Worse is better...

GC is impractical in many domains.

And in the 80s it was even more so due to CPU and RAM performance.

I’m a huge TS fan and I agree. Deno is just running tsc for me it seems. So far I don’t see much advantage. It also potentially ties Deno to current trends. TS is pretty dang popular, but what if something else comes along and scoops it?

I read in a comment somewhere else in this post that you can just point deno at JS files to skip the TS compiler. I agree it's probably not a good idea to couple the Typescript version with the runner.

Note that Deno started out as Typescript runtime, it was it's tagline, they added the JavaScript later there.

> TS is pretty dang popular, but what if something else comes along and scoops it?

Earth is rather small, type inferencing dynamic language is really hard. There is simply no other language or team that has achived anything like TS. It's very unlikely that anyone else will do it for JS again. You can just look at amount of work in TS already.

Only thing that can "scoop it" is another language entirely taking off and leaving JS developers in the history. In that case the point becomes useless, it can happen to any runtime for any given language.

A note on Deno and the safety of its V8 bindings:

> All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself.

We'll also have to wait on who will be the first to have a production ready Javascript Engine written in Rust that could replace V8, if you're talking about safety.

Even with the "safe" bindings, you will still get the same C and C++ vulnerabilities found in V8 that will also be present in Deno.

For this sort of problem Rust's safety guarantees don't buy you all that much. If you're generating machine code and implementing a GC that's not the sort of thing that Rust's typesystem can prove correct.

That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.

Well, sure, but a big chunk of the bugs in JRE were in the library, not the code generation or GC.

Speaking of: Neon, a system for writing Node libraries in Rust is pretty cool:

https://neon-bindings.com/

Not sure exactly how much it buys you but I suspect there’s still room for research especially since Mozilla themselves has interest in a Rust JS JIT. I am curious to see if HolyJIT goes anywhere and what kinds of safety improvements it could potentially offer.

Deno plans to not expose V8 internals, unlike node. I do not know where the V8 vulnerabilities came from, but it should decrease the attack surface.

But we have to admit, that most people will be happy enough with a Node.js with browser APIs.

TypeScript is just an extra.

esbuild can compile typescript a couple orders of magnitude faster: https://github.com/evanw/esbuild/issues/81#issuecomment-6250...

though i think it just strips the typescript annotations. but this may be workable if during dev there's some kind of guarantee that the typechecking has already been done.

Massive undertaking is a big understatement. It would be better to not tie into TS/Flow and let one of the two biggest tech companies implement the best, fastest typechecker.

What is the ongoing performance cost of using the official TypeScript compiler for long-running applications? Or is this primarily a concern of startup time for scripts and short-lived programs like CLIs?

AFAIK, tsc is just a compiler, not a runtime. Once you compiled, you're just executing javascript so it only impacts startup time.

ts-node is a runtime able to run TypeScript. It is definitely much much slower at execution, not just at startup time. It's useful for hacking around, I use it as a REPL but even for a dev environment it's faster to use tsc's incremental compilation with a file watcher, and execute the resulting JS

It's purely in the compilation step, V8 executes javascript.

Reply on news.ycombinator.com