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

231–240 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#231

Post by mumblemumble »

notJim wrote: post #217
darepublic wrote: post #153

Earlier quoted context omitted.

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

This feels like a tangential point about JS dev culture or engineering skill level rather than a point about the technical merits of React vs Svelte or whatever. > 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.…

For my part, I actually wonder if there's also a certain gatekeeping element that also fuels the popularity of frameworks like React?

Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it used to be fairly common to have front-end people like that who were stronger on design than programming.

Is this a form of unwitting rent-seeking behavior? Has the profession created an artificial supply-and-demand problem by convincing the managers of the world that they need expensive single-page applications built by Software Engineers™, when a (less expensive, I'm assuming) Wordpress site developed by a web designer would have sufficed?

For context on where I'm coming from: I've mostly been a back-end developer for a couple decades. I've known HTML and CSS since the '90s, of course, I'm just now starting to learn Web development in earnest, mostly as a hobby. I'm finding React's learning curve to be just incredibly steep. For the stuff I've been doing, I've had a much easier time getting acceptable (to me) results out of a more oldschool-flavored tech stack, with server-side templating and a moderate sprinkle of vanilla JS. No, it's not fancy, but I'm not looking to flex; I'm just looking to whack together a website that looks nice.

Re: Virtual DOM is pure overhead (2018)

#232

Post by nobleach »

lhorie wrote: post #214
kgr wrote: post #202

When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listener…

innerHTML has been slower than the DOM API for a few years. React had a big refactor at one point to rip out innerHTML logic precisely due to this. To make matters more interesting, the order of DOM API calls also mattered. In IE, building a DOM tree bottom up was significantly slower than building it top down (meaning, no large document fragments for you!). There are also a ton of other quirks: `.textContent = ''` b…

Not to travel too far off the main topic, but I use this exact fact to demonstrate to new developers why I prefer a developer that looks things up instead of relying on what "everyone knows". When Jeremy Keith's DOM Scripting book was written many years ago, it claimed that DOM methods were much slower than innerHtml. And that was true. If we all just took that as gospel, we'd be WAY off base.

So I'll take the dev that looks things up, as there's much more possibility they're operating on more up to date information.

Consequently, this is why I also tell people to stop repeating "this is a best practice" a year or so after something is discovered. It's a "common practice". You don't have enough info to know if it's truly "best".

Re: Virtual DOM is pure overhead (2018)

#233

Post by imbnwa »

ehnto wrote: post #138
the__alchemist wrote: post #110

When I learned frontend web work and React years ago, I fell for the same "VDOM is fast!" hype, and assumed there was non-JS magic under the hood. I eventually built a VDOM-based frontend WASM framework in Rust (Seed). I now built frontends in HTML and CS, with no frameworks, and minimal, targeted JS code to manipulate the DOM directly; it's liberating, and much faster than both React and WASM/Rust.

It's crazy how quickly frontend UI frameworks became the standard approach. They're not necessary in so many instances where they are used. I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget? Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.

Yes, there's a lacking sense of measure in frontend and I work in a shop full of people that talk about what framework to use for a few buttons, a search form, and a result list. CSS is good enough that you can implement a lot of your UI state machine with classes as switches and scoped CSS variables available with `calc()` for threading particular derived values

Re: Virtual DOM is pure overhead (2018)

#234

Post by arduinomancer »

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…

My impression of reading [1] is that its just moving the "spooky action at a distance" to a different place.

If I see this:

Click Me

My immediate question is

* What actually executes when I click the button?

* How can I debug the code that sends the GET request?

* How can I customize the GET request and add stuff like custom headers?

In the jQuery example all of that is obvious on first glance.

I feel like complexity can't be destroyed, only moved around.

Re: Virtual DOM is pure overhead (2018)

#235

Post by throwaway894345 »

SquareWheel wrote: post #227
throwaway894345 wrote: post #221

Earlier quoted context omitted.

I fully believe that JS is better than VBScript, but it's also possible that many other factors contributed to JS's triumph over VBScript. In whichever case, this is pretty weak evidence for the claim "JS won its popularity relative to other languages by merit" (presumably you weren't intending it to be strong evidence).

I was only commenting on the claim that JavaScript was the "sole language available for the web platform".

Fair enough, thanks for clarifying. :)

Re: Virtual DOM is pure overhead (2018)

#236

Post by WickyNilliams »

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.

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.

Re: Virtual DOM is pure overhead (2018)

#237

Post by nobleach »

mumblemumble wrote: post #231
notJim wrote: post #217

Earlier quoted context omitted.

This feels like a tangential point about JS dev culture or engineering skill level rather than a point about the technical merits of React vs Svelte or whatever. > 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.…

For my part, I actually wonder if there's also a certain gatekeeping element that also fuels the popularity of frameworks like React? Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it use…

I'm not sure I'd go down that road. I totally agree that for websites, Wordpress, SquareSpace, Gatsby, Hugo, and a host of other static sites work just fine. Where I find it hard to make the stretch is, these are not the type of sites your average JavaScript app developer wants to work on. They'd probably be just fine NOT touching that. I know the past few places I've worked, I've never touched the slick "brochure/marketing sites". I think that type of thing is better left to someone who has really honed their HTML/CSS skills. I don't see a whole lot of reason why anyone would want to turn that type of site into an SPA.

I'm not saying developers don't have an attitude problem. We often do. I just think you might be assuming malice where there might be none.

Re: Virtual DOM is pure overhead (2018)

#238

Post by mumblemumble »

nobleach wrote: post #237
mumblemumble wrote: post #231

Earlier quoted context omitted.

For my part, I actually wonder if there's also a certain gatekeeping element that also fuels the popularity of frameworks like React? Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it use…

I'm not sure I'd go down that road. I totally agree that for websites, Wordpress, SquareSpace, Gatsby, Hugo, and a host of other static sites work just fine. Where I find it hard to make the stretch is, these are not the type of sites your average JavaScript app developer wants to work on. They'd probably be just fine NOT touching that. I know the past few places I've worked, I've never touched the slick "brochure/ma…

Definitely not trying to assume malice. I meant it when I said, "unwitting".

Re: Virtual DOM is pure overhead (2018)

#239

Post by recursive »

WickyNilliams wrote: post #236
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.

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 have no problem with it. However, my first inclinations seem to be more likely to be those that React has problems with. I'm having a difficult time "thinking in React".

Re: Virtual DOM is pure overhead (2018)

#240

Post by recursive »

dragonwriter wrote: post #215
recursive wrote: post #206

Earlier quoted context omitted.

JSX is exactly a customized template DSL. It's not a particularly difficult one, but that's exactly what it is.

> JSX is exactly a customized template DSL. Yes, but its a template DSL for JavaScript (and TSX is one for TypeScript ), not a template DSL for HTML . Building JSX outputs JS, not HTML.

Yes, that's true. I don't see why it's significant though. There doesn't seem to be any inherent reason why an HTML-hosted DSL is more difficult to learn or use.
Post reply on HN