Skip to content

ASM.js compilation target. #375

Closed
Closed

Description

@electricessence

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.

Activity

  1. RyanCavanaugh commented on Aug 6, 2014

    @RyanCavanaugh
    Member

    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.

  2. electricessence commented on Aug 15, 2014

    @electricessence
    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. :)

  3. jslegers commented on Jun 22, 2017

    @jslegers

    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.

  4. jslegers commented on Jun 22, 2017

    @jslegers

    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 Ingvar Stepanyan (@RReverser) for pointing me in the direction of these two languages.

  5. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DeclinedThe issue was declined as something which matches the TypeScript visionOut of ScopeThis idea sits outside of the TypeScript language design constraintsSuggestionAn idea for TypeScriptToo ComplexAn issue which adding support for may be too complex for the value it adds

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions