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

261–270 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#261

Post by miracle2k »

eagsalazar2 wrote: post #196
macspoofing wrote: post #182

Earlier quoted context omitted.

>This is complete and utter nonsense. Were you programming seriously before React? Indeed I was. >There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. I'm not saying React isn't a good framework, it is perfectly nice, though I th…

I'm not sure I'd agree that when React took over, Angular was a perfectly fine framework. I mean, what happened with React was actually very unusual and remains very unusual. It took over. There is this popular and snarky notion that js devs are constantly chasing every shiny thing but that is exactly the opposite of what has happened over the last several years with React. Instead I'd argue that js devs were nomads…

When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected. Rather than going viral as a kind of fashionable thing, I feel that it really had to earn its position.

Re: Virtual DOM is pure overhead (2018)

#262

Post by rendall »

cuddlecake wrote: post #245
rendall wrote: post #230

Earlier quoted context omitted.

I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?

You're trying to reframe my argument in a bad way. I'm talking about people deciding to use a certain technology with tradeoffs. You're talking about people going against quality standards of a development team. And that's where I end the conversation, you bore me.

Not trying to reframe anything. Just trying to understand the bounds of your ease with team members making these decisions.

I haven't been hostile to you or anyone who disagrees with me, by the way. Just trying to understand if and where I'm incorrect.

Furthermore, I said what I said in reaction to someone disliking the idea of Svelte being able to use any javascript library at all because of the chaos and bad practice that represents.

> You're talking about people going against quality standards of a development team.

That's what I've been taking about this whole time

Re: Virtual DOM is pure overhead (2018)

#263

Post by runawaybottle »

rasz wrote: post #260
aidenn0 wrote: post #146

Earlier quoted context omitted.

I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone. Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on…

Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736

I just read that and chuckled. Someone must have been under pressure and just said fuck it, this works.

Re: Virtual DOM is pure overhead (2018)

#264

Post by vlasev »

acidbaseextract wrote: post #257
recursive wrote: post #199

Earlier quoted context omitted.

Here's a minimal-ish repro of the issue I ran in to. It's totally possible that I'm doing something "obviously" wrong. However, I've spent more than a couple of hours reading through docs trying to figure out what it is. I'm not seeing it. https://codepen.io/recursive/pen/XWMLWBZ If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.

Been working with React since 2014. That is the damndest thing ever, especially that it doesn't even throw a warning. It seems like an identity confusion issue where the VDOM diff is ambiguous, and React resolves it in the "wrong" way. Adding keys to each `LabeledInput` resolves the issue, but I'm surprised that the runtime doesn't complain when you create the inputs without keys. I wonder if this is why the checkbox…

If you render the inputs via a list, like

    const inputs = isBob ? [name, confirmation, request] : [name, request]
then it complains that there's no key prop and the issue persists. This shows it's because of confused identity. In the example, it doesn't complain because it doesn't understand that {name}{confirmation}{request} is essentially an unrolled loop.

Re: Virtual DOM is pure overhead (2018)

#265

Post by vlasev »

recursive wrote: post #199
madeofpalk wrote: post #172

Earlier quoted context omitted.

How did this happen? I've never seen this in practice if you weren't doing something "obviously" wrong.

Here's a minimal-ish repro of the issue I ran in to. It's totally possible that I'm doing something "obviously" wrong. However, I've spent more than a couple of hours reading through docs trying to figure out what it is. I'm not seeing it. https://codepen.io/recursive/pen/XWMLWBZ If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.

    {name}{confirmation}{request}
is basically a hidden render loop. If you had something like

    const inputs = [name, confirmation, request]
and rendered that via inputs.map() (or just {inputs}), it would have complained about the missing key prop. React can't seem identify which state belongs to which item in the "iteration".

Using a conditional render like

   {nameInput}
   {isBob ? confirmationInput : null}
   {requestInput}
seems to avoid the issue as well, without using a key prop. So yeah, beware of hidden loops.

Re: Virtual DOM is pure overhead (2018)

#266

Post by kevinak »

Panther34543 wrote: post #168

