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

Suggestion: Compilation targets other than JavaScript #9202

Closed
paul-go opened this issue Jun 16, 2016 · 14 comments

Comments

@paul-go
Copy link

commented Jun 16, 2016

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

This comment has been minimized.

Copy link

commented Jun 16, 2016

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

This comment has been minimized.

Copy link

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

This comment has been minimized.

Copy link

commented Mar 15, 2017

@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

This comment has been minimized.

Copy link
Member

commented Mar 16, 2017

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

This comment has been minimized.

Copy link

commented Mar 16, 2017

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

This comment has been minimized.

Copy link

commented Mar 16, 2017

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

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

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

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

This comment has been minimized.

Copy link

commented Mar 16, 2017

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

This comment has been minimized.

Copy link

commented Mar 16, 2017

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

Yes exactly What I wanted to mean.

@ericmdantas

This comment has been minimized.

Copy link

commented Jun 6, 2017

Maybe worth taking a look:

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

@MaxGraey

This comment has been minimized.

Copy link

commented Jun 11, 2017

AssemblyScript, TurboScript and Speedy.js Playground: Assembleash

Github Project

@piq9117

This comment has been minimized.

Copy link

commented Aug 11, 2017

@styfle

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2017

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

@grahamehorner

This comment has been minimized.

Copy link

commented Feb 13, 2018

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

@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
10 participants
You can’t perform that action at this time.