Hacker News Reader

Comment by flohofwoe | Hacker News Reader

I'm a big fan of WASM to run my cross-platform code in browsers, but everytime I see it pitched as wholesale replacement for Javascript frameworks which sit on top of the DOM I flinch a bit.

This is essentially the reverse of "with Electron you can now create native applications entirely in Javascript". Yes it works, but only with a lot of overhead that wouldn't exist by doing it the "straightforward" way.

A much smarter approach is to create hybrid JS/WASM applications, manage the UI in Javascript, move isolated standalone features (cross-platform code or performance-sensitive code) into WASM modules, and call into those WASM modules from JS.

View on HN

Will we see the next generation of electron applications using WASM for the bulk, and JS for the UI?

Heh, good point. In my last sentence I was thinking about web apps running in browsers, not about Electron (but of course there's a lot of overlap).

For native applications, maybe a better idea is to drive the UI with native code, and use WASM to run "untrusted" external code (for instance extensions/plugins), because a WASM runtime is a lot smaller than a complete browser engine like Electron.

I’d be surprised, given that one of the big arguments for using Electron is that you get to write it in JS.

If you write Rust for WASM you could just use a native UI framework and target that instead!

IMHO the USP of Electron isn't even that you can write the logic in Javascript, but that it's the option that "sucks least" for creating cross-platform UI applications.

A lot of people want to avoid the Javascript ecosystem because of fragmentation, churn and a range of other reasons. e.g. https://www.destroyallsoftware.com/talks/wat

I suppose they consider working with other languages, ecosystems and communities a smarter approach. Perhaps they have good reasons.

Yeah I see the point, but you need to consider the downsides too.

It's hard to get the binary size of WASM modules down to the size of minified Javascript, especially for code that calls into the browser anyway (e.g. for manipulating the DOM). Depending on what the code does it's not impossible, and sometimes WASM even comes out smaller, but this takes a lot of optimization and tweaking, and often developers are blind to this sort of problem (it mostly affects the users after all).

One cannot simply hand-wave those points away just because Javascript sucks (even ignoring the fact that JS hate is often completely irrational, I don't like the language either, but sheesh, C++ or Rust are not that much better).

I agree with you about that specific downside you mentioned.

Plus there's some other downsides such as likelihood that you might have to mix small amounts of Javascript as a second language into a WASM heavy solution based on another language.

However those are tradeoffs, and depending on the situation those tradeoffs can be very acceptable. A lot of enterprise software for instance isn't particularly concerned with those issues, and benefits strongly from the other very very significant benefits that can come from the other side of the tradeoff of avoiding the javascript ecosystem (not just language, but culture, tooling, churn and etc). Those benefits can include a range of things but I will just point out one theme which is increased stability and maintainability .. expressed in thing like type safety and refactoring tools, longer release cycles, less reliance on packages in favour of batteries included comprehensive language libraries, less pain with package upgrades, less pain with the canoninical way to use your framework de jour changing each year, less pain with prior art patterns being (gradually) rediscovered (and renamed) , and generally a culture that prioritises reliability and maintainability over the new hotness (or hotmess, depending on perspective!).

There's other situations, such as building the absolute fastest load time for a customer page, that tradeoff might not be appropriate. However to be fair there are other techniques for managing that, such as server side rendering and client hydrating of SPAs. Or gasp server rendered sites hehe with just a sprinkling of client interactivity if needed.

(Actually I think SPAs are usually not great at fast time to responsiveness, but that's really another discussion and lets not get sidetracked. The main point is the drawbacks are tradeoffs, and for many systems they are appropriate tradeoffs.)

Reply on news.ycombinator.com