Re:Show HN: FastDom – Lightweight replacement of React and MobX
by t0astbread on Monday March 25, 2019 @07:40AM
(#19481683)
This looks neat but was React itself ever the problem with slow web apps? I haven't looked into this so correct me if I'm wrong but from my impression, slow libraries are the biggest problem with slow performance in SPAs.
Re:Show HN: FastDom – Lightweight replacement of React and MobX
by ricardobeat on Sunday March 24, 2019 @12:46PM
(#19477285)
I think there's some misunderstanding of performance in the browser here. This library might make smooth animations when its observer system is used (doing it in parallel to the main update flow is best), but only while complexity is kept low.
Looking at the code, all it does is queue each observer listeners using RAF, the moment the component tree takes longer than 16ms to render, or a single component does a bit more work than expected, you'll get dropped frames. To actually ensure 60FPS it would need a more sophisticated scheduling system that is able to time-slice the updates (== asynchronous rendering) and possibly interrupt updates.
Re:Show HN: FastDom – Lightweight replacement of React and MobX
by pyxru on Sunday March 24, 2019 @02:19PM
(#19477837)
Render 100 node in browser it is less then 16ms, if you need hard logic, you can use reactive for that. Library first of all created all child deep, after that appendChild to DOM in memory, when all child and root ready and after that will be append in place on page.
Re:Show HN: FastDom – Lightweight replacement of React and MobX
by ricardobeat on Sunday March 24, 2019 @03:02PM
(#19478081)
> if you need hard logic, you can use reactive for that
What do you mean by that? Any logic still has to execute in the same 16ms budget. In any case, it's pointless to discuss in a vacuum, I suggest you implement something like the JS Framework Benchmark [1] or DBMonster to see where it stands in fact, and then optimize from there.
Re:Show HN: FastDom – Lightweight replacement of React and MobX
by pyxru on Sunday March 24, 2019 @03:26PM
(#19478245)
Thank you for link, i 3rd week try found it. Yes of course optimisation always in progress. I tested render 500 nodes node(simple div) and every 10ms updating 50y from them, fps was 60.
Tongue in cheek, I'm going to hold you to that ;)
Looking at the code, all it does is queue each observer listeners using RAF, the moment the component tree takes longer than 16ms to render, or a single component does a bit more work than expected, you'll get dropped frames. To actually ensure 60FPS it would need a more sophisticated scheduling system that is able to time-slice the updates (== asynchronous rendering) and possibly interrupt updates.
What do you mean by that? Any logic still has to execute in the same 16ms budget. In any case, it's pointless to discuss in a vacuum, I suggest you implement something like the JS Framework Benchmark [1] or DBMonster to see where it stands in fact, and then optimize from there.
[1] https://rawgit.com/krausest/js-framework-benchmark/master/we...