The problems I ran into, and I suspect this project will run into many of the same things were:
1. Events are synchronous so to make them async you have to preventDefault them, send to the worker, and then send back and re-dispatch them (if the worker didn't preventDefault). This works ok for many events like 'click' but not at all for things like touch events.
2. The debugging experience in the worker is not very good. Things you take for granted like being able to do `document.querySelector('.app')` and get a pretty-printed DOM object in the debugger do not work when that object is a fake DOM-like object.
3. There are a lot of DOM APIs and they continuously grow. Trying to implement everything is impossible. Many things can't (like events described above) be implemented 1 to 1. So it's a constant game of whack-a-mole.
Of these problems #2 is the biggest though. Devtools has a lot of really nice integrations with the DOM that you just lose when you're not using the actual DOM. So users have to decide if the tradeoffs are worth it. AMP might have an advantage in this regard, since you literally have no other choice; use their worker DOM or you can't run your app at all.
I think it works better because the original framework wrestles with the same limitations you mention (though an upcoming rearchitecture doesn't), and while it is by no means perfect, some early results are promising: https://rndom-movie-demo.now.sh
It also reads like it might have some kind of virtual-dom implementation to kind of optimize the actual renders needed in the UI thread? (although I'm not very sure about this part).
But this looks incredible from a first glance!
If you, for instance, blew away the whole DOM and re-rendered it (e.g., setting `innerHTML`) on every state change, the cost is going to be far higher than just tweaking the few things that might need tweaking, like on a keypress. If you're not keeping a virtual DOM around, there's no way to know what the diff is between your new and previous state to be able to make those tweaks.
Except it’s actually local, and shouldn’t deal with sensitive data.
In fact, this doesn't even require 2 Workers, you could get a conflict with a single Worker if you're also making DOM changes on the main thread.
1. https://github.com/chrishtr/display-locking/blob/master/expl...
What's AMPs goal here, is it to have untrusted third parties write their own UI's, but still run that whole site on the google domain? I hate to be cynical but if so that's the same old walled garden approach to further centralize the web
It would be far easier to just rate the page performance specs while indexing, and provide a free google CDN for heavy assets to protect privacy so they can preload most of them
This does look exciting for things like embedding small components from untrusted third parties into the middle of an article or page though
I'm impressed, but good god do we spend a lot of time reinventing the wheel within the limitations of browser engines.
I'm no expert in native or web development, but I don't know of any native GUI framework that looks as good as browser rendering does, is free, is easy to distribute, and secure.
1. You're not beholden to the app stores' whims.
2. It literally is "write once, run everywhere"
3. Webassembly & WebGPU add performance & language independence
For most cases, the web is a viable, nay superior alternative.
For cases with special sensor access & ultra high speed (rich games, Video encoding) native apps are the only way.
[1]: https://speakerdeck.com/cramforce/workerdom-javascript-concu...
If you do all that work in a worker and then only update the real DOM once, it will be much faster.
Render/paint is the slowest part in a JS application.
Oh, and making your DOM simpler if possible, but normally there's not a ton of gains to be had there in my experience.
At least, that is how it worked a few years ago.
tldr; aim is to bring scripting to AMP pages
You know, DOM isn't really for video games or realtime data visualization.
If React's virtual DOM diffing is epxensive enough to be a bottleneck in some applications though, I could see an advantage to moving that off thread...
I'm not saying having the lib is bad, but I don't see a justified use-case for it.
The ability to perform that rendering in the background without blocking the main thread would offer some real value.
If you use server-side rendering (for example, if you use PHP on your server) then you won't need all of this and pages will load instantly without any complicated preloading.
Angular can do this out of the box https://blog.angularindepth.com/angular-with-web-workers-ste...
Not necessarily -- Web Workers enable you to take advantage multiple CPU cores. You could, potentially, offload some of the rendering work to a CPU core that would otherwise go unused.
But I agree, if you went to the extreme case, pre-rendered everything the user could click on and utilized all CPU cores, then you'd definitely create a performance problem for yourself.
So now there are two VDOMs
Or what happens when two different users try to make incompatible changes to the same Google Doc?
Or what happens when you try to GIT Merge a commit that has incompatible changes?
It’s your code, so it’s in your control what happens, and also in your control how to react to what you can’t control.
You can write code that avoids conflicting manipulations (let’s say all the dom manipulations only ever happen on one thread) or you can write code that handles the case... It’s a case by case kind of thing, there is no one answer.
The DOM API does not have any way to even notify the client that their DOM manipulation failed.
The only way I see that working out nicely is if you can know the height of the table in advance, which is generally not the case.