9 ms·

Rust and WebAssembly in 2019

237 points by crunchiebones 8y ago

deleted 8y ago
[deleted]
throwawaylolx 8y ago
Is there any work done towards enabling Rust + WASM without any JS/npm?
- steveklabnik 8y ago
  Wasm requires JS to be loaded by your browser, so it can never fully go away. Outside the browser it’s a different story, of course.
  - fabrice_d 8y ago
    We could add support for <script src="something.wasm"></script> and not need JS to load it. Once the host bindings are implemented that would be a good fit.
    - steveklabnik 8y ago
      Maybe! There’s not really much demand for such a thing. Web platform people don’t have the disdain for JS that many internet commenters do.
      - pedrocr 8y ago
        In part because Web platform people have been self-selected to not dislike JS.
      - fabrice_d 8y ago
        I don't disagree with that :) But it would be an interesting experiment to build a JS-free web runtime and see how/if we could get more predictable resource usage this way.
        Keyframe 8y ago
        cough dart cough
      - josephg 8y ago
        I think this sort of thing is always a bigger deal than it seems. I think most people are actually really averse to learning new platforms, and things that enable people to make stuff without having to learn a different platform are way more popular than I would expect. Examples: phonegap, electron, unity, love2d, reactnative, and nodejs itself. (Node = I know web but not native, can you help me write server code without learning C/python). Most of this stuff solves the problem of “I want to program on platform X, but I’m most comfortable in Y. Can someone prevent me from needing to learn X’s paradigms?”. Arguably that’s one of the biggest draws of wasm itself, and why the communities around a lot of languages are excited about it. (Eg rust, blazer). (“Ugh don’t make me learn JavaScript. I already know C# and I like it. Can I just do that instead?”) To your point, I think it seems like there’s not much demand for such a thing because the people it would help aren’t involved enough yet to file issues. If they’re invested enough in the community and the problem, they’re probably invested enough to learn enough JS to bridge the languages themself anyway. Which is all to say, I think making a wasm script tag after host bindings are in is a good idea and will make a lot more people happy than it would seem if you just surveyed the existing community.
        steveklabnik 8y ago
        Eh, I think that the few lines of JS it takes to instaniate a wasm module isn’t a problem even for people who aren’t great at JS. I’m one of those people, and it’s only a few lines, really. It can even be generated by tools. It’s just not that big a deal.
        tokyodude 8y ago
        the big deal is not knowing the platform and therefore reproducing it in wasm. a simple example is most games compling in libjpg, libpng, zlib when the browser already has that stuff built in.
      - ordu 8y ago
        > Web platform people don’t have the disdain for JS that many internet commenters do. I'm not a web platform person, but I have coded some wasm application as a part of my undergraduate course work, and it is really annoying to use javascript just because rust code cannot be initialized without this BASIC of XXI century. Outdated unsafe language with outdated unsafe API for DOM access on top of modern language with an ability to design strict, safe and elegant APIs. One need not to be a guru of JS to get access to DOM and to initialize wasm-module, and to write the majority of code in rust, but all this javascript stuff feels like a fifth wheel for a cart: maybe it doesn't hurt much, but it is a dead weight at least. I mean, I'm not a web platform person, and it is far far away from my day to day work, so maybe I see it all wrong, but I believe that javascript is doomed, like any other fifth wheel. It will last, maybe decade or even more, but it is doomed.
    - Technetium_Hat 8y ago
      ...but it couldn't interact with the DOM or do anything else without JavaScript.
      - steveklabnik 8y ago
        That’s why your parent said “once host bindings are implemented.”
- throwaway23H 8y ago
  If you mean producing a wasm module without touching third-party tooling, then this can already be done with Rust today. The standard rust compiler is capable of cross-compiling out of the box, so the only thing you need in order to produce a working wasm module are the standard libraries which can be obtained from rust-lang.org. I wrote a somewhat detailed guide about the process here: https://www.reddit.com/r/rust/comments/9t95fd/howto_setting_up_webassembly_on_stable_rust/ https://www.reddit.com/r/rust/comments/9t95fd/howto_setting_...
sametmax 8y ago
I wish something similar was officially worked on by the python core dev. Ouputting wasm and being able to interpret it is going yo be necessary for the language to stay relevant in 10 years. But it not a priority at all atm.
- lachlan-sneff 8y ago
  Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
  - baq 8y ago
    You ‘just’ wasm-compile the whole interpreter. It could even be feasible with a cdn.
    - lachlan-sneff 8y ago
      Oh yeah, you can do that. Performance is still quite terrible unfortunately.
    - rthy 8y ago
      An example of compiling the CPython interpreter to WebAssembly can be found in Pyodide (https://github.com/iodide-project/pyodide/ https://github.com/iodide-project/pyodide/).
  - sametmax 8y ago
    Actually pypy and it's jit proves you can make python fast. Nuitka also compiles python, and gain up to x4 in perfs. What more, i think it would make more sense to actually make a bytecode to wasm and vice versa compiler than directly use python code. Besides, performances are not important at first. The goal is not python is the browser, as wasm can go far beyong the web. The greatest assests for wasm IMO is the interroperability.
losvedir 8y ago
It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.
- azangru 8y ago
  > As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/ https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, Webassembly is mainly just for C and Rust.
  - steveklabnik 8y ago
    Note that’s more “integrate with a host’s GC” than it is “add a GC.” A subtle but important difference.
  - hu3 8y ago
    > Webassembly is mainly just for C and Rust That's absolutely incorrect. Go and .NET can target WASM for quite a while now. Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png https://i.imgur.com/HHFkB1E.png Code here: https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder https://github.com/aspnet/samples/tree/master/samples/aspnet...
    - colordrops 8y ago
      Right but those languages compile in their own garbage collector. That's not the same as a VM provided garbage collector, and furthermore, the GC used in browsers also manages DOM allocations, and thus directly interfacing the DOM without JS is impossible until the VM GC is implemented.
    - steveklabnik 8y ago
InGodsName 8y ago
Figma uses WASM and some claim that it's even faster than natively implemented Sketch. I am surprised that now it's possible to make a web app as fast as native app. Is Visual Studio Code using WASM?
- steveklabnik 8y ago
  Not that I’m aware of.
- solarkraft 8y ago
  > faster than natively implemented It still depends on your implementation. The same code will take about 1.2x as long to execute in wasm (of course this means that a slightly faster implementation can be faster over all). > Is Visual Studio Code using WASM? I have read on HN that they use Rust for some internals, but so far I haven't been able to confirm it. It would make sense for things like intellisense to be compiled, but don't forget that with Electron you can still access the platform with all iits capabilities, so you wouldn't need wasm.
  - gpm 8y ago
    > I have read on HN that they use Rust for some internals I know the multi-file search is done via ripgrep, which is written in rust. But it's not compiled to wasm.
shmerl 8y ago
Can WebAssembly be used without any JavaScript? Or JavaScript is always required in some combination with it?
- raboukhalil 8y ago
  For now, JavaScript is required to initialize the WebAssembly module.
  - shmerl 8y ago
    Why was it not given same <script> level usage?
    - steveklabnik 8y ago
      How do you set up the imports with script? (This would be one of the major design questions with such a thing. Not insurmountable! But given you’re already connecting it to JS functions...)
      - shmerl 8y ago
        You mean for one module to import another? I guess you can use list them all first?
- deleted 8y ago
  [deleted]
- archgoon 8y ago
  It cannot be used without javascript because it currently has no interface to the DOM. Without DOM access, you're simply running a virtual machine isolated from everything else, and that would serve no purpose aside from burning clock cycles :). It is currently felt that Webassembly shouldn't be given access to the DOM until after a garbage collection interface is created. Until that happens, any object given to the WASM runtime cannot be safely destroyed, as the browser doesn't know, and WASM has no way of indicating, that something, such as a reference to a div element, is still needed. Currently, the simplest[1] and most secure way of working out how a given runtime should interface with the browser is to build that compatibility layer in javascript, and expose callbacks to the WASM runtime(which is defined). This lets developers write their own DOM-interface shim, allowing them to explore the possibility space, and not accidentally restrict which languages can be implemented in WASM. [1] From the point of view of browser vendors and standards bodies.
danShumway 8y ago
I'm really excited and happy about the direction Rust has gone with WASM; and this is coming from someone who has never used Rust before. I like JS, a lot, but my hope with WASM was still pretty much literally what they're talking about here -- that languages would start to do first-class replacements for Javascript. I didn't want people to create massive binary blobs that were primarily just native code that rendered everything out to Canvas as an afterthought. In contrast, Rust is building out better host bindings, web-first tools, looking into fallbacks for older browsers like IE11... Nearly every time I read an article about Rust and WASM I feel happy and hopeful. I think the work Rust has done here has been ridiculously valuable for setting a tone and a standard for what WASM-targetting languages should be. As a result, Rust is pretty high up on my list of languages that I'm interested in learning in the future, because I feel like any community that is getting this much right on the web has probably also gotten other things right with the core language. The fact that it's increasingly looking likely that Rust on the web will probably be one of the best supported, most thoughtful alternatives to Javascript out there makes it even more attractive.
deleted 8y ago
[deleted]
xvilka 8y ago
Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.
- swsieber 8y ago
  That overhead has been greatly reduced in Firefox recently.
  - PaulBGD_ 8y ago
    Can you explain more what changed? Super interested in this.
    - steveklabnik 8y ago
      https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
  - snek 8y ago
    Same with V8, since they added the liftoff compiler back in august
    - swsieber 8y ago
      At least on my android phone, Firefox is still an order of magnitude faster in some benchmarks.
- BinaryIdiot 8y ago
  While I agree that access will eventually come. I love seeing the experiments thus far and can't wait until WASM hits the same amount of capability via DOM access that JS has. That day will change the web forever, IMO.
- austincheney 8y ago
  That is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a stated project design goal of WASM. You have to understand that Web Assembly is there to fill the proprietary application add-in void of things like Flash using open standards safely in a way that is technology agnostic. Web Assembly is not there to serve as a crutch for people afraid of web technologies. Secondly, there will never be direct DOM access from WebAssembly for security reasons. While that is the nail in the coffin on this matter there is the more practical consideration that developers, even those who write JavaScript full time for a living, tend to be deathly afraid of touching the DOM. If this were a reality the inevitable overhead (think of all the dependencies, frameworks, and abstractions developers cannot live without because the DOM is scary) would likely be just as high, or higher, than writing your own DOM library embedded within your WARM instance. Thirdly, you can have a DOM interface in a WASM instance. This is part of the web components API, but DOM trees created for the WASM instances are islands to the WASM instance created from external JavaScript - https://medium.com/coinmonks/develop-w3c-web-components-with-webassembly-d65938284255 https://medium.com/coinmonks/develop-w3c-web-components-with...
deleted 8y ago
[deleted]
OpenBSD-empire 8y ago
Wouldn't SPARK (and Ada) be better suited for WebAssembly than rust? Because SPARK is built to be formally provable and Ada being pretty damn safe?
- steveklabnik 8y ago
  I haven’t heard of any implementation. It can’t be better if it doesn’t exist.
bayesian_horse 8y ago
I'm not quite into Rust yet, but it is a very candidate for useful webassembly frameworks/projects. It doesn't need a big run time, but is more expressive than C/C++. The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. The learning curve is just too damn hard.
- zozbot123 8y ago
  > The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. Plenty of "non-technical people" learn to write simple (buggy) programs in C in a matter of months. And once you know the basics of the C machine model, it is quite feasible to work up to Rust. The thing about learning Rust though is that it's not really a mature language just yet - it's a hell of a moving target! Even Rust+NLL is a very different animal from Rust w/o NLL, and this goes for so many other features.
  - GolDDranks 8y ago
    Rust + NLL is arguably simpler than Rust w/o NLL; the only thing that has changed in my Rust code that I need to jump through hoops less often. I think that it isn't as much the core language, but the ecosystem that is a moving target - at least with regards to the current networking stuff. But I expect that to stabilise a whole lot during the next year.
  - bayesian_horse 8y ago
    You can learn to write buggy Python or Javascript programs in a few days at most. You can learn to write a web application in Django in a few days or very few weeks. Rust has interesting features and an enthusiastic community (though the extreme down voting of any mild criticisms of Rust here is disappointing). But again, the learning curve is very flat, meaning you have to learn a whole lot just to achieve the simplest things. I have taught programming to highly intelligent non-programmers before. I know the difficulties. They don't have either the time or the frustration tolerance to argue with the rust compiler.
dakom 8y ago
I decided that Rust is the natural next step for my personal side project stuff, which I want to be more on the browser-based gamedev side of things. The learning curve is enormous - since coming from like Unity and Flash, so much is done for you... I mean, one _can_ write their own shader code and physics and things, but it's not at all required in order to make impressive content. Even in JS, Three.JS and friends typically take care of the heavy lifting and deciding to get closer to the metal on both fronts (CPU and GPU)- and in a new language (for me), is a bit daunting. Anyway - I figured a good way to push myself to learn more productively is to livestream while I'm coding and figuring stuff out. Forces some accountability and might help others too. So far I've only done two sessions and about to do my third. The goal is to build a WebGL renderer from scratch with nothing but Rust (I had a Typescript project that was after the same goal - so there's going to be a fair amount of straight conversion, but it was never totally finished and some things can be improved even if they would theoretically translate 1:1) Live Stream URL: https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/live https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/liv... Playlist URL: https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSqRV4UVt4QjaZ5 https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSq... If you join, please remember - the whole point is that I don't know what I'm doing (yet) and I actually _want_ to struggle in order to learn, rather than have solutions spoon-fed to me. I think there will ultimately be at the very least some general functions here which can be useful abstractions over web_sys/js_sys/etc. At least I hope so! Lastly - schedule is irregular, so best way to know when it's live is to subscribe and rely on youtube notifications ;)
- erlend_sh 8y ago
  Awesome work! I hope you’ll consider involving the gfx-rs project in your learning streak. They are building an all-in-one graphics backend for use in Firefox but also the gamedev ecosystem, e.g. the Amethyst.rs game engine. https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx/issues/1900 https://github.com/gfx-rs/gfx/issues/1900
- k__ 8y ago
  Really nice! The Flash devs I met went all downhill with Flash, because they never learned how to code and suddendly needed to do it.
revskill 8y ago
The ideal programming language won't let you specify type, the compiler will detect for you. Why ? Because it's unnesessary for human to waste keystrokes for something like typing. So, a statically typed language, but act like a dynamic language is ideal.
jillesvangurp 8y ago
Rust and wasm is looking pretty interesting. I've recently started playing with kotlin-js. Kotlin also has a wasm compiler but their javascript transpiler has been around longer and garbage collection is short term an issue for their wasm compiler. Also there are a ton of kotlin-js libraries out there already which makes using this straightforward. This is exactly the kind of stuff the rust people are targeting as well. Basically, both ecosystems are creating all the tools and libraries they need to make pure rust or kotlin web applications. Rust is ahead but Kotlin and other languages are not far behind. IMHO, the next two years there is going to be a massive adoption of wasm as the library ecosystem for different languages matures and as browsers gradually improve their wasm support. Contrary to the popular belief with javascript people, it will not be limited to just the performance critical parts: everything people do with javascript today is in scope. Absolutely no exceptions. I fully expect to see a lot of projects where the goal is to be 100% javascript free and I don't see any fundamental blocking issues to get there. If you are doing a greenfield project today, that is already a feasible goal to set but you may have to reinvent a few wheels along the way or be dealing with not so mature frameworks and tools. However, once you start doing rust or kotlin, it will just feel wrong to have to revert to back to javascript or pull in an npm and wrap that with some facade. That's like admitting defeat. Basically, Rust people already concluded that they can do it all and are now in the process of doing it.
- jamil7 8y ago
  Personally I can't wait, javascript is miles ahead of where it was 5 years ago but it's still pretty painful to use on large, longer running projects with bigger teams. I once enjoyed it enough and now dread starting a project in it. Typescript is a massive improvement but maybe the ship has sailed. If we don't _have_ to use it anymore why bother?.
  - jillesvangurp 8y ago
    With you there. I've spent some 'quality time' with javascript recently (as a backend developer). It doesn't suck as hard as it did a mere two years ago when I last did this and it is massively better than 20 years ago (netscape, shudder). But it's not quite awesome just yet. Basically, I'm planning to ditch javascript pretty soon. I consider typescript to be a stop gap solution. I'd prefer to use something like Kotlin or indeed Rust. IMHO Kotlin is a great fit because it already is used for frontend work in Android. Also the transition from javascript to Kotlin is pretty smooth once you get over the stockholm syndrome that most javascript developers seem to suffer from (they don't seem to know better). I've seen a few people adapt to Kotlin and liking it. In my experience, these things tend to be driven by people voting with their feet. There's lots of early signals on Github that this is starting to happen. I'd also prefer to opt out most of the npm ecosystem. IMHO, most of the stuff there is inherently javascript centric and not a great fit in a type safe environment that has things like generics, polymorphism, and other stuff that makes frameworks look and feel a bit differently. Even with type annotations like in typescript you get lots of leaky abstractions and you are still dealing with javascript when it inevitably blows up. Better to make a clean break with this and create a new ecosystem from scratch. And frankly, most npms are not that hard to replicate in another language.
