DEV Community

Cover image for It's time for Typescript Native
Zohaib Sibte Hassan
Zohaib Sibte Hassan

Posted on

It's time for Typescript Native

Unless you have been living under a rock; you must be aware of the project Deno. Yes it's the project by the same guy who wrote Node.js and according to him it's his redemption from mistakes he did in Node.js:

While project is written in Rust and it uses the same v8 engine under the hood. He made one interesting choice this time around. He selected Typescript as a primary language instead of JS.

Now is it a good or bad choice is a separate debate and only time will tell. I personally believe typed languages have more milage than dynamic languages both in terms of perf tuning and developer scalability. One might disagree; but after the Node.js hype is dead we can clearly see players like Golang and mid-evil dinosaurs like Java/C++/C/C# still holding top spots.

While browsing through Deno's source code I had a thought about how about if Deno can pre-compile TS projects into single binary like Go does? How about not having to rely on JIT and complex pipeline of V8 at all? If somebody writes strictly typed code we can benefit a lot from type hinting that Typescript has and still keep the nice features.

While somebody in Microsoft is struggling to find a feature that can get him his next promotion, I am wishing for something else. With CLR now cross-platform drop the C# ball and write us a Typescript Native compiler. In my opinion Microsoft has better odds of success with a huge community that already understands and writes Typescript! Microsoft can go head on with Golang and increase chances of .Net core being more well adopted than where it is right now. I will drop Golang if somebody can give me a nice syntax like Typescript with all the performance goodness that I can get from Golang.

Top comments (26)

Collapse
 
ben profile image
Ben Halpern

Unless you have been living under a rock; you must be aware of the project Deno.

Living under a rock here 👋

Actually I was sort of aware of this but not paying close attention at all. This is definitely promising.

Collapse
 
zohaibility profile image
Zohaib Sibte Hassan

Hahaha :) well you just escaped the rock

Collapse
 
nickytonline profile image
Nick Taylor
Collapse
 
zohaibility profile image
Zohaib Sibte Hassan

Would love to link this directly in article; only if I can find the edit button :P

Collapse
 
nickytonline profile image
Nick Taylor

If you want to link it directly, you can use this

