21–30 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.
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.
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.
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?
1. https://github.com/chrishtr/display-locking/blob/master/expl...
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.
It's true. I'm grateful though whenever I need to use a computer that's not mine and need access to stuff.
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.
WebWorkers: Same great JavaScript, now with concurrency bugs!
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?
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.
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.
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...
WebWorkers: Same great JavaScript, now with concurrency bugs!