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

271–280 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#271

Post by afavour »

harel wrote: post #264
vbezhenar wrote: post #159

Earlier quoted context omitted.

My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I st…

I'm sorry but I don't share your experience. I find React very easy, and short of a period of creating the baseline components and skeleton, everything else flows very fast in terms of development time. By the way, I think react in strict mode does run components twice in dev, so not running in strict mode will prevent that, and you can use a regular Promise in your useEffect.

The fact that “strict mode” means useEffect gets called twice feels like a great example of the ways in which React is not simple.

It’s not quite directly using a promise but I was surprised I can’t use an async function in useEffect. It’s pretty common to perform async operations there, after all.

Re: Virtual DOM is pure overhead (2018)

#273

Post by The5thElephant »

brundolf wrote: post #241
The5thElephant wrote: post #208

Earlier quoted context omitted.

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…

> HTML and CSS not being first class-citizens as they are in other frameworks In what ways are HTML and CSS less than first-class citizens in React? In my React codebases we've always written CSS (or SCSS) stylesheets, and components bottom-out in JSX (which is almost exactly just an HTML template with inserts) In my experience the biggest barrier to (and most legitimate complaint about) React vs other frameworks is…

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 much easier to read a basic conditional or loop in Vue/Svelte for someone who doesn't know JS.

How much have you used Vue or Svelte? It is a significantly better developer experience for building HTML and styling it because it doesn't force everything to be written in JS. In React JS is the only first-class language. There is no built-in support for SFCs, style scoping, etc. Thus the awfulness of CSS-in-JS was born.

Re: Virtual DOM is pure overhead (2018)

#274

Post by The5thElephant »

nwienert wrote: post #234
The5thElephant wrote: post #208

Earlier quoted context omitted.

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…

It's great to argue for Vue/Svelte, but just to clarify - the entire point about HTML/CSS isn't really true, there's no difference in support between React or any other framework there. And disagree on HTML/CSS skill loss being a thing, or being proximately caused by React. And no it doesn't have any div-soup causative effect either. I get that templates are simpler for non-coders. Unfortunately, in all but the simpl…

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 abstraction of a DSL. How is the cost-benefit better for React when I keep seeing developers who actually try other frameworks have their minds blown at how much easier it is to do the same things?

The CSS skill loss is very real, particularly with the number of straight-to-React bootcamps that barely touch on it and the insistence on using CSS-in-JS which makes it way harder for people to explore a production website and learn the fun way. I'm not some HTML/CSS purist, and React was a big step forward for the industry, but now its time is past and we have way better alternatives.

Re: Virtual DOM is pure overhead (2018)

#275

Post by markmark »

peterhunt wrote: post #260
tobr wrote: post #251

Earlier quoted context omitted.

But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler.…

I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed…

I couldn't agree more. Every time I have to do a for-each loop in some templating language instead of just using a normal programming language I want to shoot it into the sun. Templated yaml is my current pain point. Why not build data structures in a normal programming language and then write the result to yaml. It feels like a lesson we learnt after templated XML 20 years ago that we keep forgetting.

Re: Virtual DOM is pure overhead (2018)

#276

Post by harel »

afavour wrote: post #271
harel wrote: post #264

Earlier quoted context omitted.

I'm sorry but I don't share your experience. I find React very easy, and short of a period of creating the baseline components and skeleton, everything else flows very fast in terms of development time. By the way, I think react in strict mode does run components twice in dev, so not running in strict mode will prevent that, and you can use a regular Promise in your useEffect.

The fact that “strict mode” means useEffect gets called twice feels like a great example of the ways in which React is not simple. It’s not quite directly using a promise but I was surprised I can’t use an async function in useEffect. It’s pretty common to perform async operations there, after all.

useEffect IS a great (the best?) place to put async code. I do it all the time. The reason for strict mode rendering twice is to spot strictness related issues. Honestly I never even thought of using it so I've never experienced this.

Re: Virtual DOM is pure overhead (2018)

#277

Post by harel »

afavour wrote: post #36
harel wrote: post #11

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…

Not much in 2023 is fast on an old Android device from 2013, unless it's something from 2013...

Re: Virtual DOM is pure overhead (2018)

#278

Post by ricardobeat »

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…

> performance that is often not noticeable or is easily achieved with React's memoization features. React was always about enabling front-end engineers to take advantage of software engineering best practices so they could level up velocity and quality

I've been working daily with React for almost 6 years now. Another 10+ years of web development before that. And I have yet to see these benefits be realized.

It's not easy, at all, to "optimize performance using memoization" in React, best practices are mostly tied to JSX/React and its tooling, not general software engineering, and they change yearly based on the latest version and current third-party library trends. Velocity and quality are both hurt. Your best bet is to use an all-in-one framework like next.js, which delegates most of the pain to the authors - but not all of it.

The big improvements that React brought to the mainstream were componentization, and popularizing declarative rendering. I think we have better options today.

Svelte does not limit expressiveness in my experience, in fact it makes it way easier to do what you actually want to do, without contorting yourself to the framework. It's liberating. This is a viewpoint I hear frequently though, so it definitely depends on your personal path as a developer and what you've been exposed to.

Re: Virtual DOM is pure overhead (2018)

#279

Post by ricardobeat »

peterhunt wrote: post #258
brundolf wrote: post #241

Earlier quoted context omitted.

> HTML and CSS not being first class-citizens as they are in other frameworks In what ways are HTML and CSS less than first-class citizens in React? In my React codebases we've always written CSS (or SCSS) stylesheets, and components bottom-out in JSX (which is almost exactly just an HTML template with inserts) In my experience the biggest barrier to (and most legitimate complaint about) React vs other frameworks is…

The main divide I've observed is whether you are encouraged to use JavaScript's built-in control flow and code reuse mechanisms or a less expressive DSL. Hooks are pretty sweet but I think they should have launched with higher order hooks that used the same lifecycle as original React. That way you wouldn't need to think too hard about things like object identity (which I think is the state management issue you're ge…

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.

Re: Virtual DOM is pure overhead (2018)

#280

Post by postalrat »

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…

Did the borland apps you developed 25 years ago handle all sorts of devices and screens including screen readers?
Post reply on HN