40 ms·

The DOM is going to be the first thing to go if WebAssembly actually takes off. It's simply not a suitable performant model for a GUI event/render tree.

the8472 11y ago
The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
pdkl95 11y ago
...and the open web will be the 2nd thing to go. If businesses that rely on a walled garden approach (Facebook, a lot of "software as a service", etc) and the paranoid cartels that rely on re-creating scarcity (the {RI,MP}AA, "ebooks", what's left of newspapers) can bypass the DOM and render directly, they will. Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style? Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA? The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future. edit: fixed spelling typo
- walterbell 11y ago
  We are going to need self-declared URL labels/annotations plus third-party whitelists/blacklists, so that browsers/extensions can filter the "webs" that will splinter. This could extend all the way to suppressing the rendering of links which violate user preferences.

the8472 11y ago

The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.

pdkl95 11y ago

...and the open web will be the 2nd thing to go. If businesses that rely on a walled garden approach (Facebook, a lot of "software as a service", etc) and the paranoid cartels that rely on re-creating scarcity (the {RI,MP}AA, "ebooks", what's left of newspapers) can bypass the DOM and render directly, they will. Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style? Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA? The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future. edit: fixed spelling typo

walterbell 11y ago
We are going to need self-declared URL labels/annotations plus third-party whitelists/blacklists, so that browsers/extensions can filter the "webs" that will splinter. This could extend all the way to suppressing the rendering of links which violate user preferences.