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

321–330 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#321

Post by acemarke »

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.

FYI, we recommend that most folks should not write promise management, data fetching, or loading status tracking code directly

If you're using just React, use React Query or something like `react-async`.

If you're using Redux, use the "RTK Query" data fetching and caching API in our official Redux Toolkit package:

- https://redux.js.org/usage/side-effects-approaches

Re: Virtual DOM is pure overhead (2018)

#322

Post by panopticon »

The5thElephant wrote: post #288
apatheticonion wrote: post #283

Earlier quoted context omitted.

> templating makes it far easier to understand I think this is the key take away. React is great and offers a lot of tunability in terms of performance but to me it often feels a lot like writing low level code. When I use something like Vue, Petite-Vue, Svelte, Angular (flawed but underrated) - it feels like using something high level (like an ORM) that is designed to take something difficult and map it to something…

I love having HTML/CSS/JS in one place, it means things never get detached from their immediately relevant context. Also thanks to nice extensions for VSCode (which wouldn't work across separate files) I can option-click any class name and get a mini-panel to edit the styles inline without hunting for the style section or a separate style file. I can also see when styles I have added are not being used in that compon…

> they can't because they are all stuck using React

You can get most—if not all—of that behavior in React with JSS and TypeScript. All of your component code (HTML, CSS, and JS) can be colocated in one file, you can jump to the CSS class definition, TS ensures the class name is legit, etc.

Svelte and Vue provide a more batteries-included experience, but React is very flexible.

Re: Virtual DOM is pure overhead (2018)

#323

Post by The5thElephant »

panopticon wrote: post #322
The5thElephant wrote: post #288

Earlier quoted context omitted.

I love having HTML/CSS/JS in one place, it means things never get detached from their immediately relevant context. Also thanks to nice extensions for VSCode (which wouldn't work across separate files) I can option-click any class name and get a mini-panel to edit the styles inline without hunting for the style section or a separate style file. I can also see when styles I have added are not being used in that compon…

> they can't because they are all stuck using React You can get most—if not all—of that behavior in React with JSS and TypeScript. All of your component code (HTML, CSS, and JS) can be colocated in one file, you can jump to the CSS class definition, TS ensures the class name is legit, etc. Svelte and Vue provide a more batteries-included experience, but React is very flexible.

But it's a far worse developer experience, particularly for designers and HTML/CSS/A11y folks who aren't as JS focused. It's not like you really are getting that much benefit from writing CSS in JS besides familiarity with a language you prefer. It's harder to read and parse at a glance (even for the devs who wrote it, I see this in practice all the time when pairing and attempting to fix layout and style issues with my devs), harder to inspect from the browser, encourages practices that undermine many of the core benefits of CSS, etc.

My whole point is that we should not be finding worse workarounds just so we can stick with the familiarity of React. Even outside of HTML and styling it is easier to do stuff in other frameworks than it is in React. React is not providing some magical level of power other frameworks don't provide.

I don't hate React, I'm just sick of it being the defacto standard. We are creating a React monoculture in web dev and it absolutely has secondary impacts on how we write markup, styles, and how approachable and accessible our codebases are. So many major decisions being made just so a team can stick with React.

Why not pick a different framework and get better performance, easier to write JS logic, easier to write and read markup and styles, and a code that designers and others can engage with easily without having to be JS fluent?

Re: Virtual DOM is pure overhead (2018)

#324

Post by intrasight »

MrJohz wrote: post #228
intrasight wrote: post #196

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. usel…

I don't think that's a great explanation of the concept of VDOM. For example, SolidJS looks a lot like the example given, and it also arguably returns an object that represents how the page looks, but it didn't use a virtual DOM under the hood. I think it's easier to think of virtual DOM implementations as doing two things: (1) describing the desired state of the DOM in some sort of structure, and then (2) diffing th…

For some reason I thought the virtual DOM was a native feature of the browser, in the form of the DocumentFragment class, and had nothing to do with diffing. But you are saying that it's just a concept, and is implemented by frameworks such as React, and involves the two steps of generating and diffing.

I'll still ask why. Is it just something that React needs to do?

Re: Virtual DOM is pure overhead (2018)

#325

Post by MrJohz »

The5thElephant wrote: post #309
MrJohz wrote: post #295

Earlier quoted context omitted.

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…

CSS modules work quite differently from scoped CSS. In scoped CSS, every element in a component is given an extra data attribute unique to that component. Then when you write your CSS, each declaration is given an implicit extra selector that scopes it so that it only affects elements in that component. As an example, the selector `.header > nav:hover` would be implicitly transformed into `.header > nav[data-535728]:hover`, and every element in that component would be generated with the `data-535728` attribute.

In contrast, CSS modules is far simpler: every class used in a CSS file is replaced with a random identifier (normally something deterministic), and any JS file that imports that CSS file will receive an object mapping the original class names to the new identifiers. Essentially, the only change from normal CSS is that class names are no longer global - everything else remains the same.

In my experience, I tend to run into far fewer surprising situations with CSS modules because it really is just CSS. If I target a class and all of its children, then I get what I expect, regardless of how the components are laid out in practice. In contrast, with scoped CSS, I tend to find that the scoping rules get in the way - my CSS is now tied to my components, as opposed to being able to be used and reused in multiple places. It's not a big issue (and I've used it plenty, and most of the time it's fine), but I always feel like it's an extra layer on top of CSS that I don't actually need.

Whereas, ironically, CSS-in-JS tends to feel closer to true CSS (and CSS modules) because there aren't any surprises. It's just CSS declarations (albeit often written in an unusual syntax), except that class names are locally scoped. In that sense, I can use my existing CSS knowledge and craft selectors however I want.

I understand the value of SFCs for people who don't feel as comfortable with the scripting side of things, but I do wonder if that's a bit of a false economy. At the end of the day, Vue is a tool for writing Javascript components. If you've got a team that doesn't want to write Javascript, then something like Alpine.js is probably a much better option - minimise the JS side of things completely and just concentrate on the HTML and CSS sides. But component-based web development is going to involve combining Javascript, CSS, and the DOM, and that involves understanding all three technologies, and not just specialising in one of them.

E: as a complete aside, I love the user name! I've just finished rereading the Watch books and I'm deciding which thread to go down next.

Re: Virtual DOM is pure overhead (2018)

#326

Post by szastamasta »

kamikaz1k wrote: post #202
szastamasta wrote: post #141

Earlier quoted context omitted.

From what I know React does not register event handlers on individual nodes, but rather on root component. Then it uses virtual events from it’s pool in your callbacks.

Wow, I didn't know this! All that Synethetic stuff makes sense in retrospect... I tried a quick google and didn't find any articles discussing it directly. Do you have any links to offer? Thanks in advance!

Cannot find a page about it in the docs, but here they discuss how it was changed from document root to React root in React 17: https://reactjs.org/blog/2020/08/10/react-v17-rc.html#change...

Re: Virtual DOM is pure overhead (2018)

#327

Post by MrJohz »

intrasight wrote: post #324
MrJohz wrote: post #228

Earlier quoted context omitted.

I don't think that's a great explanation of the concept of VDOM. For example, SolidJS looks a lot like the example given, and it also arguably returns an object that represents how the page looks, but it didn't use a virtual DOM under the hood. I think it's easier to think of virtual DOM implementations as doing two things: (1) describing the desired state of the DOM in some sort of structure, and then (2) diffing th…

For some reason I thought the virtual DOM was a native feature of the browser, in the form of the DocumentFragment class, and had nothing to do with diffing. But you are saying that it's just a concept, and is implemented by frameworks such as React, and involves the two steps of generating and diffing. I'll still ask why. Is it just something that React needs to do?

Using some sort of VDOM is still pretty standard in most frameworks, it's definitely not just React doing this. The motivation is generally an attempt to model an application as a function `(state) => DOM`. This is probably similar to the `renderMyModel` function in your example: take state in, and return what the document should look like given this state.

The problem with this is that if you rerendering the entire DOM every time the user interacts with the page at all (and therefore changes the state) then you will run into issues. The main one of these is that the DOM itself has state, such as event listeners, or the contents of input fields. We don't want to throw this state away as well, instead we want to sing m synchronise it with the state that _should_ be. I mean, in your example, you wouldn't run the `replaceElement` function every time the user presses a key or moves their mouse, right?

VDOM is basically the solution. It can run every time a mouse is moved, because instead of just replacing everything, it replaces only the things that have changed. Assuming the input hasn't been swapped out for a different element, then it can stay. It might gain or lose a class, or the value attribute might get updated, but the element itself stays were it is.

Re: Virtual DOM is pure overhead (2018)

#328

Post by The5thElephant »

MrJohz wrote: post #325
The5thElephant wrote: post #309

Earlier quoted context omitted.

> 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…

CSS modules work quite differently from scoped CSS. In scoped CSS, every element in a component is given an extra data attribute unique to that component. Then when you write your CSS, each declaration is given an implicit extra selector that scopes it so that it only affects elements in that component. As an example, the selector `.header > nav:hover` would be implicitly transformed into `.header > nav[data-535728]:…

The difference between Vue/Svelte style scoped CSS and CSS modules isn't really that different in practice. When working with a larger team it is harder to enforce being careful with class name uniqueness, so the auto-scoping is beneficial but in a personal project I honestly don't mind turning off scoping entirely and just being strict about BEM class names. I LIKE the cascade part of CSS. So when working with a team Vue/Svelte-style scoping gives me the best of both worlds, global classes when I need them, scoped classes when I want to keep it component-specific.

The issue isn't that the companies/people I work with don't want to write JS, it's that they ONLY want to write JS. They don't hire the people that know HTML/CSS and accessibility better than their React devs so they don't even know what they are missing, they just think it is normal for implementation to be clunky, not match designs, and have poor performance. This is pretty much the standard at most early stage SAAS startups except the ones started by people who actually care about this stuff and understand it technically. At every company I have worked with (usually under 100 people) I as product designer have written more CSS than any front-end developer.

The point is to make codebases that are accessible to people who come from all sorts of backgrounds, not just JS developers. I have worked with designers who knew HTML/CSS well and they were so happy to be able to write simple template logic and plain old class names in Vue without having to figure out the correct JS syntax for modifying an array of style objects or writing a conditional and not leaving an accidental 0. Passing classes and props into child components and not having to explicitly tell it what to do with each one makes building JS components a LOT easier for people who aren't JS experts.

Discworld is a true joy, I miss Terry Pratchett! I read the books in publishing order, but I have had the urge to go back and read them as sets of related themes.

Re: Virtual DOM is pure overhead (2018)

#329

Post by [deleted] »

peterhunt wrote: post #287
ricardobeat wrote: post #279

Earlier quoted context omitted.

What makes the svelte template language less expressive than JSX in your view? Props and expressions will look similar in both (minus the useXX ceremonies), and the rest is all loops and if conditions. Writing simple inline conditions in JSX is painful, so it already starts with a negative score.

The template language doesn't compete with JSX. It competes with JSX + JavaScript, which is far more expressive.

[deleted]

Re: Virtual DOM is pure overhead (2018)

#330

Post by shepherdjerred »

Alifatisk wrote: post #297
shepherdjerred wrote: post #286

Earlier quoted context omitted.

React (or other web frameworks) have a unique advantage. They run everywhere. Any device with a modern web browser can run a React application. Sure, Electron and the alternatives are resource hungry, but they allow developers to create true cross-platform applications. Sure, there are other ways to create a cross-platform app, but none of those approaches allow you to tap into the massive number of web developers th…

Why did you say ”true cross-platform” and not just ”cross-platform”? I would define Flutter as ”true cross-platform”. Update: React + ReactNative too.

I'm not super familiar with the space nowadays, but a few years ago cross-platform apps were full of compromises. Mobile apps wouldn't look native (tiny things like a being a pixel or two off) or they wouldn't support Linux. Maybe it's better with Flutter -- I've heard good things about it.

Additionally, Electron apps not only work as a standalone app, but you can often access a near identical version of the app in your browser. For example, you can either download Discord or Slack as a desktop app, or open them in your browser.

I'm not saying this comes for free; these apps are very heavy, and Flutter/React Native would probably produce more efficient apps.

Post reply on HN