Hacker News Reader

Comment by zamalek | Hacker News Reader

It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself).

I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.

View on HN

The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet).

DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem.

[0] https://github.com/webassembly/interface-types

I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance).

LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it.

Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!

GC in wasm is proposed for two purposes: (1) DOM objects are garbage collected and so first-class support for them in wasm requires a GC; (2) optimal moving GC requires runtime support. A garbage collector needs to be able to walk stacks to find the root set of pointers, but the stack is hidden from the program in wasm.

In mobile code, a builtin runtime means less code to download, which may be preferable to GC performance.

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.

I think this will happen eventually… but there’s a lot of work to be done before it happens.

> > will it be possible to render something to the screen without first going through the DOM?

> You can take a Canvas element and draw anything you like on it

Don't you need to first go through the DOM to get the canvas element?

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?

Because it slows things down by 3 or 4 orders of magnitude?

Because there is value in ditching legacy cruft.

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?

https://webassembly.org/docs/high-level-goals/

> 3. Design to execute within and integrate well with the existing Web platform:

> * execute in the same semantic universe as JavaScript

> * access browser functionality through the same Web APIs that are accessible to JavaScript

Lawyering aside, I would say that this is pretty much the same thing as "enabling the development in web apps in other languages".

You still capture the vast majority of that value by having a minimal “legacy cruft” loader that sets up, and passes control to, the modern toolchain

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.

If you don't want cruft, don't make a browser-based app?

Currently the DOM is the content. You can not separate those.

I don't think changing this is even desirable. It's much easier and cleaner to standardize a stdlib of accessors.

> because the DOM and JS (meaning the GC) are very coupled.

This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.

It's interesting that the web standardized on one programming language.

In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.

It's easy forget these days, but Windows had this thing called Active Scripting, that was basically a set of COM-based interfaces for scripting languages to expose their functionality OS-wide, and for apps to use any scripting language available on the system. And Internet Explorer, at the peak of its popularity, used that interface to implement the <script> tag - so long as the user had some language installed on their machine, it could be used to script web pages in IE. Active Scripting came with JavaScript and VBScript supported out of the box, which is why both were available in IE. But there were quite a few third-party ones - I recall seeing Perl, Python, Tcl, and REXX.

But, of course, other browsers didn't have that. And even at the time when some websites really only cared about IE, they couldn't assume that people had any third-party runtimes installed - so you very occasionally saw VBScript, but pretty never anything else.

It doesn't seem to be in fashion these days, but some years ago language-agnostic object models for extensibility were common: Microsoft's COM, Mozilla's XPCOM, LibreOffice's UNO, IBM's SOM, etc.

Even back inn the 90s, people were thinking of the browser as a potential OS-like platform. Netscape certainly did, and that's why MS was so worried about them.

Databases. Postgres supports pgSQL, Tcl, Perl, and Python out of the box, and can support others with appropriate bindings.

What other languages do modern browsers support in the script tag?

Originally, Netscape was going to support Java along with JS. Microsoft had VBScript. And Google tried Dart.

But now, it's pretty much just JS.

> It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled.

AFAIK, the reason the DOM and JS GC are very coupled is because there can be loops between the DOM and JavaScript: the DOM can hold JavaScript resources, which themselves can hold DOM resources. As long as these loops are avoided (by not allowing the DOM to hold resources within the WASM heap), this is not an issue.

Reply on news.ycombinator.com