Live data from Hacker News

Rust and WebAssembly in 2019

fitzgeraldnick.com

81–90 of 97 posts

Re: Rust and WebAssembly in 2019

#81

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 languag…

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.

Re: Rust and WebAssembly in 2019

#83
post #15

Earlier quoted context omitted.

> 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-futu... . But meanwhile, Webassembly is mainly just for C and Rust.

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 t…

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.

Re: Rust and WebAssembly in 2019

#84

Earlier quoted context omitted.

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/ First of all JS cannot ever be replaced by WASM. This is a…

>there will never be direct DOM access from WebAssembly for security reasons 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-circui…

> 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.

Re: Rust and WebAssembly in 2019

#85
post #31

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

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…

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.

Re: Rust and WebAssembly in 2019

#86

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 we…

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?.

Re: Rust and WebAssembly in 2019

#87

Earlier quoted context omitted.

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 t…

It would be neat if they could be cached as language-specific GCs, rather than having to be bundled individually with each application.

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.

Re: Rust and WebAssembly in 2019

#88
post #53

Earlier quoted context omitted.

That overhead has been greatly reduced in Firefox recently.

Same with V8, since they added the liftoff compiler back in august

At least on my android phone, Firefox is still an order of magnitude faster in some benchmarks.

Re: Rust and WebAssembly in 2019

#89
post #15

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.

> 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-futu... . But meanwhile, Webassembly is mainly just for C and Rust.

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)

Re: Rust and WebAssembly in 2019

#90

Earlier quoted context omitted.

>there will never be direct DOM access from WebAssembly for security reasons 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-circui…

> 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 p…

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.

Post reply on HN