Status / roadmap

[ColinEberhardt]

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.

[alangpierce]

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]

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:

1. Parser: Create test cases for everything, fix issues; think about tokenizing regexp literals
2. Expression compilation: Create test cases for everything (while, for, switch and whatnot), fix issues
3. Function calls: Validate parameters, resolve and generate generic overloads, create test cases (did some work on this lately)
4. Implement builtins (that is functionality defined in assembly.d.ts).

At this point we'd have something working that simply doesn't support classes yet.

5. Refine what we have so it's usable as an alternative to C.
6. Think about classes again.

@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]

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]

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]

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 from not yet optimal. Makes a good example regarding the current state, though.

[Quramy]

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]

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 aslint tool that sits on top of the language services provided by TS but additionally reports AS specific issues.

[torch2424]

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]

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.