6 ms·

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

ake1 9y ago
do you know of any ongoing work?
avaer 9y ago
I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.
- dfox 9y ago
  Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.
  - rictic 9y ago
    For an example of this model today, take a look at the wonderful A-Frame library for doing 3D scenes, including web VR.
- dragonwriter 9y ago
  Or something like X3dom will take center stage.
dragonwriter 9y ago
Declarative UI systems that look a lot like HTML+CSS+JS, keep cropping up in other domains besides the web; I think, but for increasing freedom to replace the JS part with some other languages to specify behavior, the basic model will be around for a long time.
kowdermeister 9y ago
No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s. Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die. That's the reason we have so many Electron based apps, because it makes UI building really simple.
- rickycook 9y ago
  drawing the parallel between electron and gui toolkits probably isn’t right. i think there are lots of things at play here. just for starters: - abstracts lots of file handling - js is much easier than most languages to pick up and learn - js has a large dev base because of the web - people are well versed in coding for the web, and adding a “native” layer on top of that is actually quite easy - cross platform c/c++ in general is not so simple even without the GUI
- pjmlp 9y ago
  There isn't anything about Electron that I feel it is simple over Delphi, WinForms, JavaFX, Android, Cocoa, Qt, XAML, other than being easier for those that grew with HTML/CSS.
  - ghettoimp 9y ago
    Caveat: It's been a long time since I've used GUI toolkits like Gtk+ and QT, so this may be an out-of-date perspective. What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2. Add button2 to the box. Tell the box to grow button2 when it is resized. Create button 3..." The declarative style of HTML/CSS seems so much better. The grouping of elements becomes apparent just by looking at how they are nested, with no need to keep track of what gets added to what. And CSS gives you a really rich ability to select groups of elements, style them, try out new styles, reuse styles across pages, and so on. CSS has definitely gotten really complicated. But then, I could never build anything in a GUI toolkit without constantly referencing the API docs to figure out how to do this or that, either...
