And having a custom JS compiler isn't pure overhead?
Virtual DOM is pure overhead (2018)
101–110 of 337 posts
Re: Virtual DOM is pure overhead (2018)
#102Yes 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(…
[deleted]
Re: Virtual DOM is pure overhead (2018)
#103Yes 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(…
innerHTML doesn't preserve event handlers. So you're either reassigning event handlers over and over or relying on delegate handlers everywhere.
And while your statement makes intuitive sense regarding performance, actual measurements show clearly that idiomatic Svelte (and other modern frameworks) routinely beat VDOM-based efforts handily in their idiomatic cases and often even when folks jump through the performance optimization hoops needed for VDOM.
VDOM is pure overhead. Better than manually aligning writes before reads manually a la 2010, but noticeably worse than the current crop of compiled offerings.
Re: Virtual DOM is pure overhead (2018)
#104Earlier quoted context omitted.
Just have a suspendLayout resumeLayout / beginUpdate endUpdate method like Winforms surprised doesn't exist after all these years
Not so easy unfortunately. 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.
> no one wants EndUpdate() calls to be skipped because of errors thrown and the like.
but surely with enough effort and care this should be a non-issue? And maybe auto-rollback on error?
Re: Virtual DOM is pure overhead (2018)
#105In more cases than not I've noticed the choice of single page app itself is pure overhead. 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.
Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate.
And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is a 4+ year old $999 Costco special.
Well made React sites can run just fine on devices like that, and Svelte runs even better.
Also SPAs scale better, I remember the days of website backends being slow, with page loads taking forever, massive amounts of HTML being generated server side using slow scripting languages.
Sending a JSON blob of some fields to the browser and having the browser update some nodes makes a lot more sense than the old school way of reloading the entire bloody page to change a couple fields.
Re: Virtual DOM is pure overhead (2018)
#106In more cases than not I've noticed the choice of single page app itself is pure overhead. 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.
Totally agree. Definitely a reason I avoided any SPA on findthca.com. I've never had a user complain that it needed one.
Re: Virtual DOM is pure overhead (2018)
#107I'd argue this is essentially just an optimized (and therefore potentially more buggy) virtual dom. 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: The…
Tell us you've never tried Svelte without actually saying you've never tried Svelte.
You would have likely not said this if you had ever looked at Svelte-compiled JS. The amount of mutation is surprisingly small and easy to follow. Especially when coming from a world with JSX.
Re: Virtual DOM is pure overhead (2018)
#108I absolutely love articles like this. Written by people with more critical thinking skills than technology fetishism.
Great to see.
Re: Virtual DOM is pure overhead (2018)
#109Yes 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(…
Is this still the case with the newer transactional methods like Element.append(), Element.before(), and DocumentFragment? When I manipulate the DOM I try to create the entire structure in a fragment and the use .append(...) only once.
This:
element.append([array of Elements]);
for(const el of [array of Elements])
element.appendChild(el);
But think about updates like this:
element.patch( 1}>There {n > 1? "are": "is"} {n} bottle{n > 1? "s": ""} of beer on the wall);
Re: Virtual DOM is pure overhead (2018)
#110Earlier quoted context omitted.
> 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.
I don't get it. JSON+LD is not Javascript. It's not even spelled the same? If you are meaning that your Javascript is able to read JSON+LD, so too could you WASM in this hypothetical world we're talking about.
JSON is literally JavaScript Object Notation, my friend.