Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASM.js compilation target. #375

Closed
electricessence opened this issue Aug 6, 2014 · 4 comments
Closed

ASM.js compilation target. #375

electricessence opened this issue Aug 6, 2014 · 4 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@electricessence
Copy link

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.
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Aug 6, 2014

The vast majority of TypeScript programs cannot be meaningfully compiled into asm.js.

A non-exhaustive list of problems:

  • All TypeScript (or JS) programs assume garbage collection, which asm.js does not have
  • asm.js uses a fixed-size array for dynamic allocation; the required size of this array for an arbitrary program is noncomputable
  • asm.js doesn't natively support things like strings; re-implementing the entire string manipulation library (or rejecting TypeScript programs that use strings, which is basically all of them) is not really feasible
  • Same as prior bullet, but for objects
  • Translating prototypal inheritance to a machine-code equivalent is already the job of JavaScript runtimes -- we're unlikely to improve on their years of work
  • TypeScript allows undefined and null as numeric values; redefining the semantics here would be invasive and complex

For 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.

@electricessence
Copy link
Author

:( 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. :)

@jslegers
Copy link

jslegers commented Jun 22, 2017

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.

@jslegers
Copy link

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.

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Declined The issue was declined as something which matches the TypeScript vision Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests

3 participants