Virtual DOM is pure overhead (2018) • Hacker News Board

Re: Virtual DOM is pure overhead (2018)

#291

Post by stoicjumbotron » Thu, Jul 01, 2021, 4:56 PM UTC

mtm7 wrote: post #163

FractalHQ wrote: post #77

The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible. The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla J…

> The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is. Yes! I've been a full-time React developer for about 5 years, and recently had the chance to try Svelte on a small pet project. I'd written most of the project in React and had a free weekend so I figured what the heck – let's see how it'd look in Svelte. :) Within a day most of the…

Really helpful article. Thinking about diving into Svelte. I'm a huge fan of react-query[0] so I was wondering, is there a good alternative for it in Svelte? Would you recommend svelte-query[1]. Thanks.

[0]: https://react-query.tanstack.com/ [1]: https://github.com/SvelteStack/svelte-query

Re: Virtual DOM is pure overhead (2018)

#292

Post by chrismorgan » Thu, Jul 01, 2021, 9:38 PM UTC

dmitriid wrote: post #289

chrismorgan wrote: post #121

Earlier quoted context omitted.

React’s changes over time have always been broadly compatible, and the same under the hood, just presented and manipulated a different way at the surface. Migrating to anything like Svelte would be a radical and extremely incompatible change on multiple fronts. It’s never, ever going to happen; the closest you’ll get will be another layer on top of React that embeds something like Svelte—such as https://github.com/Ri…

> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics One could argue that React's hooks are the same: they look like JS but change JS semantics. However, your point is still valid.

Nah, React hooks are still JavaScript—they’re library functionality, executed directly as JavaScript.

Re: Virtual DOM is pure overhead (2018)

#293

Post by WickyNilliams » Sat, Jul 03, 2021, 4:12 PM UTC

recursive wrote: post #239

WickyNilliams wrote: post #236

Earlier quoted context omitted.

I assume the issue here is that you are rendering a single nameInput instance in two places. This is definitely not idiomatic react and I can't ever think of seeing this in the wild. Just render two instances. If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.

> If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop. This is the kind of stuff that's difficult for me to wrap my mind around. If I have to remember to "do it this way, but not that way", that's mental overhead. Especially when it's difficult to articulate exactly under what circumstances this problem occurs. Obviously, there are plenty of people that…

I'm not sure this is anything specific to react? Its just a question of internal vs external state. Internal state gets managed by the component itself, external state gets managed by some ancestor in the tree. One component's internal state is another's external state. No different to objects or any other data modelling exercise imo.

As for rendering a single instance in two places, you'd see weird behaviour trying to do the same with raw DOM element instance (well not so weird as not being able to render in two places).