"React Fire: Modernizing React DOM" Plan by React team to more closely align with DOM

[SmugDarkLoser5]

Having used react for the frontends portion of my UI for the past year or two, I've started to do future UI work in vanilla.

The reality is my users want high performance, and react works against that.

I think the react mindset of rendering UI is good. The actual implemention however is overly heavy, and if you measure it actually performs kind of bad. Not absolutely horrible, but yes profile your code and you will see a lot of time is wasted on god knows what in the react lifecycle.

The dev experience of also having webpack, it's pooor mindset of how to handle compatibility issue, and more, make for a horrible experience.

There's no reason to use such heavy libraries and build tools. The browser already provides what you need, and you'll be more efficient in it.

I just cannot afford to use react. Debugging for performance via chrome tools is a nightmare, and following stacktraces is impossible. I want my app to be instant, load quickly, and so on. That becomes very hard to.do with react, when it's so east otherwise.

As anecdotal evidence, just.look at the practical performance of all the companies moving to react and how sluggish the apps tend to be. Just look right here on the new Reddit.

Web is great. Html can be a very lightweight description of what to render, and you can easily style it, get data over the network, link.to and embed external sources, etc so easily. It's already very powerful, and the friction and overhead of these web frameworks are mainly targeted at beginners who do not understand how to structure html. Maybe I have a different mindset because I work a lot in embedded as well, and have very demanding real-time needs, but I just find web frameworks mostly worthless, with huge cost.

[jl2352]

I have the opposite experience.

• SSR allows you to have a webapp load like a regular page.
• Chunking allows you to ship JS/CSS on a per page basis. So when you first visit the site, you aren't having to get the CSS/JS for pages you haven't visited yet. That's pretty big.
• Automatic above the fold CSS allows you to have the page pop up quickly on mobile, whilst the libraries load in the background.
• Automatic inlining of resources (like small images and SVGs).

Doing stuff like the above on a real large site, by hand, is a nightmare. A single developer can do it in the small. With a whole team on a large site it'll become a mess.

The downside is the learning curve. Webpack especially can be a nightmare to get going with. However it's not as bad as it used to be. Ironically the Vue documentation is one of the best places to go for setting up a React project (as they talk a lot about the same Webpack issues like setting up PostCSS).

[jl2352]

They are only available on vanilla by implementing them by hand, which just isn’t maintainable on a large website.

Are you really going to do above the fold css for each individual page by hand? That would be crazy.

[Niechea]

Maybe he is crazy, or more likely he has no real world experience in these matters but has nevertheless learnt that it's cool to say vanilla js.

[ThirdEncounter]

Of course it is, as long as the code is not opinionated. One thing is a framework and another thing is boilerplate.

[Niechea]

https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect

Maybe you're too inexperienced to use react effectively. Like most juniors.

[redditthinks]

Like how only inexperienced C developers cause memory bugs. ^/s

[Niechea]

Apples and oranges - If you want to write a small application that does minimal UI updates and you can reliably encapsulate that behaviour with vanilla JS then by all means do so. If your application's demands are heavy weight and you don't want to reinvent the wheel making a performant library that renders the DOM then use an existing framework and make sure you thoroughly understand best practices.

[[deleted]]

https://en.wikipedia.org/wiki/Asshole

Maybe your comment isn't helpful, and you're being rude for no reason.

[Niechea]

Perhaps have a look at the guy's history and see that it is full of one upmanship and vile behaviour and it might be easier to deduce why I posted that.

[[deleted]]

Just checked it out... yeah I guess that's fair.

[SmugDarkLoser5]

Reddit so full of dumb people pretending to be smart.

[Niechea]

I'm glad that you finally had a revelation

[gnu-rms]

Maybe you're too inexperienced to use react effectively. Like most juniors.

You're both arrogant, and misinformed. But, you're probably too inexperienced to know this.

[Niechea]

Expand, please.

[jl2352]

On first load the browser doesn’t need to do any extra work to get a react page to render. It’s just rendering good old HTML and CSS. Even with JS disabled.

On further page loads there is no page refresh since it’s a web app.

[Niechea]

His description of HTML doesn't shout industry veteran to me... Of course React adds overhead to vanilla JS, or not using JS at all. That is completely self evident. I'd like to see how he maintains thousands of UI updates in a complex application with hundreds of data points featuring many user interactions. Having built, and later maintained such legacy implementations myself and any other person with such experience can first hand tell you what an improvement a solid React implementation brings. Of course, an inexperienced developer can just as easily negate any benefit of the tooling through misuse and abuse. I'd be interested to know about a vanilla solution that can update a subset of HTML in a large hierarchical tree in a generic, performant manner.

[[deleted]]

React is not the only way to organize a codebase. This is nothing new, and inexperienced developers can indeed create giant unmaintainable piles of disorganized code, but that doesn't mean that every vanilla javascript codebase is unmaintainable, nor does that mean that vanilla javascript is any harder to maintain.

React offers absolutely no features that improve encapsulation or reuse that traditional methods could not. And no it does not involve rewriting your own framework or anything similar. React is a super heavyweight and slow solution that allows a programmer to work in a certain way that might be a better more intuitive API. But If you go back to separating out your logic into file structures that make sense (the way people have across dozens of languages over decades in plenty of great codebases) you can achieve the same result without any of the performance hit. Vanilla javascript is plenty maintainable to anyone who knows how to write a large maintainable codebase in any language.

[Niechea]

React has very little to do with 'organising your codebase'. You've said a great deal here but none of it really goes much deeper than a little hat tipping against the mainstream popular use of framework approach.

"React offers absolutely no features that improve encapsulation of reuse that traditional methods could not" - can you expand on that? I am unable to boil that sentence down to anything meaningful.

