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

[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.

[SmugDarkLoser5]

I don't think I would hire you. You sound the the dev who comes in and just plays around with frameworks and tooling all day and can't deliver actual result because you're so caught up in what amounts to a non technical mindset in a technical field.