4 ms·

Encapsulate it into two functions: window.getState(); window.setState(); You could even use document.querySelectorAll() to go through all the elements on your

Encapsulate it into two functions: window.getState(); window.setState(); You could even use document.querySelectorAll() to go through all the elements on your page, and update them based off values in the state, whenever window.setState() is called. This is basically all front-end frameworks in a nutshell. You've invented reactive programming in the browser.

tomduncalf 4y ago
Perhaps my way of thinking is React-centric but this feels like a pretty inefficient way to do it. Feels a bit like reinventing the wheel poorly when things like MobX exist, sure it’s simple to start off but then you hit performance issues or issues with dependent state etc. etc. and you realise why, for all the derision they sometimes get, libraries exist to solve this problem and they are useful. But for a simple thing built with JS that isn’t going to need to scale to a large codebase or whatever, sure, keep it simple!
- Kiro 4y ago
  I build games where I run a global setState on the root component 60 times a second and even with deeply nested components it's not even a factor in performance.
  - sibeliuss 4y ago
    Are you talking about using React, or some kind of home-rolled setState function on a simple object?
- acdha 4y ago
  If you don’t have the overhead of React you have multiple orders of magnitude more headroom. That’s enough to push common UI idioms as far as they can go in many cases - for example, interactive tables with at least 10^5 rows perform well in modern browsers so using the DOM means you can keep things simple and fast without having to struggle with the scrolling, text selection, accessibility, etc. concerns that custom widgets entail. An awful lot of applications exist where you need more than hundreds of records but fewer than millions.
  - tomduncalf 4y ago
    Interesting, I wonder if the overhead of updating UI based on state “efficiently” (eg MobX style tracking of what should re-render when certain data changes) would actually be slower than brute force updating everything in this scenario? A bit like I’ve heard people talking about just rendering the UI to a canvas, a whole new render 60 times a second, is actually the most efficient way to update a UI for certain cases like really big stock ticker displays (versus selectively re rendering bits of HTML)
sibeliuss 4y ago
Unfortunately, it's not so simple! For anything non-trivial you'd have to add some kind of listener or tag to every node, find said node, and then update (ideally in a performative way). Said updates cannot destroy existing state, but must patch it. Updates must also not break existing attached event listeners. The list goes on and on.
- Olreich 4y ago
  Things are faster than you’d expect. Tables with millions of items don’t work in any framework, but tables with a hundred items work in all of them. Since no one has really cracked the nut on performant UIs with lots of things going on, anything homegrown will be simpler and performant enough compared to the major competition.
  - sibeliuss 4y ago
    There is definitely truth to this, I agree.
whycombagator 4y ago
That is one way to do it, albeit a seemingly naive way. I can’t imagine the entire page is linearly searched to update a UI element these days. Perhaps an entire component in some frameworks? I don’t know and can’t easily find out the time complexity of things like React setState(), but would hope that for frontend code bases where there is a build step(s) and/or for typed frontend languages we could achieve better than linear (especially if N is every element on the page)

tomduncalf 4y ago

Perhaps my way of thinking is React-centric but this feels like a pretty inefficient way to do it. Feels a bit like reinventing the wheel poorly when things like MobX exist, sure it’s simple to start off but then you hit performance issues or issues with dependent state etc. etc. and you realise why, for all the derision they sometimes get, libraries exist to solve this problem and they are useful. But for a simple thing built with JS that isn’t going to need to scale to a large codebase or whatever, sure, keep it simple!

Kiro 4y ago
I build games where I run a global setState on the root component 60 times a second and even with deeply nested components it's not even a factor in performance.
- sibeliuss 4y ago
  Are you talking about using React, or some kind of home-rolled setState function on a simple object?
acdha 4y ago
If you don’t have the overhead of React you have multiple orders of magnitude more headroom. That’s enough to push common UI idioms as far as they can go in many cases - for example, interactive tables with at least 10^5 rows perform well in modern browsers so using the DOM means you can keep things simple and fast without having to struggle with the scrolling, text selection, accessibility, etc. concerns that custom widgets entail. An awful lot of applications exist where you need more than hundreds of records but fewer than millions.
- tomduncalf 4y ago
  Interesting, I wonder if the overhead of updating UI based on state “efficiently” (eg MobX style tracking of what should re-render when certain data changes) would actually be slower than brute force updating everything in this scenario? A bit like I’ve heard people talking about just rendering the UI to a canvas, a whole new render 60 times a second, is actually the most efficient way to update a UI for certain cases like really big stock ticker displays (versus selectively re rendering bits of HTML)

sibeliuss 4y ago

Unfortunately, it's not so simple! For anything non-trivial you'd have to add some kind of listener or tag to every node, find said node, and then update (ideally in a performative way). Said updates cannot destroy existing state, but must patch it. Updates must also not break existing attached event listeners. The list goes on and on.

Olreich 4y ago
Things are faster than you’d expect. Tables with millions of items don’t work in any framework, but tables with a hundred items work in all of them. Since no one has really cracked the nut on performant UIs with lots of things going on, anything homegrown will be simpler and performant enough compared to the major competition.
- sibeliuss 4y ago
  There is definitely truth to this, I agree.

whycombagator 4y ago

That is one way to do it, albeit a seemingly naive way. I can’t imagine the entire page is linearly searched to update a UI element these days. Perhaps an entire component in some frameworks? I don’t know and can’t easily find out the time complexity of things like React setState(), but would hope that for frontend code bases where there is a build step(s) and/or for typed frontend languages we could achieve better than linear (especially if N is every element on the page)