{% link https://dev.to/nickytonline/10-things-i-regret-about-nodejs-14m3  %}
Thread Thread
 
zohaibility profile image
Zohaib Sibte Hassan

Don't have edit option :(

Thread Thread
 
michaeljota profile image
Michael De Abreu

To edit an article here you have to go to your dashboard.

Collapse
 
jochemstoel profile image
Jochem Stoel

I would like to take a slight detour and say that you can create a TypeScript native executable runtime thingy yourself with node.

Initialize a Node application, install the ts-node package in your application folder (not global) and let your main script call the dist/bin.js script of ts-node.

Then build the app to an executable for your desired platform.

What you end up with is a typescript.exe that behaves like Node but speaks TypeScript. Do not pass arguments to get a typescript REPL, otherwise run the file.

Collapse
 
kepta profile image
Kushan Joshi

I believe sticking to Web assembly would be a pragmatic solution instead of writing a native compiler. Check out this project github.com/AssemblyScript/assembly... which lets you write a subset of Typesvript to target WASM.

Collapse
 
jvanbruegge profile image
Jan van Brügge

I am not sure why you would want Typescript. Sure it's better than Javascript, but standing alone it's still awful. The typesystem gets more hacky with every release (conditional types? WTF?) and it still carries the warts of Javascript.

If I want to target native, and want a typed language, O would either look into Haskell or Rust.

Collapse
 
speculative profile image
Jeffrey Tao

"Typescript Native" is a bit of a strange thing to ask for, in my humble opinion, because it's roughly the same as compiling Javascript. Compilation processes roughly fall into two categories:

  1. "Ahead of Time" compilation to native machine code
  2. "Just in Time" compilation at run-time

Typescript and Javascript fall into the 2nd category. At run-time in every javascript engine, the source code is JITed before execution begins. As far as I'm aware, this is the most straightforward way to compile javascript, which may mutate its code during execution (such as with eval or require) -- new bits of code can simply be JITed during execution. Having these features means that the execution context must have access to a javascript compiler/interpreter.

So I think there are two things at play in your suggestion here:

  1. Emitting a single executable file
  2. Performance improvement

With respect to emitting a single executable file, if this is your only goal, you can accomplish it by generating an executable containing a Javascript runtime (like V8). There is precedence for things like this (such as py2exe) but they're normally concerned with portable distribution of software to consumers who may not have the relevant runtimes intstalled. Obviously, this is not a particularly satisfying solution and you're essentially just wrapping up the runtime with your source code as the data section of the executable.

As far as performance is concerned, initial JIT to start running can be significant (depending on the size of your program). Ahead of time compilation could potentially solve this, although there are multiple relative levels of performance cost at play: require() time (mostly due to synchronous file I/O), parse/compilation time. You can actually improve the require file I/O time drastically by using a javascript bundler (webpack, parcel), since it will combine all of your scripts into a single file.

Finally, I think it's important to consider that Typescript's stated goal is to be a strict syntactical superset of Javascript, so removal of standardized features in order to accommodate ahead of time compilation seems unlikely for the official Typescript project. There is asm.js, which is the subset of javascript which would probably allow for ahead-of-time compilation.

Collapse
 
gurukyuu profile image
Vamsi Vishnubhotla

I sympathize with your desire for native performance, but the JS family of languages (Typescript, Dart, etc.) are intentionally dynamic and that offers developers a number of features that are unavailable for statically compiled languages, such as stateful hot-reload.

Google has done some good work with Dart in that their VM can do AOT or JIT compilation depending on whether you're in production or development environments. It seems like this might be what you want with Typescript. I would look into Dart. It might offer exactly what you're looking for.

Collapse
 
ollydixon profile image
Oliver Dixon

Yeah but Dart still sucks, I mean it doesn’t even have optionals and many other basic features designed to help developers. I write Flutter apps daily and we’re seeing unnecessary null pointers that could be avoided with these simple language features.

I love TypeScript, I think it’s one of the best languages out there by far. If you’re writing vanilla JS and not syncing models with your web apps, you’re not a developer 😂😂

Collapse
 
konstardiy profile image
Konstantin Isaev

I personally more interested in compiling typescript into WebAssembly instead of pure "nativization".
I understand how it is hard to do.
Have you seen how CLR IL code with generic and async/ienumerable functions look like? It is a less elegant thingy. And CLR has MUCH richer instructions set than WebAssembly.
I think we will have to wait for WebAssmbly instructions enrichment with alloc_str concat_str slice_str alloc_arri8 createObj callMtd getProp setProp cast_intf add_cls add_intf etc.
Or if someone will implement these instructions using js or another assembly to be referenced as importables and runtime for actual app-specific assemblies
These in

 
zohaibility profile image
Zohaib Sibte Hassan

Agreed

Collapse
 
bashery profile image
bashery

Good post. Thank you
In my opinion nothing can replace golang
golang is special. typescript native is only another kotlin native or other Swift. I hardly find a difference.
Maybe vlang. He is on the way to keeping his promises

 
zohaibility profile image
Zohaib Sibte Hassan

Seriously WTF; I gave up almost on it

Thread Thread
 
nickytonline profile image
Nick Taylor

There's an EDIT POST button beside the title of your article, e.g.

Thread Thread
 
zohaibility profile image
Zohaib Sibte Hassan

Bad design!!! It was right in front of my eyes and the cognitive load made me ignore it.

Collapse
 
michaeljota profile image
Michael De Abreu

Please notice I open an issue suggesting this as I find it a very interesting idea.

github.com/dotnet/coreclr/issues/1...

I mention your post as the original idea, and maybe you can explain better what would be the advantages for the community of using Typescript in a native runtime.

Collapse
 
teebot profile image
Thibaut Nguyen • Edited

Typescript Native on .NET would be so similar to C# (Anders Hejlsberg being behind both of them) why bother? .NET is also JITted

Collapse
 
zohaibility profile image
Zohaib Sibte Hassan

I think there is a AOT support github.com/dotnet/corert. I think the attraction I am pointing out is huge developer community (larger than C#) and existing ecosystem.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

I think Microsoft have been working Bosque.

github.com/microsoft/BosqueLanguag...

Collapse
 
heyjonr profile image
Jonathan Rowley 👨🏻‍💻

Did a little test for TypeScript to create a Windows Forms app. Wishing we had a .net core/standard compiler now... twitter.com/heyjonr/status/1124396...

Some comments may only be visible to logged-in visitors. Sign in to view all comments.