Hacker News Reader

Comment by calaphos | Hacker News Reader

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.

View on HN

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.

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

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)

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

Reply on news.ycombinator.com