31–40 of 62 posts
Wow, the contortions we go through trying to make HTML into a full-blown native application platform, instead of writing native applications. I'm impressed, but good god do we spend a lot of time reinventing the wheel within the limitations of browser engines.
So if I'm reading it right, it looks like it's trying to replicate the DOM interface almost exactly (but in a web worker)! Which means that any UI library should be able to plug into this system and run mostly off the main thread for most of the application's life, bringing JS to parity with a lot of "native" development where you do most of your work on a "main" thread, and only touch the UI thread when you want to…
doesn't the added vdom lead to redundancy?
Earlier quoted context omitted.
That's where stuff like batch inserting the elements (split your table up into groups of 100 elements, and add one every so often to keep the UI smooth), and virtual-rendering (only show the part of the list that is actually visible) are going to be the only real solution. Oh, and making your DOM simpler if possible, but normally there's not a ton of gains to be had there in my experience.
There's a lot of tricks you can try, but even rendering the first set of visible rows can take more than a 60fps time window will allow.
Earlier quoted context omitted.
I think this is more useful from the perspective of, if you have some busy task and you need to get the data back into the DOM, what can you do? You either need to build a messaging layer, which was the defacto way, or use this. I have a few projects that could benefit from this, being able to put a progress bar in the DOM and have the worker update it in a clean API is pretty neat.
Often though, a better pattern for that is to have your "compute thread" not know anything about the UI - it just sends back packets of result data, or serialized model updates, which the view-model layer back in the "UI thread" uses to rerender. 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...
Earlier quoted context omitted.
I imagine one of these DOM is "fake", i.e. it doesn't really have access to the UI. After all, the DOM is a generic API to work with structured node based documents. Changes to the DOM would still need to be serialized in order to be sent to the UI thread.
Yes I know. Which is why I asked what happens if two Workers try to make incompatible changes at the same time. How does this library resolve conflicts when applying the changes from the fake DOM to the real one? 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.
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.
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
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.
Earlier quoted context omitted.
I imagine one of these DOM is "fake", i.e. it doesn't really have access to the UI. After all, the DOM is a generic API to work with structured node based documents. Changes to the DOM would still need to be serialized in order to be sent to the UI thread.
Yes I know. Which is why I asked what happens if two Workers try to make incompatible changes at the same time. How does this library resolve conflicts when applying the changes from the fake DOM to the real one? 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.
tldr; aim is to bring scripting to AMP pages
I don't quite understand how busy your page must be if you feel that you're held back by the performance of one thread with the DOM. You know, DOM isn't really for video games or realtime data visualization.
I could see this being used in a "pre-fetch" manner for single-page applications. For example, preparing and rendering the next page or component before the user has opened it. So when the user does click to open the next page or component, it can be displayed immediately. The ability to perform that rendering in the background without blocking the main thread would offer some real value.