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.
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.
Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries, for the same reason those languages have c extensions rather than extensions in other large runtime languages today.
This only applies to libraries served from separate locations though, right? No issue writing a Haskell library for wasm and then having consumers compile their app leveraging your library (at which point it's bundled with the RTS)
I’m not sure what the serving part has to do with it; if I have a ruby library and a python library and I use them from a Haskell app, I’m getting three runtimes, regardless of if they’re bundled together or not.
This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.
No, we should be working to replace NPM and the bad influence of the javascript community, not double down on their ubiquity. We should be able to do a lot better than sticking with NPM and wrapping everything in Chromium.
No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks...
No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications.
In the simplest form Google or Python.org could serve these files on a CDN. In a more complicated form you could run an application on a range of Python versions, and only download updates when you want and need them.
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.
The "problem" with integrating with the host gc is that it means language who have subtly different approaches to garbage collection can't trust compiled code behavior to be identical in the browser.
This is probably not a terrible thing, since a native garbage collector in WASM (unless it was designed in an extremely simplistic, low-level form) would also probably not be suitable for the diversity of the languages that want to include one.
It is (probably) better for individual languages to write their own, even if that increases binary sizes.
Of course, if you have a bunch of languages that compile to JavaScript, they all share the same low-level object layout and garbage collector. This VM has a lot of momentum.
The problem is that languages that are genuinely different from JavaScript (such as Dart and Go via gopher) have their own static linkers that generate a big blob of JavaScript. To really do interop right, you need to share a common linker and data format for public API calls. And to make this efficient, it needs to handle inlining and tree-shaking. At that point you might as well use JavaScript or a light overlay language like TypeScript.
With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.
This is something that interests me as well. If you have separate WASM binaries, right now they have to be on separate threads. For many languages, that may not matter, but it would be interesting to see if there was some way to split up a WASM binary on the same thread and apply caching to some of it.
That "integration with the browser’s garbage collector" feature in the webassembly roadmap doesn't mean the inclusion of a GC - it means there will be a mechanism by which a WASM-implemented GC can cooperate with the browser GC.
(There seem to be additional long term ideas int he wasm design repos for adding more GC support, but they seem vague at this point and it's not clear how interested browser vendors or language implementors are)
There are plans to get garbage collection support into WASM, but GC is already possible, just not native.
In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers.
Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a way to host and cache such runtimes for multiple applications or websites.
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.
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.
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/
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...
>developers, [...], tend to be deathly afraid of touching the DOM
I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile.
I am writing JS in the entire stack at the moment and I am mostly happy with it. I don't think that ability will go away but I look forward to the day where I can do the same in Rust or F# or whatever. And it doesn't seem unlikely to me that one day we will see wasm becoming the foundation in browsers, with JS running on top of it like any other language.
> I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile.
Uggghhh, somehow you have somehow never seen DOM fear while simultaneously describing your own DOM fear. To say this behavior is prolific underscores the prolificness of it.
---
Some anecdotal stories of DOM fear:
I remember trying to hire my replacement when I was the A/B test engineer for Travelocity. This was when jQuery was at its religious height before querySelectors were a standard. jQuery wouldn't work well in this context because it was too slow, required an external library, and developers spent more time debugging their crappy jQuery code than simply solving the business problem. I remember warning applications they could not use jQuery in this position and it would not be available for consideration in the interview. Half the candidates dropped out.
Before I became the A/B test engineer for Travelocity I remember a principle engineer telling me they had to use jQuery because the DOM was too hard. Its because of stupid crap like that the company had no trouble promoting me to more senior positions.
I remember being temporarily banned from an IRC channel because I described jQuery as slow. They are thousands of times slower on all browsers except Firefox where they are millions to billions times slower. It sounds like there should be more to this, such as a demonstration of bad behavior on my part, but I promise describing jQuery as slow was all it took to elicit an immediate emotional response that touched on multiple people.
I remember being continuously flamed on Reddit for describing that WASM is not a DOM replacement. I have since deleted my Reddit account. On Reddit's r/programming the emotions are especially raw on this subject.
I remember going into job interviews for JavaScript development and opening the conversation with my thoughts on jQuery or DOM access. Every time the interview would have to recollect themselves from being immediately disoriented and completely lost. Strange as that sounds it never stopped me from winning the job.
I could go on and on, but fear of the DOM is real. People justify all manners of strange behaviors to qualify their defensiveness on this matter to the point of exercising extreme effort to avoid the subject at great expense to their business products and even their career decisions. Its really weird because the DOM is the standard and its stupid simple.
Is this all just about people using ``$`` instead of ``document.querySelector``? I figured you were talking about the virtual DOM in React or something. Now I'm not sure what you mean anymore.
What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow. That has nothing to do with being afraid of the DOM, it has to do with grouping your update logic into one place so that you can avoid spaghetti code, state-dependent updates, and XSS attacks. When people talk about direct DOM access, this is often what they're referring to -- developers who think, "I need to change the color of this button. I know, I'll just set it directly in this random method so it only works in this very narrow code path."
I haven't used JQuery on a single personal project in at least 3 or 4 years, possibly longer. But even though I'm usually using the JS APIs directly, I'm still pushing all of my logic through a single render function instead of willy-nilly updating input labels in 5 different functions. Forcing rendering to go through an optimized chokepoint is just good architecture -- I'd use the same pattern even if I was working with Windows Forms or OpenGL.
My advice would be that if you're surrounded by people who are frightened of working with the DOM without JQuery, then find better developers to hang out with. Because in my experience that's not typical, and I very rarely run into developers with that perspective. Certainly I don't think it's the consensus on HN.
document.querySelector is still amazingly similar in use and form to the Sizzle engine on which it is based. Either way they have to parse into the standard DOM methods, because strings alone will not navigate or access anything.
Here is a summary of the standard DOM for mere mortals:
> What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow.
I have been doing this work long enough to see all manners of excuses and justifications. It is amazing how they change over time, but at any given time they are wonderfully uniform centering on the most popular understanding of the technology at the time. They are all unoriginal clichés that people mindlessly echo.
The excuses that stuck with me over the years:
* Its too hard. You cant do it without jQuery.
* It has to be further abstracted. Without the necessary abstractions you are essentially working in assembly code. (JavaScript is never close to assembly).
* You are reinventing the wheel (never mind that frameworks do that frameworks reinvent the wheel)
* You have to maintain state and you cannot do that without a framework. (unit test your code)
* If you don't use a framework you will end up writing a framework anyways.
---
In the end all the stupidity comes down to behavior. Developers don't trust the technology, don't trust their management, and especially don't trust each other or themselves to get it right. This behavior is called invented here syndrome and it isn't limited to the dom, the web, or even software. I frequently speak with lawyers and medical professionals who are frequently forced to mitigate this very same set of stupidity.
The cure for this foolishness is:
* Don't hire incompetent people, which are people lacking the proper desire and potential.
* Train your people. This technology isn't hard.
* Have the proper test automation in place.
* Have strong leadership in place. It is only a matter of time before people get frustrated or desperate and differ to really bad decisions. Bad decisions aren't limited to stupid people. Strong leaders are capable of withstanding the tired pleadings and big tears. Bad decisions are almost universally motivated by a perception of convenience without regard for risks or future expense, the easy versus simple paradigm.
Of course most organizations aren't willing to invest in any of this and would rather push the debt out to be a future failure for somebody else.
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)
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 ;)
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.
Doesn't sound like they were devs at all. Flash's AS3 (and to a lesser extent AS2) were pretty good languages and after learning them it should be pretty easy to transition to JS. AS3 was, imho, a better ECMAScript implementation than JS was, especially because it was typed. As someone who worked in both AS3 and JS I still miss it a bit but it wasn't that much of a leap to work in other environments.
Yeah I agree... especially with stuff like Starling Flash/AS3 was (and I suppose is) an amazing dev environment with robust capabilities.
I think one of the reasons "flash devs" get a bad rap is because a huge amount of the paid work for an epoch was all about making like preloaders and banners and things that were 95% timeline transitions and animations with just a sprinkling of code.
It's like taking a JS developer from the 90's and putting them in the same league of modern web app developers.
Same language (essentially, ish) but no comparison.
Especially with the last hurrah of flash which tied into native extensions for standalone builds and things - Adobe really dropped the ball with something great :\
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.
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.
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.
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?.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
Wouldn't it be a good solution for certain use cases like games, if you introduce a special mode with just one canvas?
So you allways have one and only one canvas for the output in which you write directly, via webgl or without.
No need for a gc here as that canvas inly gets removed qhen the site closes.
I assume you're talking only in the context of web browsers...
But if you're not, and for clarification, webassembly is not a web-browser-only thing.
https://webassembly.org/docs/non-web/
I personally want to use webassembly in a few non-browser tools/apps, but currently it's doesn't seem well supported (I've not run anything outside v8 or javascriptcore yet)
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.
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.
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.
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.