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

301–310 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#301

Post by vbezhenar »

scotty79 wrote: post #300
vbezhenar wrote: post #292

Earlier quoted context omitted.

It's supposed to run provided promise and return its status. If deps changed or component is unmounted while promise is pending, it should inform currently running promise using AbortSignal. And it should handle edge cases (e.g. promise is changed, second promise is started but first promise ignored abort signal and resolved to a value. This value should be ignored). Basically it should remove any boilerplate from us…

Thanks. But what do you use it for? What promises do you want your components to be involved with and in what way?

For example HTTP request. Anything, actually. Some rough code:

    function Item({id}) {
      const r = usePromise(async (signal) => {
          const resp = await fetch(`/item/${id}`, {signal});
          return await resp.json();
      }, [id]);
      if (r.status == "pending") {
        return Loading;
      }
      if (r.status == "rejected") {
        return Error: {r.reason};
      }
      return {r.value};
    }
It's really like useEffect but provides better support for cancellation and properly tracks promise. Rewriting this snippet with useEffect correctly would require quite a lot of code (although rewriting this snippet with useEffect incorrectly is possible with not a lot of code, but you don't want to write incorrect code). Which has to be repeated everywhere.

Again, this task is better solved by react-query or its alternatives. What I'm writing is not strictly web-site, but rather a web-interface on embedded device and web-server is not remote web-server but thing that works on the same device, so for now I decided not to use those libraries which made for slightly different use-cases.

Re: Virtual DOM is pure overhead (2018)

#302

Post by HorizonXP »

peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

As a complete aside, happy birthday bud!

Re: Virtual DOM is pure overhead (2018)

#303

Post by JLuterek »

pweissbrod wrote: post #91

In 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.

This is very true. It's also why we have svelte-kit, remix, astrojs, and other frameworks that take a transitional app approach. They are server-rendered where it makes sense and client-rendered where necessary. Before developers had to choose between a server-rendered website and full on single-page application, now there are great options that blend the two depending on needs.

Re: Virtual DOM is pure overhead (2018)

#304

Post by scotty79 »

vbezhenar wrote: post #301
scotty79 wrote: post #300

Earlier quoted context omitted.

Thanks. But what do you use it for? What promises do you want your components to be involved with and in what way?

For example HTTP request. Anything, actually. Some rough code: function Item({id}) { const r = usePromise(async (signal) => { const resp = await fetch(`/item/${id}`, {signal}); return await resp.json(); }, [id]); if (r.status == "pending") { return Loading ; } if (r.status == "rejected") { return Error: {r.reason} ; } return {r.value} ; } It's really like useEffect but provides better support for cancellation and pro…

I think I'd go about it using redux-thunk because I feel like render function is not a great place for complex async state changes and chcecking internal status of a promise is a bit low level, but you've built a nice, easy to use thing. If you published it some people might find it to be exactly what they need. Plus they might help you debug some corner cases.

Re: Virtual DOM is pure overhead (2018)

#305

Post by npteljes »

fleddr wrote: post #217

Imagine being someone in the semiconductor industry reading this. You're at the absolute pinnacle of high-tech and are approaching the limits of material reality to realize a 20% faster CPU. It's a true super human accomplishment. Software developers: well yes, 99% of the cycles I use are completely needless, but it's still plenty fast enough! Which we justify with the idea that a framework like React is abstract, he…

The state of things is ridiculous. But I think that this is how people operate, in general: they just fill the available space, use all the available resources.

Re: Virtual DOM is pure overhead (2018)

#306

Post by npteljes »

commandlinefan wrote: post #79
lordgroff wrote: post #31

Earlier quoted context omitted.

100% There's a vanishingly small number of applications where it's really going to make a difference. Use what your work uses, or if personal project what you like. The more I use React and co. the more I feel like it's all the same thing.

> There's a vanishingly small number of applications where it's really going to make a difference Developers (and especially deadline-conscious managers) keep saying this, but their web sites keep slowing down my computer to a crawl. As a consumer, I really wish that development teams paid at least some attention to performance.

The truth is, performance doesn't bring in the dollars, features do, and marketing, and sales. The incentives are just not there, and these issues what we're having, show that.

Re: Virtual DOM is pure overhead (2018)

#307

Post by vbezhenar »

scotty79 wrote: post #304
vbezhenar wrote: post #301

Earlier quoted context omitted.

For example HTTP request. Anything, actually. Some rough code: function Item({id}) { const r = usePromise(async (signal) => { const resp = await fetch(`/item/${id}`, {signal}); return await resp.json(); }, [id]); if (r.status == "pending") { return Loading ; } if (r.status == "rejected") { return Error: {r.reason} ; } return {r.value} ; } It's really like useEffect but provides better support for cancellation and pro…

I think I'd go about it using redux-thunk because I feel like render function is not a great place for complex async state changes and chcecking internal status of a promise is a bit low level, but you've built a nice, easy to use thing. If you published it some people might find it to be exactly what they need. Plus they might help you debug some corner cases.

Thanks, I'll think about it.

Re: Virtual DOM is pure overhead (2018)

#308

Post by The5thElephant »

nwienert wrote: post #291
The5thElephant wrote: post #274

Earlier quoted context omitted.

