Closed electricessence closed 10 years ago
The vast majority of TypeScript programs cannot be meaningfully compiled into asm.js.
A non-exhaustive list of problems:
undefined
and null
as numeric values; redefining the semantics here would be invasive and complexFor a statically-typed language that compiles to asm.js or other native targets, I would recommend Rust, Zig, Go, ReasonML, or even C/C++ if you must
if someone wants to give this a go, once our compiler API is stabilized and published, we'd be happy to help people understand how to use that API for parsing or type information.
:( Yeah, you're right, I looked deeper into it and sadly, it's not ideal. But I could dream for a second. Thanks for your thorough response. :)
Personally, I don't see much of a benefit of using TypeScript or Flow instead of JavaScript. Especially now that the ES6 standard also added class-based object-oriented programming to the language, all you'd really get from adopting TypeScript or Flow today would be the addition of static typing... and interfaces. Besides making your code look more like eg. Java code, I really don't see the benefit at all... except when using static typing to optimize the JavaScript code it produces... which is where asm.js comes in.
In environments where high performance is essential (eg. 3D rendering in the browser for browser games or GIS web apps), the current approach is to write the core code (that does the heavy lifting) in C/C++ (compiled to asm.js) and everything else in JavaScript. That means you need a really good understanding of both JavaScript (which I do) and C/C++ (which I don't) to be able to write proper code or maintain existing code for such apps, both inside and outside of the the core code.
How great would it be to be able to use one - TypeScript - codebase for such projects and compile to asm where possible and to regular JavaScript where not possible? Or to put it differently : how great would it be for a JavaScript programmer to be able to program in highly readable superset of JavaScript and have it compiled - where possible - to a highly optimized subset of JavaScript?
It seems like a win-win for everyone, really, especially if you leave it optional whether or not to compile to asm.js for developers who don't work in high performance environments and prefer readability to performance.
IMO, compilation of (a subset of) TypeScript to asm.js would be major improvement over TypeScript as it exists today. For me, it would totally be a game changer and make the difference between supporting and not supporting the adoptation of TypeScript - or Flow for that matter - at the company I work for...
While I understand that TypeScript is not intented to be compiled to asm.js, C/C++ or WebAssembly (and I expect that), the ability to export a language like Flow or TypeScript to typed AST in some way or another would be a good first start. With the TypeScript core devs not interested in this feature, it would at least open up the possibility for other teams to implement TypeScript to WebAssembly, TypeScript to C/C++ or TypeScript to asm.js conversion wherever possible.
Those also interested in converting staticly typed variations of JavaScript to asm.js, WebAssembly or C might want to take a look at ThinScript or TurboScript.
ThinScript compiles to JavaScript, WebAssembly, and C. TurboScript compiles only to JavaScript and WebAssembly.
Both languages have been inspired by TypeScript.
I'd like to thank @RReverser for pointing me in the direction of these two languages.
Original thread: https://typescript.codeplex.com/discussions/438243 Also: http://typescript.codeplex.com/workitem/852
Not sure how this should be approached, but I have some suggestions and for some of us that could really use this right about now, we may need to start another repo/branch to get something working.
1) Ideally, it's just another target. You set --target asm and it just works if the code doesn't break too many rules. 2) Unless someone already has done this (and can paste a link here), we can start another transpiler that takes standard TSC output and convert it to asm format. If that goes well, I don't see why the TSC couldn't import that code.