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

151–160 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#151

Post by jakelazaroff »

rendall wrote: post #133
KronisLV wrote: post #105

Earlier quoted context omitted.

> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. This makes me feel conflicted. With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech. With JS libraries it's the wild west once again and befor…

> With React/Angular/Vue you're given a stable base upon which to build new components and logic Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting t…

The purpose of styled components (or CSS modules or what have you) isn't to deal with specificity. It's to deal with collisions between what are essentially global variables.

Re: Virtual DOM is pure overhead (2018)

#152

Post by fokinsean »

recursivedoubts wrote: post #76
avidphantasm wrote: post #63

I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the…

You might want to take a look at the HAT stack: https://htmx.org - server interactions in HTML https://alpinejs.dev - small front end tweaks in your HTML https://tailwindcss.com - styling in your HTML This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. full disclosure: I am the author of htmx [1] - https://htmx.org/e…

HTMX has been on my radar for a little while.

Do you have a starter template with all of these hooked together? Or an example repo?

Re: Virtual DOM is pure overhead (2018)

#153

Post by darepublic »

mumblemumble wrote: post #124
macspoofing wrote: post #89

Earlier quoted context omitted.

>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because…

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read too much damn code where a dev wants to do something straightforward but either because of ignorance or some cultural pressure reaches for a complicated library way to do it, finds that said library doesn't solve the problem well, and then misuses that library or exploits one of its escape hatches in the solving of the problem just to say that their code used the new shiny library. As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

Re: Virtual DOM is pure overhead (2018)

#154

Post by handrous »

engineeringwoke wrote: post #114
vinnymac wrote: post #81

Earlier quoted context omitted.

Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed. At the end of the day, I've never spok…

I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they…

Context and hooks both feel very much like "I'm being paid to work on this but it's basically done... so... guess I'll find something to do" additions. The latter especially.

Re: Virtual DOM is pure overhead (2018)

#155

Post by mvolfik »

strangescript wrote: post #113

Time and again it has been proven that the number one metric for success of a language or framework is developer experience. Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. React has become that for frontend development. React is easier to use than Svelte. I got excited when I first learned of it, but its awkwa…

Where do you find React easier to use than Svelte? I did mostly backend and simple pure-JS frontends before and never picked up react because of how long the tutorial was and how messy the tooling felt. Svelte was a breeze in both of this and I didn't experience larger issues yet, so I'm curious what I'm missing out on?

Re: Virtual DOM is pure overhead (2018)

#156

Post by recursive »

madeofpalk wrote: post #61
recursive wrote: post #17

Earlier quoted context omitted.

For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.

Is it possible to just not think about it? Or is that easier said than done?

Usually it just works. But, even following the "Rules of Hooks" (https://reactjs.org/docs/hooks-rules.html), I managed to write some code where the state that belonged to one component ended up in its adjacent sibling. When that happened, I really wasn't sure what to do other than go on a deep react dive. It's not clear how to debug stuff like that.

I came to realize that I had confused the reconciler. The fix is basically to just use the key= attribute everywhere, not just in arrays.

Re: Virtual DOM is pure overhead (2018)

#157

Post by slumdev »

blacktriangle wrote: post #112
slumdev wrote: post #58

Earlier quoted context omitted.

Writing HTML programmatically or using JSX are both unfortunate React-isms. Not saying that Angular's banana box is ideologically superior, just that all JS frameworks have idiosyncrasies.

Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.

Browsers support HTML and JS (and a few other things not relevant to this point).

Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions.

If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything that currently exists and does what you're describing.

Re: Virtual DOM is pure overhead (2018)

#158

Post by blacktriangle »

slumdev wrote: post #157
blacktriangle wrote: post #112

Earlier quoted context omitted.

Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.

Browsers support HTML and JS (and a few other things not relevant to this point). Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions. If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything th…

Natively no, but writing some JS code that will take an array of objects and turn it into a DocumentFragment is a trivial exercise. And once you're representing your HTML as data, looping and data binding are trivial.

Re: Virtual DOM is pure overhead (2018)

#159

Post by werm82 »

px43 wrote: post #103

Maybe this is a dumb question from a JS muggle, but the thing that kills me about this whole movement to virtual/shadow DOM is that it's made the "ctrl+f" search useless on more and more websites. Is there a nice way to hook the search function to actually look inside elements that haven't been swapped in yet? If so, more people should be using it.

Virtual DOM is completely different from Shadow DOM. Shadow DOM is an isolated DOM of a web component, separate from the global DOM.

Re: Virtual DOM is pure overhead (2018)

#160

Post by ar_lan »

strangescript wrote: post #113

Time and again it has been proven that the number one metric for success of a language or framework is developer experience. Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. React has become that for frontend development. React is easier to use than Svelte. I got excited when I first learned of it, but its awkwa…

> but it was easy to use

I disagree. I've found Javascript to be quite complicated.

However, I agree with your takes that:

1. It's highly accessible - yes, you can learn a single language and get away with only knowing that language for a good chunk of your career nowadays.

2. It does involve fairly immediate feedback (somewhat akin to Python in that regard), because it's interpreted. Given that it's also visual, and a strong majority of people equate the internet to solely what you see in a browser, it's a pretty gratifying experience (even if, later in your career, you avoid it like the plague).

Post reply on HN