I'm a web dev and I don't know much about WASM. I've been wondering - will it be possible to render something to the screen without first going through the DOM? Or is the DOM literally the only way to display content?
It's enticing to imagine being able to open a wasm file and seeing an application on the page. Kinda like how you can just open an image or a video in the browser, without rendering it via an html document.
You can take a Canvas element and draw anything you like on it - even hardware accelerated 3d using webGL. I think there are some projects trying to (re) implement a 2d user interface, rendered onto canvas.
However the issue id that you will need to reimplement a lot of things the browser already does for you: rendering text, scaling, zoom, input methods, highlighting text, accessibility features, etc...
Unless you use case is very different from normal browser usage (e.g. 3d graphics) the advantages seem dubious to me.
Mostly I was just curious, although I could see one argument for it. HTML/DOM was meant to display interactive documents, which is far smaller in scope than what browsers are used for today.
A lot of the web today (web applications in particular) are therefore hacks of HTML. I know that the standard has responded to these uses by incorporating more application-level features, but IMO this has become burdensome and bloated.
There are lots of issues coming from the fact that we're attempting to write application-level code on top of a platform that has historically been designed for documents.
You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
React and friends solves that problem for you. It was designed to be a UI layer for web apps. It does use the DOM at the end, but you are not managing it anymore.
I don't think the downplay of HTML/CSS (referring to it as hacks) is valid just because 30 years ago it was about document delivery. You have to start somewhere. It took a while and it made some people fed up with it, I've seen that. I still have some PTSD from hacking IE6, those were the real hacky days. Nowadays most stuff just works.
What we have as a spec is the lowest common denominator that passed the test of tons of communities and companies, and from this perspective it's incredibly successful.
It seems probable to me that some actual application GUI toolkits will target WASM+Canvas and finally give us good-looking, capable, better-performing, easy-to-work-with GUI application development in the browser, yes.
HTML's pretty bad at the use case it's been smushed into, and hacking a semi-reasonable GUI toolkit on top of it in Javascript is bound, no matter how good the effort, to be slower and less pleasant than something designed from the beginning to be used for heavily interactive application GUIs.
The two big risks I see are: 1) the tinkerer-friendliness of the Web is, very likely, going to take a big step backwards as WASM use spreads, and 2) there's a chance we'll end up with 100 different WASM GUI toolkits and they'll be super-trendy and all the job ads will demand familiarity with at least one of them, but not a single goddamn one of them will handle accessibility and various edge cases half as well as plain HTML or actual native development does (to be fair, Javascript that writes around limitations in HTML by re-implementing parts of it often has the same problem)
> You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
Well, there are three ways to do that. You can use a 2D canvas, you can use a WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to what you get when you’re programming a desktop application anyway. This is a cornucopia of alternatives here! I’m having a hard time understanding what is missing.
These “use the DOM” in the same sense that desktop applications use the window manager. You’re just drawing into an element in some compositing system. This is fine, there’s no real benefit to bypassing the DOM—like window managers, you can bypass the compositor when possible and go through the compositor when unavoidable. This is transparent to the application programmer.
What is missing is a way for one's wasm code to make WebGL or 2D canvas calls (or even write directly into a bitmap canvas), without writing a bunch of Javascript trampoline / thunk / whatever code. If I'm mistaken, a pointer to some C / C++ / Rust code that compiles down to wasm that actually touches a canvas that's being displayed in the browser would be most appreciated.
There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code.
Of course, why not just use a small HTML+JS shim for your WASM?
HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.
This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.
I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.
It has not been my perception that that's an aspiration or a goal of WASM, but there's much I haven't read. Can you point me to where this is stated as one of WASM's goals?
That’s a short-term view. There’s going to be legacy cruft either way. Either we have the existing HTML + JS with WASM alongside it, or we introduce a ton of new APIs to let WASM function by itself.
Using the existing HTML + JS avoids creating as much future legacy cruft.
It's enticing to imagine being able to open a wasm file and seeing an application on the page. Kinda like how you can just open an image or a video in the browser, without rendering it via an html document.