91–100 of 337 posts
SPA technology brings some key advantages but also a whole new realm of cost and complexity. It's my experience that SPA popularity has convinced many folks to use it when they really don't have a practical reason to justify it.
From the end of this article: “Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.“
Okay great, it’s not pure overhead.
Can we please talk about how much reactive programming sucks for UIs? I miss all the people who switched from angular to react for a reason in these discussions... I'd bet none of those are going to move to svelte.
Earlier quoted context omitted.
Here's an excerpt of some Javascript found on the Amazon link: window.ue_ihb = (window.ue_ihb || window.ueinit || 0) + 1; if (window.ue_ihb === 1) { var ue_csm = window, ue_hob = +new Date(); (function(d) { var e = d.ue = d.ue || {}, f = Date.now || function() { return +new Date }; e.d = function(b) { return f() - (b ? 0 : d.ue_t0) }; e.stub = function(b, a) { Feel free to visit it to find the entire script. It is mu…
> Why couldn't its WASM parser pull out the same information There's currently no standard. If there's a will, there's a way. JSON+LD is the standard for JavaScript based metadata.
Earlier quoted context omitted.
That's an interesting comparison because: - Svelte is actually strangely slow, I mean there's *one* interesting optimization that having a custom compiler/transform allows you do to for free, which is deep cloning nodes in one go rather than creating them one by one each time, and they ain't doing it. Also, I don't have proof of this anymore, but I had tried running my relatively naive framework without the deep clon…
Inferno was one of the first frameworks to embrace compiling JSX as an opportunity for advanced performance. the `$HasTextChildren` is a special attribute their JSX compiler (its a babel plugin) uses to optimize the tree at that point in time the that flag is found. It can do advanced optimization knowing that the children of that component are purely text VNodes. There are other flags available too that optimize dif…
https://krausest.github.io/js-framework-benchmark/2023/table...
Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…
Once a view is created, it can't be processed by JS. It can't be stored in an array or an object. You can't count or individually wrap children. This makes it harder to create flexible API's [1].
The question is: are we willing to give up the expressivity of React for extra performance?
I am leaning towards "no", because I believe React's performance issues mainly come from its memoization-based reactivity model rather than the VDOM. When applying `.useMemo` in the right places I can create perfectly performant apps. However, this requires profiling and is often unintuitive.
[1]: for example https://news.ycombinator.com/item?id=33990947
Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…
> And virtual DOM reconciliation implementations in browsers can use only public APIs like appendChild(). Why can't they also use innerHTML? Meaning, they could define a cost function where they deduce that it's cheaper to use innerHTML on a potentially larger than necessary scope if the alternative is >some_threshold for modification API calls.
Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…
> And virtual DOM reconciliation implementations in browsers can use only public APIs like appendChild(). Why can't they also use innerHTML? Meaning, they could define a cost function where they deduce that it's cheaper to use innerHTML on a potentially larger than necessary scope if the alternative is >some_threshold for modification API calls.