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 accordi...
For further actions, you may consider blocking this person and/or reporting abuse
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
Seriously WTF; I gave up almost on it
There's an EDIT POST button beside the title of your article, e.g.
Bad design!!! It was right in front of my eyes and the cognitive load made me ignore it.
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.
Typescript Native on .NET would be so similar to C# (Anders Hejlsberg being behind both of them) why bother? .NET is also JITted
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.
I think Microsoft have been working Bosque.
github.com/microsoft/BosqueLanguag...
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...
Hoping the sme here
this project is very small, but it's a TS Native Compiler!
github.com/ASDAlexander77/TypeScri...