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.
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.
There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, 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
Code here: https://github.com/aspnet/samples/tree/master/samples/aspnet...
I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
A CDN may happen; there’s some details that make it tough. We’ll see.
npm is already that package manager :)
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.
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.
With wasm, similarly, a common language runtime should probably have its own linker that combines and optimizes libraries and emits a wasm file.
(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)
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.
Don't know how this will play with other languages.
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.
You should contribute this knowledge: https://github.com/WebAssembly/proposals/issues/16
>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.
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 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.
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.
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.
* 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 agree with you that that doesn’t mean anything with regards to “killing JS” or anything.
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/liv...
Playlist URL: 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 ;)
The Flash devs I met went all downhill with Flash, because they never learned how to code and suddendly needed to do it.
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 :\
But it not a priority at all atm.
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.
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.
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.
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.
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_...
Outside the browser it’s a different story, of course.
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).
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.
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.
 From the point of view of browser vendors and standards bodies.
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.
(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...)
I am surprised that now it's possible to make a web app as fast as native app.
Is Visual Studio Code using WASM?
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.
I know the multi-file search is done via ripgrep, which is written in rust. But it's not compiled to wasm.