I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework. I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing,…

We've been building Budibase without SK and it's great: https://github.com/Budibase/budibase

Re: Virtual DOM is pure overhead (2018)

#267

Post by panta »

Panther34543 wrote: post #168

I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework. I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing,…

I agree. SvelteKit should not be advertised as the standard way to use svelte imho. Fortunately it’s not necessary to use svelte. I’ve some quite complex apps built using svelte, all without SvelteKit/sapper (I am of the “explicit is better than implicit” school of thought).

Re: Virtual DOM is pure overhead (2018)

#268

Post by arcturus17 »

recursive wrote: post #256
arcturus17 wrote: post #253

Earlier quoted context omitted.

I’ve been coding in React for a few years and I’ve never seen anything like this. Bookmarking this so I can take a look tomorrow and also in case someone provides an answer.

I seem to have a talent for coming up with things that shouldn't be, can't be, or are difficult to express in react. Note that I'm not particularly interested in other ways of writing this that would work. I now know several. I'm more interested in simple general rules that one could follow to stay out of trouble.

> I'm more interested in simple general rules that one could follow to stay out of trouble.

I don't know what to tell you, just don't do this?

I've been working professionally for years in React and have never encountered this particular issue. Once I've gotten to to it this morning with fresh eyes it's taken me like 5min to understand - React sees this as a list of the same element, which requires keys - this on the other hand is extremely common and well documented, so even a junior could intuit it.

This is a contrived example and as a moderately experienced developer you would almost certainly reach for the idiom, which would be rendering the input as a list with a map, in which case you would see clearly what's going on, get a warning, and a clear mapping to the official docs [1]

As far as footguns go, I think this is a weak and contrived example. I get why one would not want to work with React - maybe they don't like JSX, or the lack of baked-in state management, that there are a million ways to do the same thing, the general philosophy of the framework, etc.

But I've worked with many other technologies on the front and the back end and not only have I seen infinitely worse than this, I can't think of a technology where if you try really hard to break it, you won't find ways to do so.

[1] https://reactjs.org/docs/lists-and-keys.html

Re: Virtual DOM is pure overhead (2018)

#269

Post by arcturus17 »

vlasev wrote: post #265
recursive wrote: post #199

Earlier quoted context omitted.

Here's a minimal-ish repro of the issue I ran in to. It's totally possible that I'm doing something "obviously" wrong. However, I've spent more than a couple of hours reading through docs trying to figure out what it is. I'm not seeing it. https://codepen.io/recursive/pen/XWMLWBZ If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.

{name}{confirmation}{request} is basically a hidden render loop. If you had something like const inputs = [name, confirmation, request] and rendered that via inputs.map() (or just {inputs}), it would have complained about the missing key prop. React can't seem identify which state belongs to which item in the "iteration". Using a conditional render like {nameInput} {isBob ? confirmationInput : null} {requestInput} se…

Yea, I was startled by the issue at first, but once I checked it in more detail it took me like 5min to figure out what was going on.

I'll grant the particular example or edge case is not available in the public docs, but it's extremely easy to intuit what is happening and relate it to the requirement of list components needing keys.

Like I replied to OP, you would be in all likelihood using arrays anyway, instead of this contrived pattern.

Re: Virtual DOM is pure overhead (2018)

#270

Post by nextaccountic »

the__alchemist wrote: post #128
nextaccountic wrote: post #8

Okay, but - why does Rust frontend libraries (like Yew and Seed) use vdom instead of doing whatever Svelte does? Actually, is anyone else doing it the Svelte way?

I created Seed. I didn't know any better at the time! I'm no longer a fan of the extra computations VDOM does. Svelte's approach sounds like a clever way to mix declarative code without running extraneous computation.

I understand. Btw, what do you think about MoonZoon? (https://github.com/MoonZoon/MoonZoon) In special, the decision to not use Elm architecture. I see it's created by the current Seed maintainer.

It appears MoonZoon uses https://github.com/Pauan/rust-dominator which, like Sycamore, is also a DOM library that doesn't use vdom.

Post reply on HN