mr_toad 9y ago
The DOM will be around as long as the web has documents.
pcwalton 9y ago
I'm nearly certain that this will not be the case. Once you reinvent everything that the DOM does, it's highly unlikely you'll end up faster than the DOM. Everyone thinks that the rendering engines in browsers are easy to beat in terms of performance. I thought that too, until I implemented one. They are definitely beatable, but not easily, and certainly not with an architecture like that of Qt or GTK.
- gpm 9y ago
  Are there any resources that describe the sort of UI rendering engine you think you would need to beat browsers?
  - pcwalton 9y ago
    I don't think it's really possible to do much better than the next-gen browser architecture (Servo, fully-fleshed-out Quantum) if you support the entire feature set of browsers (once typed CSSOM is a thing, anyway). You can certainly do better in constrained environments, though. For example, Leo Meyerovich is doing really neat things with data viz, where all the elements to be laid out have the same shape and you can take advantage of that to do things like GPU layout.
    - swsieber 9y ago
      But if you're making your own UI kit, couldn't you just eschew CSS and the like? I was under the impression that part of the reason browser rendering is such a gnarly process is because of the reflow issues that CSS and HTML layout quirks/changes can cause. I would assume that you can implement a couple of layouts that prevent those sort of pitfalls and thus speed up rendering... Please correct me (you know a lot, and I'm betting some of my assumptions are wrong).
      - pcwalton 9y ago
        Sure, you could get rid of CSS, but in favor of what? You probably need something just like flexbox, and it's not easy to beat an optimized implementation of CSS flexbox in terms of layout performance (especially if parallelized). You could eliminate the restyling step by not having cascading and selector matching, but that hurts productivity and maintainability, which is why you see frameworks like GTK+ moving toward CSS-like styling. There's no free lunch here...
eyko 9y ago
You seem to ignore that even in desktop and mobile, HTML(ish)+CSS(ish)+JS is taking over.
- pjmlp 9y ago
  On mobile surely not.
kabes 9y ago
You can already replace dom with a canvas renderer. Flipchart does it with a react canvas renderer, but yet it doesn't take off, so why would wasm change that?
chrismorgan 9y ago
We’re nowhere near the point where that would be even vaguely feasible on one crucial point: accessibility. If you’re talking about rendering everything on a canvas, well, there’s been the occasional discussion about making it a11y-friendly, exposing content in it to screen readers and so forth, but nothing has really happened with it. Your WebAssembly GUI toolkit is going to be completely invisible to screen readers.
xg15 9y ago
So in the end we really do end up in the alternate future where every website is just a single giant SWF file - except instead of Flash, it's WASM. Hooray! /s

ake1 9y ago

do you know of any ongoing work?

avaer 9y ago

I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.

dfox 9y ago
Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.
- rictic 9y ago
  For an example of this model today, take a look at the wonderful A-Frame library for doing 3D scenes, including web VR.
dragonwriter 9y ago
Or something like X3dom will take center stage.

dragonwriter 9y ago

Declarative UI systems that look a lot like HTML+CSS+JS, keep cropping up in other domains besides the web; I think, but for increasing freedom to replace the JS part with some other languages to specify behavior, the basic model will be around for a long time.

kowdermeister 9y ago

No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s. Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die. That's the reason we have so many Electron based apps, because it makes UI building really simple.

rickycook 9y ago
drawing the parallel between electron and gui toolkits probably isn’t right. i think there are lots of things at play here. just for starters: - abstracts lots of file handling - js is much easier than most languages to pick up and learn - js has a large dev base because of the web - people are well versed in coding for the web, and adding a “native” layer on top of that is actually quite easy - cross platform c/c++ in general is not so simple even without the GUI
pjmlp 9y ago
There isn't anything about Electron that I feel it is simple over Delphi, WinForms, JavaFX, Android, Cocoa, Qt, XAML, other than being easier for those that grew with HTML/CSS.
- ghettoimp 9y ago
  Caveat: It's been a long time since I've used GUI toolkits like Gtk+ and QT, so this may be an out-of-date perspective. What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2. Add button2 to the box. Tell the box to grow button2 when it is resized. Create button 3..." The declarative style of HTML/CSS seems so much better. The grouping of elements becomes apparent just by looking at how they are nested, with no need to keep track of what gets added to what. And CSS gives you a really rich ability to select groups of elements, style them, try out new styles, reuse styles across pages, and so on. CSS has definitely gotten really complicated. But then, I could never build anything in a GUI toolkit without constantly referencing the API docs to figure out how to do this or that, either...

mr_toad 9y ago

The DOM will be around as long as the web has documents.

pcwalton 9y ago

I'm nearly certain that this will not be the case. Once you reinvent everything that the DOM does, it's highly unlikely you'll end up faster than the DOM. Everyone thinks that the rendering engines in browsers are easy to beat in terms of performance. I thought that too, until I implemented one. They are definitely beatable, but not easily, and certainly not with an architecture like that of Qt or GTK.

gpm 9y ago
Are there any resources that describe the sort of UI rendering engine you think you would need to beat browsers?
- pcwalton 9y ago
  I don't think it's really possible to do much better than the next-gen browser architecture (Servo, fully-fleshed-out Quantum) if you support the entire feature set of browsers (once typed CSSOM is a thing, anyway). You can certainly do better in constrained environments, though. For example, Leo Meyerovich is doing really neat things with data viz, where all the elements to be laid out have the same shape and you can take advantage of that to do things like GPU layout.
  - swsieber 9y ago
    But if you're making your own UI kit, couldn't you just eschew CSS and the like? I was under the impression that part of the reason browser rendering is such a gnarly process is because of the reflow issues that CSS and HTML layout quirks/changes can cause. I would assume that you can implement a couple of layouts that prevent those sort of pitfalls and thus speed up rendering... Please correct me (you know a lot, and I'm betting some of my assumptions are wrong).
    - pcwalton 9y ago
      Sure, you could get rid of CSS, but in favor of what? You probably need something just like flexbox, and it's not easy to beat an optimized implementation of CSS flexbox in terms of layout performance (especially if parallelized). You could eliminate the restyling step by not having cascading and selector matching, but that hurts productivity and maintainability, which is why you see frameworks like GTK+ moving toward CSS-like styling. There's no free lunch here...

eyko 9y ago

You seem to ignore that even in desktop and mobile, HTML(ish)+CSS(ish)+JS is taking over.

pjmlp 9y ago
On mobile surely not.

kabes 9y ago

You can already replace dom with a canvas renderer. Flipchart does it with a react canvas renderer, but yet it doesn't take off, so why would wasm change that?

chrismorgan 9y ago

We’re nowhere near the point where that would be even vaguely feasible on one crucial point: accessibility. If you’re talking about rendering everything on a canvas, well, there’s been the occasional discussion about making it a11y-friendly, exposing content in it to screen readers and so forth, but nothing has really happened with it. Your WebAssembly GUI toolkit is going to be completely invisible to screen readers.

xg15 9y ago

So in the end we really do end up in the alternate future where every website is just a single giant SWF file - except instead of Flash, it's WASM. Hooray! /s