Repository navigation
Status / roadmap #1
Description
I was wondering if you could share any thoughts about the status or roadmap of this development?
The reason I ask is that I am pretty excited about the prospect of TypeScript => WebAssembly compilation (see my recent blog post: http://blog.scottlogic.com/2017/10/30/migrating-d3-force-layout-to-webassembly.html), and I am looking to explore this further.
I've noticed that TurboScript is no longer being maintained, and speedy.js is inactive - which means your project is the only active TypeScript => WebAssembly compiler!
Do you have a rough idea of when v.Next might be released? And are there opportunities for contribution?
This project generated a lot of interest when it was initially picked up by HN/reddit/twitter, but I don't think that has translated to many users. However, I do think there is mileage in the concept, and as WebAssembly itself evolved, allowing for GC, etc ... this approach will become more and more relevant.
Activity
alangpierce commentedon Nov 28, 2017
I'd love to contribute as well, and am now more excited about possibilities after reading that blog post. 😄
In my case, I've been working on a faster version of Babel (currently just the JSX transform): https://github.com/alangpierce/sucrase. I played around with AssemblyScript last weekend and the results looked really promising, but (like in the blog post) it was a pain to get everything set up. Now that I'm a little more comfortable with it, happy to be an early adopter or contributor to v.Next if that's helpful. Even stuff like better tutorials, docs, and error messages would be really useful.
dcodeIO commentedon Nov 28, 2017
I've recently been working on adding utilities to binaryen but I must also admit that I lost some of the initial pace. That's mostly because there are some parts that aren't worth implementing yet, e.g., it is unlikely that GC-registered classes will be stored in linear memory at all and it doesn't seem to make a lot of sense to implement a makeshift runtime now just to throw it away again later.
Good to see that there's still some interest, though. If I'd had to pinpoint a roadmap:
At this point we'd have something working that simply doesn't support classes yet.
@ColinEberhardt: Already stumbled upon your blog post a while ago. You are also doing WebAssemblyWeekly, right?
@alangpierce: Yeah, I could need some help here. That's mostly development and testing with an unfinished API at the moment, though.
ColinEberhardt commentedon Dec 1, 2017
Thanks for the response @dcodeIO - you sound busy!
I agree with your point regarding the GC, may as well wait until this is supported in WebAssembly rather than building your own. I do like the way that the current AssemblyScript runtime is very lightweight.
Thanks for sharing your roadmap, I'd love to help out, but doubt I have the time (or the expertise). One area I am interested in is simplifying the interface between the hosting JavaScript and the WebAssembly module - I was really pleased that I was able to re-use TypeScript classes and their serialisation / deserialisation logic into linear memory from both my WebAssembly & JavaScript code. I think this is the sort of thing that could be turned into a more standard utility.
I think AssemblyScript has an interesting future. One of the biggest obstacles to WebAssembly adoption is the languages that target it. Many web developers will want to benefit from more compact distributions, reduced parse / compile / optimise times - and (small) runtime performance gains. However, not many will want to switch to C / C++ / Rust to achieve this.
In an ideal world, a JavaScript developer could simply add types to their code, and target WebAssembly.
Yes, there are a lot of other issues that need to be resolved, e.g. WebAPI access (which appears to be a long way off with WebAssembly), but that is a direction I'd love to see this technology move towards.
Any yes, I do run the WasmWeekly twitter / newsletter. I've not done that sort of thing before, but as I want to keep a close eye on how things are developing, it's very little effort to just write it up once a week :-)
dcodeIO commentedon Dec 4, 2017
Theoretically, it should now be possible to compile the first simple programs. Import/export should mostly work, global exports should work, builtins should work, simple function calls should work.
It's certainly still a rough ride
, not only because there's no command line utility,but the few tests we have already show that at least some things are working.dcodeIO commentedon Dec 6, 2017
As another reference, there now is an unfinished implementation of TLSF as a compiler test. The code looks and feels much like C and the optimized WASM is
far fromnot yet optimal. Makes a good example regarding the current state, though.Quramy commentedon Dec 22, 2017
Hi. I'm loving TypeScript's Language Service and tsserver. Do you have a plan to implement (or migrate) AssemblyScript's Language Service or something like LSP implementation ?
dcodeIO commentedon Dec 22, 2017
I don't have any immediate plans yet because there's still so much other work to do, but that's certainly something I'd love to have as well. For now, I am simply using what TypeScript provides already.
Two options: Either implement a language service specifically for AS or create an additional
aslinttool that sits on top of the language services provided by TS but additionally reports AS specific issues.torch2424 commentedon Jan 31, 2018
Just in case someone else stumbles upon this, there is a Status / Roadmap posted at: https://github.com/AssemblyScript/assemblyscript/wiki/Status-and-Roadmap
dcodeIO commentedon Mar 5, 2018
Closing this issue for now. As noted above, there's this wiki page covering some points, though it certainly needs a rework to outline higher level goals.
Merge pull request AssemblyScript#1 from AssemblyScript/master
Merge pull request AssemblyScript#1 from nearprotocol/near-bindgen
Merge pull request AssemblyScript#1 from willemneal/asconfig
Merge pull request AssemblyScript#1 from MaxGraey/resolution-timer
Merge pull request #1 from btc-vision/closures