Deno: Compile-to-javaScript (still) is turn-away

[jayarjo]

This might not be the best place to ask this, but I'm not sure where if not here. I've starred deno a while ago - year maybe more, but compilation-to-JavaScript step is basically a turnaway point. I know there are lots of benefits in using deno over node, but the only one that matters I think is just that - bypassing JavaScript altogether. How feasible is that? Is there anyone working on that currently? Why not compile directly to WebAssembly for example?

[actual-size]

Google experimented with this idea with v8, but my guess is that it's a lot of work with basically no benefit. Nowadays JS is performant enough for most work and when it's not WASM can be used.

[jayarjo]

Google experimented with this idea with v8, but my guess is that it's a lot of work with basically no benefit. Nowadays JS is performant enough for most work and when it's not WASM can be used.

I mean then deno has no real benefit over node.

[kitsonk]

Depends on what you consider a benefit. Raw performance is not the only factor. Lots of people assume you can take JavaScript and wave a magic wand and run it faster in Web Assembly. That is simply not true. JavaScript is a loosely typed, garbage collected language, it needs a whole bunch of infrastructure to work at all. That has been honed for years by v8. You would effectively have to reimplement huge parts of v8 in Web Assembly to have general, ECMAScript complaint JavaScript to run. V8 is about as fast as you can get if you are authoring JavaScript.

It was never Deno's goal to be faster than Node.js. If you want something faster, don't write JavaScript.

All that being said, this isn't a discussion forum. It is an issue tracker. In addition there are several other "issues" here on very similar topics. It isn't nice to add to that noise.

[jayarjo]

I searched and then created this issue, I didn't find any open or active threads. There was just one that mentioned Liftoff (what a name!) and it was closed years ago. I consider this topic an issue. A huge issue to be specific. A whole elephant stomping on top of this project.

I'm not talking about making JavaScript faster or making it to compile into WebAssembly. I'm talking about dropping it altogether. And make TypeScript compile to WebAssembly. That is if deno is oriented on future. JavaScript is a walking dead basically.

In fact I'm pretty sure that every other person visiting this project is under impression that that's what it's really about.

[aduh95]

And make TypeScript compile to WebAssembly.

I think you want to check out AssemblyScript.

Deno is a JavaScript runtime, I don't know if it's "oriented on future", but this is the way it is. If you don't like it, then don't use it; I personally love it.

[jayarjo]

@aduh95 It's not about me. It's about why not AssemblyScript for this project?

[aduh95]

It's about why not AssemblyScript for this project?

Nothing's stopping you from using AssemblyScript with deno, as it supports WebAssembly already.
Now if you are asking for built-in support for AssemblyScript, that's something else. If you feel strongly about this, I encourage you to work on an implement and open a PR, but I have to warn you it may not be a popular-enough feature to have it land in Deno core if it makes the executable larger.

The AssemblyScript FAQ goes in details on the reasons why you shouldn't expect JavaScript to be gone anytime soon and how WASM is not _always_ better, faster, stronger. It is harder though.

[caspervonb]

Short answer.

How feasible is that?

It's not, TypeScript is not sound.

Is there anyone working on that currently?

There's a few dead projects around, like StaticScript, llvm-ts, mints, etc.

Why not compile directly to WebAssembly for example?

TypeScript isn't sound.

---

Anyway, I'm just chiming in because I've played around with this idea before; it was around the time Deno was first announced so I had Deno in the back of my mind as a possible targetable runtime environment.

The thing is; while it was a fun experiment it was a case of "I spent too much thinking if i could, without questioning if I should". Once you're compiling a strict sound subset of TypeScript you've effectively created a new language that kinda looks like TypeScript but isn't actually TypeScript and can't interop with any existing code without porting; at this point it's better to just reach for an existing sound language with a solid ecosystem which there are many to choose from.

Take AssemblyScript for example; while it kind of looks like TypeScript it is "definitely not a TypeScript to WebAssembly compiler"; while this tagline is somewhat tongue in cheek there's a lot of truth to it as the language has more in common in terms of semantics with C than TypeScript.

[jayarjo]

@caspervonb thanks for the insight. Appreciate it. Lots of informational bits that I can follow. But having that, I don't understand why even bother with deno in first place. There's that nice, fast, well established, reliable and mature node. And it can be used with JavaScript, or TypeScript, or WebAssembly... you name it, basically same arguments you've just used.

[lucacasonato]

A reason to use Deno would be the new take on module handling, use of modern features like Promises, the security by default, ect. If you don't see an immediate benefit in using Deno that is fine. Nobody is forcing you to use Deno. If you want to stick with Node, no one is stopping you. Node will not go anywhere, it will be used by many people for many years to come.

[runny-yolk]

I'm not talking about making JavaScript faster or making it to compile into WebAssembly. I'm talking about dropping it altogether. And make TypeScript compile to WebAssembly. That is if deno is oriented on future. JavaScript is a walking dead basically.

TS compiles to JS, as we all know, and the way v8 (Deno's JS runtime) works is by compiling JS to machine code - or at least, it used to, but these days uses a mixture of bytecode and machine code. Some further reading

So it seems to me, that Deno already does what you want, just the compiler is part of the runtime, instead of doing the usual thing, of having seperate compilation and running steps.

[jayarjo]

At the end of the day I think I simply need something with TypeScript syntax to survive the day when JavaScript will end.

[bartlomieju]

Closing as discussion seems to be settled