www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Spasm - webassembly libary for single page applications

reply Sebastiaan Koppe <mail skoppe.eu> writes:
I like to announce Spasm https://github.com/skoppe/spasm

It is a webassembly library to develop single page applications 
and builds on my previous work 
(https://forum.dlang.org/post/eqneqstmwfzugymfewqo forum.dlang.org).

It generates fast and small webassembly binaries. The example 
todo-mvc is only 5995 bytes (wasm) + 2199 bytes (html+js) when 
gzipped, and loads pretty fast 
(https://skoppe.github.io/spasm/examples/todo-mvc/)

Spasm can be used with dub and only requires a recent version of 
ldc. See the readme on github how to get started.

The library includes a webpack bootstrap project to build a 
production ready web page.

Spasm is written in betterC.

Next steps are:

- more js host bindings (xhr, localstorage, etc.)
- memory deallocation
- gather an angry mob to make phobos more betterC compatible ;)
Oct 12
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/18 3:43 PM, Sebastiaan Koppe wrote:
 I like to announce Spasm https://github.com/skoppe/spasm
 
 It is a webassembly library to develop single page applications and 
 builds on my previous work 
 (https://forum.dlang.org/post/eqneqstmwfzugymfewqo forum.dlang.org).
 
 It generates fast and small webassembly binaries. The example todo-mvc 
 is only 5995 bytes (wasm) + 2199 bytes (html+js) when gzipped, and loads 
 pretty fast (https://skoppe.github.io/spasm/examples/todo-mvc/)
 
 Spasm can be used with dub and only requires a recent version of ldc. 
 See the readme on github how to get started.
 
 The library includes a webpack bootstrap project to build a production 
 ready web page.
 
 Spasm is written in betterC.
 
 Next steps are:
 
 - more js host bindings (xhr, localstorage, etc.)
 - memory deallocation
 - gather an angry mob to make phobos more betterC compatible ;)
OK, this is pretty cool. I need to start checking out webasm. -Steve
Oct 12
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
Nifty, I'll have to look into this. Any idea what it would take to get 
this doing some WebGL? (Or playing audio?) Or is this more for HTML-ish 
sorts of stuff?

What are the main current limitations?
Oct 12
next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 13 October 2018 at 04:34:28 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Nifty, I'll have to look into this. Any idea what it would take 
 to get this doing some WebGL? (Or playing audio?) Or is this 
 more for HTML-ish sorts of stuff?
This is more focused on HTML rendering, but you can do anything that you can do from JS, you just have to write JS glue code. WebGL is based on and follows the OpenGL ES (Embedded Systems) spec, which is a subset of OpenGL. So if you have the API definitions you are already half done. The other half is writing that in JS and calling the actual WebGL. If you want to do it right now you can use vladimir's dscripten-tools project, which is based on emscripten. I just don't like emscripten because it has a complex toolchain (D->LDC->(patched)LLVM->asm.js->binaryen->wasm) and results in bloated code.
Oct 13
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 13 October 2018 at 04:34:28 UTC, Nick Sabalausky 
(Abscissa) wrote:
 What are the main current limitations?
Mainly that it is written in betterC, which is quite the limitation if you are used to freely call anything from phobos, or expect the GC to clean up. Also I currently don't free memory.
Oct 13
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Friday, 12 October 2018 at 19:43:25 UTC, Sebastiaan Koppe 
wrote:
 I like to announce Spasm https://github.com/skoppe/spasm

 It is a webassembly library to develop single page applications 
 and builds on my previous work 
 (https://forum.dlang.org/post/eqneqstmwfzugymfewqo forum.dlang.org).
I must say even at this stage this library is awesome! Good job! Keep up with the good work! :)
Oct 13
prev sibling next sibling parent reply Bogdan <szabobogdan yahoo.com> writes:
On Friday, 12 October 2018 at 19:43:25 UTC, Sebastiaan Koppe 
wrote:
 I like to announce Spasm https://github.com/skoppe/spasm

 It is a webassembly library to develop single page applications 
 and builds on my previous work 
 (https://forum.dlang.org/post/eqneqstmwfzugymfewqo forum.dlang.org).

 It generates fast and small webassembly binaries. The example 
 todo-mvc is only 5995 bytes (wasm) + 2199 bytes (html+js) when 
 gzipped, and loads pretty fast 
 (https://skoppe.github.io/spasm/examples/todo-mvc/)

 Spasm can be used with dub and only requires a recent version 
 of ldc. See the readme on github how to get started.

 The library includes a webpack bootstrap project to build a 
 production ready web page.

 Spasm is written in betterC.

 Next steps are:

 - more js host bindings (xhr, localstorage, etc.)
 - memory deallocation
 - gather an angry mob to make phobos more betterC compatible ;)
Awesome work! I remember that, at some point the https://glimmerjs.com/ authors wanted to write their vm in rust for better performance. It looks like D is a new option for such projects. Bogdan
Oct 13
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 14 October 2018 at 06:03:10 UTC, Bogdan wrote:
 Awesome work! I remember that, at some point the 
 https://glimmerjs.com/ authors wanted to write their vm in rust 
 for better performance. It looks like D is a new option for 
 such projects.

 Bogdan
Thanks, a lot of credits go to LDC for supporting the webassembly backend of LLVM. I thought about doing a VM as well, specifically because I was afraid of the performance penalty of switching a lot between js and wasm. The idea was to emit all dom operations into one bytebuffer (possibly at compile-time) and then instruct js to execute that. It turns out jumping between wasm and js isn't really a big deal (at least not anymore), so I ditched that idea to keep things simple. Plus, there is a good chance that in the near future wasm will be able to call the browsers' api directly.
Oct 14
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Sunday, 14 October 2018 at 19:04:51 UTC, Sebastiaan Koppe 
wrote:
 It turns out jumping between wasm and js isn't really a big 
 deal (at least not anymore), so I ditched that idea to keep 
 things simple.

 Plus, there is a good chance that in the near future wasm will 
 be able to call the browsers' api directly.
Precisely, that is why I like this approach. Good job.
Oct 15
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Sunday, 14 October 2018 at 19:04:51 UTC, Sebastiaan Koppe 
wrote:
 On Sunday, 14 October 2018 at 06:03:10 UTC, Bogdan wrote:
 Awesome work! I remember that, at some point the 
 https://glimmerjs.com/ authors wanted to write their vm in 
 rust for better performance. It looks like D is a new option 
 for such projects.

 Bogdan
Thanks, a lot of credits go to LDC for supporting the webassembly backend of LLVM. I thought about doing a VM as well, specifically because I was afraid of the performance penalty of switching a lot between js and wasm. The idea was to emit all dom operations into one bytebuffer (possibly at compile-time) and then instruct js to execute that. It turns out jumping between wasm and js isn't really a big deal (at least not anymore), so I ditched that idea to keep things simple.
I saw a recent announcement by the Firefox devs on some massive improvements they've made in the js-wasm switching speed. Its negligible for most cases...unless probably something crazy. Its was very fast...especially for a benchmark of 100 million calls with Math.random() https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/
 Plus, there is a good chance that in the near future wasm will 
 be able to call the browsers' api directly.
Have you seen this? https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API I'm not sure how limited it is though.
Oct 17
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 12 October 2018 at 19:43:25 UTC, Sebastiaan Koppe 
wrote:
 I like to announce Spasm https://github.com/skoppe/spasm

 It is a webassembly library to develop single page applications 
 and builds on my previous work
This is really interesting. I don't do web development myself and haven't been doing hobby programming, but I like the idea of of webasm. It would be cool if D provided the easiest way to develop webasm first to see if it could claim that market.
Oct 15
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 16 October 2018 at 03:23:21 UTC, Jesse Phillips wrote:
 It would be cool if D provided the easiest way to develop 
 webasm first to see if it could claim that market.
If you have some minutes to spare it would be great if you could try it out. It should only take 10min to render your first divs, otherwise something is wrong. The major hurdle with any wasm dom framework is that there are no standard components to build on (like dropdowns, drag-n-drop, input validations, notifications, etc.), nor any css frameworks (like material ui, bootstrap). So'll need to build everything from scratch, and no sane person is likely to do that. What might be an option is to try to integrate with other wasm libraries out there, so at least we can use their components. But everyone does his own thing, so integrating is going to be hard as well.
Oct 16
parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 16 October 2018 at 07:57:12 UTC, Sebastiaan Koppe 
wrote:
 On Tuesday, 16 October 2018 at 03:23:21 UTC, Jesse Phillips 
 wrote:
 It would be cool if D provided the easiest way to develop 
 webasm first to see if it could claim that market.
If you have some minutes to spare it would be great if you could try it out. It should only take 10min to render your first divs, otherwise something is wrong. The major hurdle with any wasm dom framework is that there are no standard components to build on (like dropdowns, drag-n-drop, input validations, notifications, etc.), nor any css frameworks (like material ui, bootstrap). So'll need to build everything from scratch, and no sane person is likely to do that. What might be an option is to try to integrate with other wasm libraries out there, so at least we can use their components. But everyone does his own thing, so integrating is going to be hard as well.
A common use case for wasm is to port C++ native apps to web. e.g. is the recent autoCAD web app which does almost everything the desktop app can. That's the only reason to IMO do stuff in wasm. Games, productivity software, etc...performance. Spasm might just be perfect for that kind of stuff
Oct 17
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 17 October 2018 at 19:07:16 UTC, aberba wrote:
 A common use case for wasm is to port C++ native apps to web. 
 e.g. is the recent autoCAD web app which does almost everything 
 the desktop app can. That's the only reason to IMO do stuff in 
 wasm. Games, productivity software, etc...performance. Spasm 
 might just be perfect for that kind of stuff
There are issues getting the current GC ported to webassembly, so it is hard to port D code to wasm. That is one of the reasons why spasm has taken the betterC approach. But remember, spasm is just a library to render and update html, and to respond to dom events. It won't help you in anyway to port something to wasm. If you really want to port existing D code to wasm you either need to rewrite that in betterC or port druntime, which includes writing a precise GC. Dscripten-tools is a move in that direction. The reason spasm exists is because I wanted to optimise web application's rendering code at compile-time, to reduce the runtime (setup) costs and to deliver high performant web applications. I first tried to do that by writing a javascript optimiser that can take React code as input and spit out highly optimised js code. I got pretty far with that but at one point I realised that to do it well I needed advanced things like data-flow analysis and abstract interpretation. So I decided to ditched that and just use D's static introspection and LLVM's wasm target. A couple of weeks after that spasm was born.
Oct 18
parent Suliman <evermind live.ru> writes:
https://github.com/kripken/emscripten/wiki/Pthreads-with-WebAssembly
Oct 18