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

291–300 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#291

Post by nwienert »

The5thElephant wrote: post #274
nwienert wrote: post #234

Earlier quoted context omitted.

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 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 minimum importing CSS.

React has some of the most gorgeous style solutions around (I should know having built the best one) and has since forever ago. Svelte is less popular than many React starter kits with I'd argue much nicer DX.

CSS needed drastic changing too, and I think if you looked on average total CSS knowledge is higher than ever, you're just seeing frontend become popular and wide, different types of sub-specialties at this point.

[0] https://youtube.com/watch?v=HHTYHm6qLFY&t=19

Re: Virtual DOM is pure overhead (2018)

#292

Post by vbezhenar »

scotty79 wrote: post #193
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…

What does usePromise is supposed to do?

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 user of this API and handle edge cases.

Re: Virtual DOM is pure overhead (2018)

#293

Post by vbezhenar »

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.

Strict mode is not something that should be avoided. In the future versions React will do stuff that it does with strict mode today. Of course you can use a regular async function in useEffect but you'll quickly notice that it's called twice in strict mode. And you'll want to abort running fetch. Then you'll notice that responses can arrive out of order and your state updated with outdated response which happened to arrive last. It's easy to use async code in useEffect. It's not easy to use it correctly.

Re: Virtual DOM is pure overhead (2018)

#295

Post by MrJohz »

The5thElephant wrote: post #273
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…

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 having to create a new file whenever you want a new component. In JSX-based frameworks, I tend to start with a component in a file, then split it up into multiple components in one file, then finally into different components in different files as I'm going along - the same as I would do for normal Javascript functions. That's difficult to do in Vue, and I often find components tend to grow much larger and more unwieldy because it's easier to just add more to a single component than to split it into multiple components.

I also like the way CSS is built in, but I'm unconvinced that magic style scoping is all that helpful. I found myself fighting against it, and trying to remember the correct `::v-deep` incantation more often than I'd like. For me, the ideal abstraction here is CSS modules, where the class names are scoped, but the actual declarations behave like normal CSS. I never managed to get CSS modules to work with Vue, but we were stuck on Vue 2 for a long time, and that might have changed with more recent versions.

But I think that's the thing: there isn't really a clear "best in class" here. 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. There are definitely downsides, but there are downsides in most of these solutions.

Re: Virtual DOM is pure overhead (2018)

#296

Post by scq »

leetrout wrote: post #238
satvikpendem wrote: post #225

Earlier quoted context omitted.

Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparab…

> For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world. Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. I do find it interesting that it says it performs faster due to reacts scheduler.

You don't _need_ react-three-fiber to embed ThreeJS in React component either.

The point of react-three-fiber is that it allows you to use React's declarative rendering model to render your scene.

Re: Virtual DOM is pure overhead (2018)

#297

Post by Alifatisk »

shepherdjerred wrote: post #286
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…

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.

Re: Virtual DOM is pure overhead (2018)

#298

Post by harel »

vbezhenar wrote: post #293
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.

Strict mode is not something that should be avoided. In the future versions React will do stuff that it does with strict mode today. Of course you can use a regular async function in useEffect but you'll quickly notice that it's called twice in strict mode. And you'll want to abort running fetch. Then you'll notice that responses can arrive out of order and your state updated with outdated response which happened to…

Whether it should or should not be avoided is a preference. That is why it's not forced. I don't want or need it. And if I do, and it's caveated with double-useEffect - so be it. I have a feeling there is a lot of overkill in your approach but of course I lack context so apologies if I'm wrong.

Re: Virtual DOM is pure overhead (2018)

#299

Post by fleddr »

postalrat wrote: post #280
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?

Does any web framework do that? No, you have to do all of that from scratch.

Re: Virtual DOM is pure overhead (2018)

#300

Post by scotty79 »

vbezhenar wrote: post #292
scotty79 wrote: post #193

Earlier quoted context omitted.

What does usePromise is supposed to do?

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?
Post reply on HN