Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

github.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#11

Post by Klathmon »

nitwit005 wrote: post #8

Unfortunately, in my current app, the actual issuing of DOM updates seems to be what's blocking things. Inserting large tables takes some time.

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.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#12

Post by dinedal »

aasasd wrote: post #10

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

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#13

Post by EB66 »

aasasd wrote: post #10

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.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#14

Post by nitwit005 »

Klathmon wrote: post #11
nitwit005 wrote: post #8

Unfortunately, in my current app, the actual issuing of DOM updates seems to be what's blocking things. Inserting large tables takes some time.

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.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#15

Post by paulddraper »

aasasd wrote: post #10

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.

It's for guaranteed responsiveness

Angular can do this out of the box https://blog.angularindepth.com/angular-with-web-workers-ste...

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#16

Post by aikah »

eridius wrote: post #9

If this is exposing DOM operations in a Worker and then replicating them back to the real DOM in the main thread, what happens if 2 Workers try to make incompatible changes to the DOM at the same time?

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.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#17

Post by mtarnovan »

k__ wrote: post #3
Klathmon wrote: post #2

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?

React, Vue and other modern frontend frameworks already rely on a vdom implementation.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#18

Post by eridius »

aikah wrote: post #16
eridius wrote: post #9

If this is exposing DOM operations in a Worker and then replicating them back to the real DOM in the main thread, what happens if 2 Workers try to make incompatible changes to the DOM at the same time?

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.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#19

Post by jchw »

aasasd wrote: post #10

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 don't think it's about using the DOM for anything real-time. The unfortunate truth of JavaScript (obviously when not running in a worker) is that it blocks the UI. WorkerDOM appears to be an attempt to allow you to run existing JavaScript without blocking the UI, which seems like a great idea to me.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#20

Post by thrower123 »

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.

Post reply on HN