Hacker News Reader

> I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning.

I think that main use case is not for the web developers who already know the tech needed for web development but actually vice-versa. E.g. you're a C/C++/Rust developer and you want to expose your product as a browser service - you transpile it to wasm and with a bit of JavaScript you integrate it into the end service. And that landscape is now expanding to other languages too, namely the ones with the GC.

Already possible with PNaCL and CrossBridge in 2010, but yeah we needed to have it as a standard and delay everything for a decade.

I don't really know about PNaCL or CrossBridge, web is not particularly my domain but I was just trying to state the obvious advantage about WASM.

You're entirely correct. Non-standard ("proprietary") things tend to not catch on.

The irony is that with ChromeOS taking over the Web it hardly matters.

Emscripten has been around since 2012, originally targeting JavaScript.

But if you’re comparing to proprietary examples, you could go all the way back to ActiveX in 1996.

Or, since today’s news is about Java, you could go back to Java applets in 1995. (At least those were somewhat secure, unlike ActiveX.)

Yeah, I left those out on purpose, because Java Applets did not support C and C++, although there were later compilers for the JVM, and ActiveX were straight COM x86 binaries.

> E.g. you're a C/C++/Rust developer and you want to expose your product as a browser service - you transpile it to wasm and with a bit of JavaScript you integrate it into the end service

Speaking as someone who worked for two companies that tried to do exactly that, it's not that simple. The "bit of JavaScript" ends up requiring huge amounts of work, and the user experience feels un-browser-like, because you're fitting everything through a canvas element.

I have almost no exposure to JS but what I have seen so far in WASM projects didn't seem to require that much of a non-usual work but, of course, YMMV.

To me the most challenging part seemed to be in the domain of debugging when things would go south because all of the sudden you have to become very intimate with how things work under the hood and across the whole stack: JS -> V8 -> WASM runtime -> Emscripten -> C++. There's not many people capable of doing that job.

> user experience feels un-browser-like

Perhaps Photoshop is not the classical example but I think it's one of the most craziest ones out there - humongous and extremely complicated C++ codebase consisting of every imaginable optimization and heavy lifting deployed as a WASM "plugin".

[1] https://medium.com/@addyosmani/photoshop-is-now-on-the-web-3...

[2] https://web.dev/articles/ps-on-the-web

You can leverage normal HTML though? Blazor does this with C#, you don't write it all to a canvas element, you just use C# to modify the html itself, basically replacing the 'react' part of the UI.

Yes, but it's important to think about the bridge/shim between your application code (the web assembly module) and the host (the browser). If you have a C++ game which draws to the screen with SDL, then you can use a shim to convert SDL calls into html canvas calls [1]. But if a backend engineer wants to compile their java swing application to web assembly, there is a larger impedance mismatch from Java Swing => react html, then from Java Swing => html canvas.

If your application is built upon a web framework which already has this translation layer, like Blazor, then the amount of harness/shim-glue code you need to write goes down.

1: https://web.dev/articles/drawing-to-canvas-in-emscripten

For games canvas is fine. There is no 'web native ui' people expect.

I really don't think the use of this is running existing Java swing applications on the web. Maybe a bit of a hack for legacy software, but it's really using Java instead of Javascript, but using the normal DOM/HTML.

100% agreed with you. Here's the part where I agree with user "PoignardAzur":

* user "menaerus" goal is have "C/C++/Rust developer [...] expose your product as a browser service", which they can transpile to wasm - cool.

* they will need "a bit of JavaScript you integrate it into the end service" - UI targets the DOM, sounds great.

The questions become:

* how much code will need to be written into each layer (rust wasm, react html ui, bridge between the 2)?

* what level of experience with that tech will you need todo that? ie: writing a react ui which interfaces with a wasm shim is some non-trivial javascript to say the least.

* based on the above: how far has wasm enabled a "c/c++/rust developer" to easily port their application to the web without also being a super strong frontend developer?

I'm trying to draw a contrast between:

A) I have business logic which is not well suited for javascript (image processing on binary data, figma, etc), and I have rust/c++ developers AND javascript frontend developers to build the application

B) I am a rust/c++ developer who wants to target the web with their rust/c++ product, but doesn't want to dive deep into frontend/js/react tech.

In the long term, I am optimistic that scenarios like "B" will be opened up by application (web) frameworks which target wasm via backend technologies and their MVC patterns. But in the short term, the amount of "glue code" to be written is non-trivial.

You can get DOM access with WASM right now by importing host functions. I have managed to write a simple virtual DOM rendering algorithm using WASM GC and imported DOM functions. Only a small bit of JavaScript is needed to instantiate the module and pass in the host functions.

JS hasn't been the only "real game". People have been happily shipping apps with ClojureScript, TypeScript, Scale.js, PureScript etc compile-to-js languages for years (12+ for CLJS[1]) with much easier JS interop and integration with buid systems etc. WASM even with this is a pretty poor fit for managed languages that don't have heritage in the native compilation platforms.

[1] https://www.clojure.org/news/2011/07/22/introducing-clojures...

Kotiin already compiles to JavaScript, but to my understanding it has seen limited use in browsers. So why would people use it to target wasm if they don't already use it to target JS?

Kotlin now also targets WASI for server-side Wasm applications. Combined to Kotlin/Wasm browser support, that’s a powerful combo.

Notice the footprint is very small (3k for an hello world).

The revenge of plugins is almost complete.

I don't see the "binaryification" of the web platform happening any time soon (if ever). The web is (and should remain) fundamentally about the transmission of documents. Javascript+DOM allows for the dynamic updating of said documents, and this is what the main thread (asynchronous event loop) is all about. For all "heavy lifting," the logic should go into worker threads, where there isn't any DOM access anyway. I think a decent rule of thumb is that WASM modules should generally only be used in these kinds of off-the-event-loop types of worker threads.

(See https://linuxontheweb.github.io/ for my implementation of a new kind of web application platform where these kinds of ideas can start becoming a reality.)

I like the idea of the web / js / DOM being for documents, but if you look at all the new browser javascript APIs it’s clear we’re constantly moving further and further away from documents. Once developers have all these tools available they build things and the cycle continues towards what seems like a pretty complete application runtime environment within the browser.

As long as web applications are necessarily embedded inside of SCRIPT elements, which are themselves necessarily embedded inside of HTML elements, then documents will always have priority over applications.

There are basically two variants of the web: The document web and the application web. I think there's space for both.