Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

191–200 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#191

Post by PaulDavisThe1st »

c-smile wrote: post #175
PaulDavisThe1st wrote: post #166

Reading this as a native developer is a bit like reading about alchemy or astrology - two fields with their own vast suite of terminology and internal logic that doesn't fully correspond to anything real ... ... only to find out that this stuff is actually real and is how a big chunk of the visible web actually works.

> native developer You probably haven't done any native UI as native UI uses exactly the same idiom. CWnd* parent = ... parent->appendChild( new EditBox() ); native UI also uses DOM concept, it is just that instead of child elements it uses term child windows or [Gtk]widgets or [ns]View s.

> You probably haven't done any native UI

Hah. https://github.com/Ardour/ardour/tree/master/gtk2_ardour ... c'est moi

Anyway, that's not really the point I was making. Native UI can be thought of and used as a DOM model, but that's not inherent to the process unless you're literally writing traditional database+presentation+edit applications.

I was more poking light-hearted fun at the explosion in terminology and concepts exposed to someone doing web-based "frontend" development, and how little most of this has to do with HTML, CSS and the general classical model of "a browser".

Re: Virtual DOM is pure overhead (2018)

#192

Post by traverseda »

randomdata wrote: post #29
traverseda wrote: post #7

Earlier quoted context omitted.

Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm. Y…

> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?

I presumed that you were talking about replacing the HTML with a wasm-rendered app, if you're just talking about replacing javascript with compiled javascript blobs, well we already do that general type of transpilation using tools like babel.

Re: Virtual DOM is pure overhead (2018)

#193

Post by scotty79 »

vbezhenar wrote: post #159
stillkicking wrote: post #150

Earlier quoted context omitted.

>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous ren…

My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I st…

What does usePromise is supposed to do?

Re: Virtual DOM is pure overhead (2018)

#195

Post by ttfkam »

c-smile wrote: post #169
zozbot234 wrote: post #151

Earlier quoted context omitted.

Element.insertAdjacentHTML() appears to fix the event handlers issue (and similar issues with element state), since unlike innerHTML it does not replace the element it's being used on.

Again, in case of Sciter, event handlers are not the problem at all as it supports declarative event handlers: class FooBar extends Element { render() { return Foo Bar } // event handlers: ["on click at button.foo"](evt,button) { console.log("click on button foo") } ["on click at button.bar"](evt,button) { console.log("click on button bar") } } document.body.append( ); This approach will define event handlers on the…

I swear, folks and their JSX have me convinced they have Stockholm Syndrome. HTML+CSS in JS was always a pragmatic choice back in 2015, never the most elegant or most maintainable one.

It's like the folks who refused to use anything but the DOM APIs when JQuery was sitting right there. Or who keep on using onclick handlers on their div tags instead of using perfectly good HTML tags like:
JSX was never the best of any web development world. It was at best the least worst option at the time. We have better ones now.

Re: Virtual DOM is pure overhead (2018)

#196

Post by intrasight »

I've heard the term "virtual dom" for years. This article made me want to understand. It gives this example for explaining "what is a virtual dom?"

  function HelloMessage(props) {
    return (
      
        Hello {props.name}
      
    );
  }
And that returns "an object representing how the page should now look"

Aren't we developers here. How about an object type. I assume it's a DocumentFragment. Is that correct?

Then it talks in broad (i.e. useless) terms about using this object.

So my next question is: what's exactly is wrong with using a DocumentFragment to just replace that part of the DOM? For example:

   let frag = renderMyModel();

   if (destElt.firstElementChild) {
      destElt.replaceChild (frag, destElt.firstElementChild);
   } else {
      destElt.appendChild (frag);
   }
I do this with a massive DOM tree and rendering is like instant.

Re: Virtual DOM is pure overhead (2018)

#197

Post by afavour »

vbezhenar wrote: post #159
stillkicking wrote: post #150

Earlier quoted context omitted.

>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous ren…

My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I st…

I feel more and more like React wants to be separate from JS and the web. Perhaps so that it can better fit React Native, I don't know. But it wants to be its own entire world and it's an exhausting thing to pick up at times.

Re: Virtual DOM is pure overhead (2018)

#198

Post by marcosdumay »

AtlasBarfed wrote: post #137
com2kid wrote: post #105

Earlier quoted context omitted.

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…

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Is there some VM that allows limiting the CPU to a performance similar to a P4? (A PIII is way too bad for my tastes.)

I imagine Linux would have a bad time running in it.

Re: Virtual DOM is pure overhead (2018)

#199

Post by c-smile »

mrtranscendence wrote: post #177
c-smile wrote: post #146

Earlier quoted context omitted.

> this doesn't seem to be accurate It is pretty accurate here, case #3 is significantly (almost two times) slower than case #1.

Not on my browser (Safari 16.1). Here case #3 is the fastest, over 7% faster than case #1.

Seems like Safari has quite naive element.append(...list) implementation and/or "destructuring to argv" operation is slow there.

I suspect that element.append(...list) is just a

   for(auto arg : args) 
     element.append(arg);
so no transaction there at all - slower version of case #3.

On Windows I am testing it in Edge, Chrome and FF. Edge and Chrome show close numbers (#1 fastest). FF shows #3 is faster - same problem as Safari I think.

Re: Virtual DOM is pure overhead (2018)

#200

Post by ttfkam »

c-smile wrote: post #186
ttfkam wrote: post #178

Earlier quoted context omitted.

Let's compare lines of code, because more lines invariably leads to more bugs. Contents of Beers.svelte: export let bottles = 99; {#if bottles > 0} --bottles}> {bottles} bottles of beer on the wall {:else} No more bottles of beer on the wall {/if} Then to use it: import Beers from './Beers.svelte'; No knowledge of Reactor's existence needed let alone the library's "signal" function. No functions needed at all. No bes…

In Sciter you do not need any preprocessor at all, not even JS in your HTML: div.beer { prototype: Beer url(/components/beer.js); } After that div.beer element will be instanceof Beer. In this case class Beer used as a [Web-alike] component.

1. I think you accidentally a tag

2. Your example would have atrocious load time implications for any non-trivial web page. Iterating the DOM through querySelectorAll to replace items at load time? Yikes!

So apparently with Sciter you can either have minimal code or acceptable performance. Got it. Would rather have my cake and eat it too.

Post reply on HN