nmca 8y ago
I used this to write a game playing engine recently, was quite fun. However the ecosystem is not that developed on the JS side - ran into bundling issues with both parcel and webpack that were totally mystifying. https://github.com/N-McA/parcel-yavalath/blob/master/README.md https://github.com/N-McA/parcel-yavalath/blob/master/README....

237 points by crunchiebones 8y ago

deleted 8y ago

[deleted]

throwawaylolx 8y ago

Is there any work done towards enabling Rust + WASM without any JS/npm?

steveklabnik 8y ago
Wasm requires JS to be loaded by your browser, so it can never fully go away. Outside the browser it’s a different story, of course.
- fabrice_d 8y ago
  We could add support for <script src="something.wasm"></script> and not need JS to load it. Once the host bindings are implemented that would be a good fit.
  - steveklabnik 8y ago
    Maybe! There’s not really much demand for such a thing. Web platform people don’t have the disdain for JS that many internet commenters do.
    - pedrocr 8y ago
      In part because Web platform people have been self-selected to not dislike JS.
    - fabrice_d 8y ago
      I don't disagree with that :) But it would be an interesting experiment to build a JS-free web runtime and see how/if we could get more predictable resource usage this way.
      - Keyframe 8y ago
        cough dart cough
    - josephg 8y ago
      I think this sort of thing is always a bigger deal than it seems. I think most people are actually really averse to learning new platforms, and things that enable people to make stuff without having to learn a different platform are way more popular than I would expect. Examples: phonegap, electron, unity, love2d, reactnative, and nodejs itself. (Node = I know web but not native, can you help me write server code without learning C/python). Most of this stuff solves the problem of “I want to program on platform X, but I’m most comfortable in Y. Can someone prevent me from needing to learn X’s paradigms?”. Arguably that’s one of the biggest draws of wasm itself, and why the communities around a lot of languages are excited about it. (Eg rust, blazer). (“Ugh don’t make me learn JavaScript. I already know C# and I like it. Can I just do that instead?”) To your point, I think it seems like there’s not much demand for such a thing because the people it would help aren’t involved enough yet to file issues. If they’re invested enough in the community and the problem, they’re probably invested enough to learn enough JS to bridge the languages themself anyway. Which is all to say, I think making a wasm script tag after host bindings are in is a good idea and will make a lot more people happy than it would seem if you just surveyed the existing community.
      - steveklabnik 8y ago
        Eh, I think that the few lines of JS it takes to instaniate a wasm module isn’t a problem even for people who aren’t great at JS. I’m one of those people, and it’s only a few lines, really. It can even be generated by tools. It’s just not that big a deal.
        tokyodude 8y ago
        the big deal is not knowing the platform and therefore reproducing it in wasm. a simple example is most games compling in libjpg, libpng, zlib when the browser already has that stuff built in.
    - ordu 8y ago
      > Web platform people don’t have the disdain for JS that many internet commenters do. I'm not a web platform person, but I have coded some wasm application as a part of my undergraduate course work, and it is really annoying to use javascript just because rust code cannot be initialized without this BASIC of XXI century. Outdated unsafe language with outdated unsafe API for DOM access on top of modern language with an ability to design strict, safe and elegant APIs. One need not to be a guru of JS to get access to DOM and to initialize wasm-module, and to write the majority of code in rust, but all this javascript stuff feels like a fifth wheel for a cart: maybe it doesn't hurt much, but it is a dead weight at least. I mean, I'm not a web platform person, and it is far far away from my day to day work, so maybe I see it all wrong, but I believe that javascript is doomed, like any other fifth wheel. It will last, maybe decade or even more, but it is doomed.
  - Technetium_Hat 8y ago
    ...but it couldn't interact with the DOM or do anything else without JavaScript.
    - steveklabnik 8y ago
      That’s why your parent said “once host bindings are implemented.”
throwaway23H 8y ago
If you mean producing a wasm module without touching third-party tooling, then this can already be done with Rust today. The standard rust compiler is capable of cross-compiling out of the box, so the only thing you need in order to produce a working wasm module are the standard libraries which can be obtained from rust-lang.org. I wrote a somewhat detailed guide about the process here: https://www.reddit.com/r/rust/comments/9t95fd/howto_setting_up_webassembly_on_stable_rust/ https://www.reddit.com/r/rust/comments/9t95fd/howto_setting_...

sametmax 8y ago

I wish something similar was officially worked on by the python core dev. Ouputting wasm and being able to interpret it is going yo be necessary for the language to stay relevant in 10 years. But it not a priority at all atm.

lachlan-sneff 8y ago
Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
- baq 8y ago
  You ‘just’ wasm-compile the whole interpreter. It could even be feasible with a cdn.
  - lachlan-sneff 8y ago
    Oh yeah, you can do that. Performance is still quite terrible unfortunately.
  - rthy 8y ago
    An example of compiling the CPython interpreter to WebAssembly can be found in Pyodide (https://github.com/iodide-project/pyodide/ https://github.com/iodide-project/pyodide/).
- sametmax 8y ago
  Actually pypy and it's jit proves you can make python fast. Nuitka also compiles python, and gain up to x4 in perfs. What more, i think it would make more sense to actually make a bytecode to wasm and vice versa compiler than directly use python code. Besides, performances are not important at first. The goal is not python is the browser, as wasm can go far beyong the web. The greatest assests for wasm IMO is the interroperability.

losvedir 8y ago

It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.

azangru 8y ago
> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/ https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, Webassembly is mainly just for C and Rust.
- steveklabnik 8y ago
  Note that’s more “integrate with a host’s GC” than it is “add a GC.” A subtle but important difference.
- hu3 8y ago
  > Webassembly is mainly just for C and Rust That's absolutely incorrect. Go and .NET can target WASM for quite a while now. Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png https://i.imgur.com/HHFkB1E.png Code here: https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder https://github.com/aspnet/samples/tree/master/samples/aspnet...
  - colordrops 8y ago
    Right but those languages compile in their own garbage collector. That's not the same as a VM provided garbage collector, and furthermore, the GC used in browsers also manages DOM allocations, and thus directly interfacing the DOM without JS is impossible until the VM GC is implemented.
  - steveklabnik 8y ago

InGodsName 8y ago

Figma uses WASM and some claim that it's even faster than natively implemented Sketch. I am surprised that now it's possible to make a web app as fast as native app. Is Visual Studio Code using WASM?

steveklabnik 8y ago
Not that I’m aware of.
solarkraft 8y ago
> faster than natively implemented It still depends on your implementation. The same code will take about 1.2x as long to execute in wasm (of course this means that a slightly faster implementation can be faster over all). > Is Visual Studio Code using WASM? I have read on HN that they use Rust for some internals, but so far I haven't been able to confirm it. It would make sense for things like intellisense to be compiled, but don't forget that with Electron you can still access the platform with all iits capabilities, so you wouldn't need wasm.
- gpm 8y ago
  > I have read on HN that they use Rust for some internals I know the multi-file search is done via ripgrep, which is written in rust. But it's not compiled to wasm.

shmerl 8y ago

Can WebAssembly be used without any JavaScript? Or JavaScript is always required in some combination with it?

raboukhalil 8y ago
For now, JavaScript is required to initialize the WebAssembly module.
- shmerl 8y ago
  Why was it not given same <script> level usage?
  - steveklabnik 8y ago
    How do you set up the imports with script? (This would be one of the major design questions with such a thing. Not insurmountable! But given you’re already connecting it to JS functions...)
    - shmerl 8y ago
      You mean for one module to import another? I guess you can use list them all first?
deleted 8y ago
[deleted]
archgoon 8y ago
It cannot be used without javascript because it currently has no interface to the DOM. Without DOM access, you're simply running a virtual machine isolated from everything else, and that would serve no purpose aside from burning clock cycles :). It is currently felt that Webassembly shouldn't be given access to the DOM until after a garbage collection interface is created. Until that happens, any object given to the WASM runtime cannot be safely destroyed, as the browser doesn't know, and WASM has no way of indicating, that something, such as a reference to a div element, is still needed. Currently, the simplest[1] and most secure way of working out how a given runtime should interface with the browser is to build that compatibility layer in javascript, and expose callbacks to the WASM runtime(which is defined). This lets developers write their own DOM-interface shim, allowing them to explore the possibility space, and not accidentally restrict which languages can be implemented in WASM. [1] From the point of view of browser vendors and standards bodies.

danShumway 8y ago

I'm really excited and happy about the direction Rust has gone with WASM; and this is coming from someone who has never used Rust before. I like JS, a lot, but my hope with WASM was still pretty much literally what they're talking about here -- that languages would start to do first-class replacements for Javascript. I didn't want people to create massive binary blobs that were primarily just native code that rendered everything out to Canvas as an afterthought. In contrast, Rust is building out better host bindings, web-first tools, looking into fallbacks for older browsers like IE11... Nearly every time I read an article about Rust and WASM I feel happy and hopeful. I think the work Rust has done here has been ridiculously valuable for setting a tone and a standard for what WASM-targetting languages should be. As a result, Rust is pretty high up on my list of languages that I'm interested in learning in the future, because I feel like any community that is getting this much right on the web has probably also gotten other things right with the core language. The fact that it's increasingly looking likely that Rust on the web will probably be one of the best supported, most thoughtful alternatives to Javascript out there makes it even more attractive.

deleted 8y ago

[deleted]

xvilka 8y ago

Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.

swsieber 8y ago
That overhead has been greatly reduced in Firefox recently.
- PaulBGD_ 8y ago
  Can you explain more what changed? Super interested in this.
  - steveklabnik 8y ago
    https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
- snek 8y ago
  Same with V8, since they added the liftoff compiler back in august
  - swsieber 8y ago
    At least on my android phone, Firefox is still an order of magnitude faster in some benchmarks.
BinaryIdiot 8y ago
While I agree that access will eventually come. I love seeing the experiments thus far and can't wait until WASM hits the same amount of capability via DOM access that JS has. That day will change the web forever, IMO.
austincheney 8y ago
That is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a stated project design goal of WASM. You have to understand that Web Assembly is there to fill the proprietary application add-in void of things like Flash using open standards safely in a way that is technology agnostic. Web Assembly is not there to serve as a crutch for people afraid of web technologies. Secondly, there will never be direct DOM access from WebAssembly for security reasons. While that is the nail in the coffin on this matter there is the more practical consideration that developers, even those who write JavaScript full time for a living, tend to be deathly afraid of touching the DOM. If this were a reality the inevitable overhead (think of all the dependencies, frameworks, and abstractions developers cannot live without because the DOM is scary) would likely be just as high, or higher, than writing your own DOM library embedded within your WARM instance. Thirdly, you can have a DOM interface in a WASM instance. This is part of the web components API, but DOM trees created for the WASM instances are islands to the WASM instance created from external JavaScript - https://medium.com/coinmonks/develop-w3c-web-components-with-webassembly-d65938284255 https://medium.com/coinmonks/develop-w3c-web-components-with...

deleted 8y ago

[deleted]

OpenBSD-empire 8y ago

Wouldn't SPARK (and Ada) be better suited for WebAssembly than rust? Because SPARK is built to be formally provable and Ada being pretty damn safe?

steveklabnik 8y ago
I haven’t heard of any implementation. It can’t be better if it doesn’t exist.

bayesian_horse 8y ago

I'm not quite into Rust yet, but it is a very candidate for useful webassembly frameworks/projects. It doesn't need a big run time, but is more expressive than C/C++. The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. The learning curve is just too damn hard.

zozbot123 8y ago
> The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. Plenty of "non-technical people" learn to write simple (buggy) programs in C in a matter of months. And once you know the basics of the C machine model, it is quite feasible to work up to Rust. The thing about learning Rust though is that it's not really a mature language just yet - it's a hell of a moving target! Even Rust+NLL is a very different animal from Rust w/o NLL, and this goes for so many other features.
- GolDDranks 8y ago
  Rust + NLL is arguably simpler than Rust w/o NLL; the only thing that has changed in my Rust code that I need to jump through hoops less often. I think that it isn't as much the core language, but the ecosystem that is a moving target - at least with regards to the current networking stuff. But I expect that to stabilise a whole lot during the next year.
- bayesian_horse 8y ago
  You can learn to write buggy Python or Javascript programs in a few days at most. You can learn to write a web application in Django in a few days or very few weeks. Rust has interesting features and an enthusiastic community (though the extreme down voting of any mild criticisms of Rust here is disappointing). But again, the learning curve is very flat, meaning you have to learn a whole lot just to achieve the simplest things. I have taught programming to highly intelligent non-programmers before. I know the difficulties. They don't have either the time or the frustration tolerance to argue with the rust compiler.

dakom 8y ago

I decided that Rust is the natural next step for my personal side project stuff, which I want to be more on the browser-based gamedev side of things. The learning curve is enormous - since coming from like Unity and Flash, so much is done for you... I mean, one _can_ write their own shader code and physics and things, but it's not at all required in order to make impressive content. Even in JS, Three.JS and friends typically take care of the heavy lifting and deciding to get closer to the metal on both fronts (CPU and GPU)- and in a new language (for me), is a bit daunting. Anyway - I figured a good way to push myself to learn more productively is to livestream while I'm coding and figuring stuff out. Forces some accountability and might help others too. So far I've only done two sessions and about to do my third. The goal is to build a WebGL renderer from scratch with nothing but Rust (I had a Typescript project that was after the same goal - so there's going to be a fair amount of straight conversion, but it was never totally finished and some things can be improved even if they would theoretically translate 1:1) Live Stream URL: https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/live https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/liv... Playlist URL: https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSqRV4UVt4QjaZ5 https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSq... If you join, please remember - the whole point is that I don't know what I'm doing (yet) and I actually _want_ to struggle in order to learn, rather than have solutions spoon-fed to me. I think there will ultimately be at the very least some general functions here which can be useful abstractions over web_sys/js_sys/etc. At least I hope so! Lastly - schedule is irregular, so best way to know when it's live is to subscribe and rely on youtube notifications ;)

erlend_sh 8y ago
Awesome work! I hope you’ll consider involving the gfx-rs project in your learning streak. They are building an all-in-one graphics backend for use in Firefox but also the gamedev ecosystem, e.g. the Amethyst.rs game engine. https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx/issues/1900 https://github.com/gfx-rs/gfx/issues/1900
k__ 8y ago
Really nice! The Flash devs I met went all downhill with Flash, because they never learned how to code and suddendly needed to do it.

revskill 8y ago

The ideal programming language won't let you specify type, the compiler will detect for you. Why ? Because it's unnesessary for human to waste keystrokes for something like typing. So, a statically typed language, but act like a dynamic language is ideal.

jillesvangurp 8y ago

Rust and wasm is looking pretty interesting. I've recently started playing with kotlin-js. Kotlin also has a wasm compiler but their javascript transpiler has been around longer and garbage collection is short term an issue for their wasm compiler. Also there are a ton of kotlin-js libraries out there already which makes using this straightforward. This is exactly the kind of stuff the rust people are targeting as well. Basically, both ecosystems are creating all the tools and libraries they need to make pure rust or kotlin web applications. Rust is ahead but Kotlin and other languages are not far behind. IMHO, the next two years there is going to be a massive adoption of wasm as the library ecosystem for different languages matures and as browsers gradually improve their wasm support. Contrary to the popular belief with javascript people, it will not be limited to just the performance critical parts: everything people do with javascript today is in scope. Absolutely no exceptions. I fully expect to see a lot of projects where the goal is to be 100% javascript free and I don't see any fundamental blocking issues to get there. If you are doing a greenfield project today, that is already a feasible goal to set but you may have to reinvent a few wheels along the way or be dealing with not so mature frameworks and tools. However, once you start doing rust or kotlin, it will just feel wrong to have to revert to back to javascript or pull in an npm and wrap that with some facade. That's like admitting defeat. Basically, Rust people already concluded that they can do it all and are now in the process of doing it.

jamil7 8y ago
Personally I can't wait, javascript is miles ahead of where it was 5 years ago but it's still pretty painful to use on large, longer running projects with bigger teams. I once enjoyed it enough and now dread starting a project in it. Typescript is a massive improvement but maybe the ship has sailed. If we don't _have_ to use it anymore why bother?.
- jillesvangurp 8y ago
  With you there. I've spent some 'quality time' with javascript recently (as a backend developer). It doesn't suck as hard as it did a mere two years ago when I last did this and it is massively better than 20 years ago (netscape, shudder). But it's not quite awesome just yet. Basically, I'm planning to ditch javascript pretty soon. I consider typescript to be a stop gap solution. I'd prefer to use something like Kotlin or indeed Rust. IMHO Kotlin is a great fit because it already is used for frontend work in Android. Also the transition from javascript to Kotlin is pretty smooth once you get over the stockholm syndrome that most javascript developers seem to suffer from (they don't seem to know better). I've seen a few people adapt to Kotlin and liking it. In my experience, these things tend to be driven by people voting with their feet. There's lots of early signals on Github that this is starting to happen. I'd also prefer to opt out most of the npm ecosystem. IMHO, most of the stuff there is inherently javascript centric and not a great fit in a type safe environment that has things like generics, polymorphism, and other stuff that makes frameworks look and feel a bit differently. Even with type annotations like in typescript you get lots of leaky abstractions and you are still dealing with javascript when it inevitably blows up. Better to make a clean break with this and create a new ecosystem from scratch. And frankly, most npms are not that hard to replicate in another language.

nmca 8y ago

I used this to write a game playing engine recently, was quite fun. However the ecosystem is not that developed on the JS side - ran into bundling issues with both parcel and webpack that were totally mystifying. https://github.com/N-McA/parcel-yavalath/blob/master/README.md https://github.com/N-McA/parcel-yavalath/blob/master/README....