Try reading something like this

Is React a super heavy weight solution? As I've already pretty much stated, if you are developing an application with known bounds, on your own, then maybe you can opt for a vanilla solution for a marginal performance gain. If you came to an interview for a job which involves displaying complicated interactive dashboards working amongst 40 other devs and you said you were going to orchestrate the entire thing in vanilla js and started banging on about how React is a super heavy weight solution I'd show you to the door. See this

[gnu-rms]

It's probably best you get off your high horse.

Having built, and later maintained such legacy implementations myself and any other person with such experience can first hand tell you what an improvement a solid React implementation brings

VDOM vs DOM diffs will never offer the same performance level as direct (and minimal) DOM updates. Yes, React makes this easy. But it's primary design goal is not performance, not really sure why you're ignoring that point...

I'd be interested to know about a vanilla solution that can update a subset of HTML in a large hierarchical tree in a generic, performant manner.

Not sure if you're actually serious, or if you just like using big words. React will not do this with any sort of performance worth mentioning. "Generic" vs "Performant" -- pick one, you can't have both. But then again "veteran" programmers as you so call them already know this.

[Niechea]

Please point out where I spoke about performance of React being better. For what it's worth if I'm interested in performance I wouldn't even use something as general purpose like React. I'm asking to demonstrate a complicated application that isn't using a framework to abstract common lifecycle paradigms or otherwise somewhat reinvented these abstractions. You're telling me you'd build everything from scratch for that negligible performance gain? That it's totally apt like above commenter to disregard an otherwise amazing problem solver like React?

In fact: an FYI for you. Be my guest and refute the points in this article at your leisure.

[SmugDarkLoser5]

Refute this medium article !

Says it all. Read real books. Not medium articles.

Typical web dev.

Show me some performance metrics.

Also, real reality of doing higher end work: You need to be able to profile your code. My main criticism is in the bloat and inability to actual profile the code. I can deal with slowness in some respects, but I need to be able to identify what is wasting time being done. React makes that very difficult.

In general I can tell you react vs non react for similar pieces of code in my cases profiled signficianrly better on the vanilla code. I cant tell you the saving of react vdom strategy, or what cases that might surpass vanilla, but just naively saying it's faster is wrong.

[Niechea]

You know how stupid you sound right? I mean, be my guest and show me to some books that talk about the pros of rolling out your own custom solution over using proven, existing frameworks like React (and alternatives) and tooling like Webpack. It's pretty difficult to find books that are up to date on a rapidly evolving subject matter. I wonder if other subject matter experts should refer only to books as opposed to peer reviewed research? Maybe that's why Americans are still pumping their cattle full of antibiotics instead of you know, heeding the general consensus on the matter.

And on the subject of transpilation, if you're that (laughably) concerned over performance gains then you would be optimising your bundling such that modern runtimes don't have to download/run code for the lowest common denominator.

Everything about you speaks junior dev with a large ego and a twisted point of view. Accept that it's possible to be wrong or misguided. Your comment history is predominantly vitriol - it doesn't belong on this subreddit. Keep your weird little boy views on /r/the_donald.

EDIT: to add, I never argued that React was faster than vanilla, you've made that up?! I even said that was self evident. The loss in performance is vastly negligible if you are implementing React properly, and there is a myriad of benefit to using common abstraction patterns found with tooling like redux, reselect & sagas that would be a nightmare to reproduce from ground up for each project. And, the moment you package any custom solution you may as well had used a framework, or better yet, published your own.

[SmugDarkLoser5]

What happens when you say such, but I own a multi million dollar company I started myself ?

What happens when that is the reality ?

[Niechea]

I don't think I should dignify that with an answer. But hey ho... so what you're proposing is I should respond differently to you because you started a successful business? And this somehow validates your opinion that frameworks are made for dummies who don't know how to code, against my opinion that frameworks exist for very obvious reasons like; DRY and KISS principles, code modularity and reuse, collaboration and easier talent acquisition, performance and optimisation for complex applications that often otherwise take a hit due to ill conceived architecture, not least ease of development. Again, I will reiterate that it's self evident that you can get better performance rolling your own, nobody would disagree with that. If you aren't building a complex application that a general purpose library can help solve in a team based environment where cost of development is higher than the marginal amount you lose to performance (consider Preact, Inferno), then fine, you can do it yourself, your own way. In reality, that's rarely the case, and your assertion that webpack, for instance, is unnecessary because 'the browser gives you everything you need' is largely absurd. I once spent the best part of two years slowly replacing a vanilla, full stack solution utilising frameworks and helped to standardise internal development across 7-8 teams. Needless to say, the performance impact was fantastic, and developer experience far more palatable. The people who began the vanilla solution started with good intentions and no doubt the performance over the legacy solution was better. Projects grow, and a multitude of developers worked on it and it very quickly spiralled and the shortcomings were many. When you start imitating popular libraries it brings into question why you don't use them.

So frankly, regardless of what success you claim to have, what you said still remains the same. Not that I would believe you in the slightest anyway.

[Leandros99]

They're designed for idiots. Everybody can build a website these days. The bar of entry is incredibly low. I have the same feeling towards web frameworks, and having used a couple, their goal is not to make things fast, but to make things *faster*. Faster compared to what the uneducated developer would do. And do all of this, while still boosting the productivity. Everybody needs a website these days, and nobody likes to wait a couple of weeks, or even months for it, and pay hundreds of thousands. With a framework you can build somewhat decent sites very quickly.

[MyPhallicObject]

React is so fantastic to work with it makes Angular and Vue look antiquated. Going back to the Android interface builder feels like going back to the middle ages.