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)
Living under a rock here 👋
Actually I was sort of aware of this but not paying close attention at all. This is definitely promising.
Hahaha :) well you just escaped the rock
Relevant for those unaware about Deno.
10 Things I Regret About Node.js
Nick Taylor (he/him) ・ Jun 7 '18 ・ 1 min read
Would love to link this directly in article; only if I can find the edit button :P
If you want to link it directly, you can use this
Don't have edit option :(
To edit an article here you have to go to your dashboard.
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.
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.
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.
"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:
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
evalorrequire) -- 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:
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 therequirefile 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.
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.
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 😂😂
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
Agreed
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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.