81–90 of 337 posts
Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…
Earlier quoted context omitted.
> The key observation about HTML templates is that usually large portions of them don't change with new data. Isn't this a core idea underneath the https://fresh.deno.dev/ "islands" and I believe the https://astro.build/ framework when they confronted issues around hydration/SSR? https://www.patterns.dev/posts/islands-architecture/ Clearly there's some overhead via the vDOM and simply using React-like templates when…
vdom is overhead server-side too. When rendering HTML on the server you really want to stream longer pre-allocated strings as much as possible. The serialization overhead of converting many small objects to individual HTML tags shows up in profiles. And when you want low latency and the ability to handle high loads, it matters.
Poorly written react code isn't performant and removing the Virtual DOM will not fix your problem. It's a hill I'm willing to die on. Many engineers seem to struggle with unnecessary re-renders, to the point where I see long tasks in the performance tab. Clicking a button shouldn't lock the UI thread for 2 seconds.
I don't think that many junior/early mid React developers know that the whole tree gets re-rendered. Those that do, I don't think they fully understand when and where to `useMemo` and `useCallback` to optimize. It tends to get overused or used in a way that doesn't actually memoize the parts of the component that doesn't change. Then adding in state management only makes it more complicated in some cases depending on…
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…
I see Solid to the left of Inferno in that benchmark, though they are very close indeed. Solid's code looks weird in its own ways I guess, but it looks less hacky/hand-optimized to me.
Inferno seems to use less memory though, which seems interesting. Solid isn't fully memory optimized though, it could beat Inferno with more memory optimizations potentially.
Svelte is being smart and skipping comparisons in the places it knows the result is static. That's nifty. But it also means you have to depend on svelte getting it right every time, in all scenarios.
Long term - I think this is probably the right approach, but it feels very similar to the -03 c++ optimization flag: There was a fairly long period where enabling that flag was considered risky. Each extra transformation carries opportunities for bugs.
It also means extra work at code generation time - it's building a vdom engine specific to your template (again - this is nifty!). Probably not a huge deal, since js build tooling is seeing a LOT of focus on speed, but it's there.
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(…
Just have a suspendLayout resumeLayout / beginUpdate endUpdate method like Winforms surprised doesn't exist after all these years
1. BeginUpdate stops a control from repainting itself and that is what browser is doing already - no painting happens at the moment of JS execution. So primitive "postpone painting" does not really help.
2. element.update(callback) or DOM.mutate(root,callback) shall be a single method - no one wants EndUpdate() calls to be skipped because of errors thrown and the like.
Earlier quoted context omitted.
Short answer: yes. Crawlers are based on consuming text. HTML is text. Sites that optimize for SEO also use JavaScript to provide SEO context. The specific standard is called JSON+LD; pretty much any site that you use where SEO matters has JSON+LD, RDF-a, or Microdata embedded in the HTML. You can see these structures if you use the Schema.org validator: https://validator.schema.org/ Try plugging in a URL like Reddit…
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…
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.
> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…
> React also needs to hydrate every element even when it isn't ever going to change That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-com...
Earlier quoted context omitted.
You can't parallelize DOM updates. All has to happen in the main loop. This is not gonna change for the web as it is today.
I don't think that's what OP is saying. They're saying that (e.g.) calculations are made on each appendChild() call when it would be more efficient (when you know you're going to be inserting a ton) to suspend all calculation, insert 1000 nodes, then resume calculations. Something akin to setNeedsLayout() on iOS: https://developer.apple.com/documentation/uikit/uiview/16226...