How can you say there is no difference? What do you think Vue and Svelte SFCs are? Where does React have built-in component style scoping? Where does React have automatic passing of classes and properties to components? Can I write SCSS in a React JS file and have it just work? Nope. The platform is more than just JS, and React has plenty of stuff going on that is "magic" enough to be no different for me than the abs…

No one believes the gospel of syntax, simplicity, and inline styles more than me [0]. I made that before Svelte was a thing and the Vue creator actually asked if he could borrow multiple ideas from that as he was making it. But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the min…

> React has some of the most gorgeous style solutions around

Can you give an example?

> But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the minimum importing CSS.

Vast majority use Styled Components or another flavor of CSS-in-JS that continues the problem of making it harder for HTML/CSS experts to contribute to a JS-only codebase. Tamagui is exactly the issue I'm talking about. It's great for JS/React first devs, but doesn't actually do that much that a good HTML/CSS developer couldn't do without all this added tooling and with much easier to read clean code for people unfamiliar with the framework.

> I think if you looked on average total CSS knowledge is higher than ever,

Definitely not my experience. There are some great CSS devs out there, but it is always secondary to the skillsets that are actually highly paid (JS, React) and they mostly end up in large companies by happenstance of those companies hiring more people. Smaller tech companies make the consistent mistake of not hiring front-of-the-front-end devs and end up with poor UI and experiences because of it.

Re: Virtual DOM is pure overhead (2018)

#309

Post by The5thElephant »

MrJohz wrote: post #295
The5thElephant wrote: post #273

Earlier quoted context omitted.

There is no built-in support for writing your styles alongside your JSX the way Vue and Svelte have. Both provide automatic component style scoping, escape hatches, deep selectors, etc. Vue passes classes given to a component instance into the top level element of that component. All of this makes styling with plain CSS and SCSS 1000x easier than it is in React. Then there is the template side of things where it is m…

There is definitely no built-in support for those things, but I don't think it's fair to call them second class citizens in the React world. AngularJS bundled an entire http client back in the day, but that doesn't make it more "first class" in the AngularJS ecosystem than in Vue or React! My experience with Vue has been pretty mixed here, though. It's nice having everything in one file, sure, but it's also a pain ha…

> For me, the ideal abstraction here is CSS modules, where the class names are scoped, but the actual declarations behave like normal CSS.

How is this different from Vue or Svelte scoped style blocks? Those are just normal CSS with scoped class names.

> Different tools work for different people and in different contexts. You talk about the awfulness of CSS-in-JS, but last time I used it, I found it gave a really good balance between conventional CSS (albeit not in CSS format), while still being collocated with JS components.

People think too much about how these things work for themselves and their own skillsets, not whether it prevents other great people from contributing as easily. I know HTML/CSS developers who are way better than the average React dev at building great clean and accessible UIs, but they aren't as strong in JS and end up struggling with unnecessarily complicated JS solutions to things that don't need them.

Besides the colocation what other benefits did CSS-in-JS provide you besides the familiarity of JS logic? This feels like again a solution to solve a limitation of React, not actually the best solution.

Re: Virtual DOM is pure overhead (2018)

#310

Post by horsawlarway »

ttfkam wrote: post #255
horsawlarway wrote: post #218

Earlier quoted context omitted.

So what part of this statement do you disagree with? > "it's building a vdom engine specific to your template" Because that's... exactly what it's doing. It's doing it at compile time, and so yes - the amount of mutation in the output is small, which is not surprising at all because most templates are fairly static. We can quibble over exactly what a VDOM is, but I don't really know that tracking only a subset of the…

I'm not sure we can quibble over the definition of a vDOM. There is the DOM as found in browsers and then there's a layer on top of that, proxying access to the DOM, which we call a vDOM. Svelte does not have this construct. All actions are performed on the DOM without an intermediary proxy object. Tracking 100% matters, because you must iterate through the vDOM to determine the diffs that must be applied to the unde…

Well now we can quibble! :D

Svelte IS storing a representation of the expected layout of the DOM (at least the limited set it cares about). That's precisely what "reactivity" is. It's aggregating the values we've stated are important to our template (either by hand ($) or automatically (=)) and monitoring changes to those values to trigger a set of updates.

The diffing happens right there. It's also why you end up with some unusual restraints on how you do assignments - if you're not careful the autodetection of "this bit was important and needs to be diffed and trigger code on changes" fails (they talk about this quite clearly, and very early: https://svelte.dev/tutorial/updating-arrays-and-objects)

I also find it bit disingenuous to call out things like "shouldComponentUpdate". That's very, very nearly the same as reactive declarations. You're having to indicate to svelte that "yes - this declaration should update". Again - it's more precise than react allows you to be, but conceptually I find it just a slightly different take on the same function.

It's also why you can easily get into the same sort of cyclical dependencies that you can with react (although I think the messaging from the svelte compiler here is pretty on point, compared to react)

Now - I generally find it a bit easier to suss out why the loop is happening in svelte than react (where it's not always easy or intuitive to understand that a hidden reference value may have been changed and is triggering quite a bit of downstream updates) but it's essentially the same problem space, just inverted:

React makes you mark places you don't want to care about changes (useMemo, useCallback)

Svelte makes you mark places you do want to care about changes ($, =)

You're basically arguing that opt-in is better than opt-out, and I think that you may have a fairly compelling argument, but lets not paper over the fact that both frameworks are tackling the problem is similar ways, and both end up with their own DSLs to indicate intent with regards to changing values, and when to run code.

Post reply on HN