Suggestion: Compilation targets other than JavaScript

[paul-go]

Feel free to close this issue under the grounds of "outrageously out-of-scope". I wasn't able to find any other information on this subject, but I'm sure I'm not the first to raise the issue.

TypeScript's typing seems like a natural fit for compilation targets such as the .NET CLR or LLVM / WebAssembly. Of course this would likely involve operating against a subset of the TypeScript language to make it less dynamic and more compiler-friendly.

This seems to me like a good move to ensure the continued growth of the language. Is there any support for such a project within the TypeScript team, Microsoft, or elsewhere?

[mhegazy]

There is no such support that I am aware of.

WebAssembly as it stands today is not a good target for TS/JS as it does not have manged memory support; it would be ideal for a c/c++ language that manages its own memory.

As you noted, this is out of scope for the the TS project. However, the compiler API allows for skipping emit, and you can implement your emitter to write to any other language.

There is a TS2Dart tool in https://github.com/angular/ts2dart that might be relevant.

[matthew-dean]

I would think this would be an end-goal of TypeScript. It would mean that developers who adopted TypeScript today could eventually be distributing the code of tomorrow, i.e. Web Assembly. It also would mean that until browser support of Web Assembly had landed in all browsers, developers could choose both targets, JavaScript and WASM.

If it's out of scope, perhaps it should be reconsidered to be entirely within the scope. This would be a game changer for TypeScript.

[RyanCavanaugh]

JS engines already turn JS code into assembly at runtime, and can do a very good job of it because they have a complete runtime profile. There's really no obvious upfront gains to be had from translating a working JS program into WASM - if there were, that's what browsers would already do with JS code in the first place. Existing JS patterns around virtual method dispatch, polymorphism, objects, etc, make it virtually impossible to turn directly into bytecode even with type information.

If you're looking for a typed language with the proper restrictions in place to be able to generate explicit-memory-managed bytecode-ready IL: C

[ganeshkbhat]

@RyanCavanaugh As per my understand goes WASM is faster then Javascript or TS compiled to Javascript. Its a different thing if TS does not goal up this compiler feature to WASM due to current incapabilities of WASM to support objects.

@ TS Team: But its going to be a pain area for Javascript sooner, especially enterprise apps that run huge TS or JS or for that matter even Coffeescript code bases. Frankly, it seems the code bases are getting bigger (definitely) day by day with transpilation based languages as well. Seems there's resistance at a lot of places to get things up and going (which I feel is possible). Sorry for trying to push hard. But things might need changes here. Please share your thoughts on it.

Update: I am not sure if this work url makes sense for any support from the support request in NodeJS team on --expose-wasm on WASM tests here

https://github.com/nodejs/node/tree/master/deps/v8/test/mjsunit/wasm

[RyanCavanaugh]

As per my understand goes WASM is faster then Javascript

The WASM devs, in the thread you linked, clarified this:

There is no secret nor any magic. Wasm is "faster than JavaScript" because it is a much simpler language that is much closer to hardware. JavaScript is a complicated language that has to do many expensive things during execution. It wouldn't magically get faster by compiling it to native code through Wasm instead of directly.

There's no level of "pushing" here that will somehow turn this into a tractable problem. Just to repeat myself: Existing JS patterns around virtual method dispatch, polymorphism, objects, etc, make it virtually impossible to turn directly into bytecode even with type information. Even if it were somehow possible, any solution would almost certainly have to work with arbitrary non-typed JS as well, at which point you may as well use whatever magic make-JS-faster perpetual motion machine someone invented.

I don't want to sound rude here but if the TS devs tell you it can't really happen and the WASM devs tell you it can't really happen... why come here and 👎 me for telling you as such? Rarely in the history of software have developers overestimated the difficulty of a problem, after all.

[matthew-dean]

JavaScript is a complicated language that has to do many expensive things during execution. It wouldn't magically get faster by compiling it to native code through Wasm instead of directly.

I don't believe anyone is asking to compile JavaScript into WASM. The question is about TypeScript at some point in the future, which would rely, of course, on an expanded feature set of WASM. TypeScript can already allow a developer to restrict what patterns are allowed, which, on compilation, limits the amount of polymorphism of function results, for example. That's not to say it's an easy problem by any stretch of the imagination. But, theoretically, at a point when WASM can support some basic features of a few more languages, it's conceivable that TypeScript could continue on its course of a "JavaScript-like" syntax that has a strict and predictable compilation target that's compatible with WASM. If TypeScript can throw compilation errors for illegal type-casting before converting to JavaScript, it could theoretically do the same with objects and patterns incompatible with WASM 2.0, etc.

It's a long goal far from the present, but right now the TypeScript workflow is positioned as the closest language where that idea is even remotely possible, where it could guide a developer into highly-optimized patterns which compile into a fast compilation and execution format. Nothing else really targets the web platform in a way that forces the developer to adapt and enforce strict patterns, or generates strict JS patterns based on language-specific features of TypeScript.

That said, I trust the language designers and WASM engineers who say it's kind of a moon shot. Perhaps just wishful thinking at this point. But.... from what I understand of the long-term goals of WASM, not necessarily impossible.

[ganeshkbhat]

I have looked across some codes seriously here. There are four things I would want to point out:

1. WASM support is incapable since Object support is not there.

currently, it is not possible to allocate objects inside asm.js / webassembly. In asm.js and webassembly, all JavaScript operations will use one big typedarray to store and load there values. Creating JavaScript objects (e.g. var obj = {a: 1, b: 'test'}) and arrays (e.g. var a = [];) is not possible inside webassembly since there is no object support yet. This is a design decision of the Minimal Viable Product made to get webassembly support in all major browsers as soon as possible

2. WASM proposals are on the move but lack traction.

are working on a proposal for object support in webassembly, but that will take some time to land as a specification and an implementation in all major browser

3. There are basic/partial tests around it by Node.JS. What can be tested can be reverse engineered, and optimized. I definitely see conflict and divergence of interests in web environments here like it was during the start of the web.

4. No one could have thought of Type adherence in the first place and TS team could think of it. So will definitely want to disagree here. If there is one port of Javascript that can get quite easily get compiled to WebAssembly that could be Typescript frankly. I am not talking about Javascript to WebAssembly. Even I see an issue there with lack of type adherence support; and thinking of all use case might really get difficult. Marking it off as out of scope helps no one. A problem accepted is problem half solved. May be the there needs some remapping of goals by some group (if not as a immediate goal but in the near future). I hope you agree to this point at the least.

[matthew-dean]

No one could have thought of Type adherence in the first place and TS team could think of it. So will definitely want to disagree here. If there is one port of Javascript that can get quite easily compiled to WebAssembly that could be Typescript frankly. I am not talking about Javascript to WebAssembly.

Similar to what I said although I'm not sure about the "quite easily". But I would say that TypeScript support of WASM is likely much easier than any other language transpiled to JavaScript, because of the way its designed.

[ganeshkbhat]

WASM is likely much easier than any other language transpiled to JavaScript

Yes exactly What I wanted to mean.

[ericmdantas]

Maybe worth taking a look:

https://github.com/dcodeIO/AssemblyScript
A subset of TypeScript that compiles to WebAssembly.

[MaxGraey]

AssemblyScript, TurboScript and Speedy.js Playground: Assembleash

Github Project

[piq9117]

is this related? https://github.com/rsms/wasm-util

[styfle]

Another somewhat related project is walt.
See ballercat/walt#11 from a comparison of walt to AssemblyScript.

[grahamehorner]

This has become more relevant as the of the aspnet/blazor project 🤔