Why We Should Ditch React [video] | Hacker News Reader

Why We Should Ditch React [video]

youtube.com

39 pointsmacando31 comments

This is a long-winded rant that seems to boil down to advocating for avoiding frameworks altogether. Not worth the watch.

TLDW: “the whole point behind this video, guys, is maybe we should ditch React because all of these changes are because of short-sighted architecture, and maybe we all shouldn’t just be these herd animals that are constantly taking and following the herd from one section of the field to the other you know we keep going around in circles and getting nowhere.”

Sounds like he's never had to develop a complex stateful application. In the comments he suggests we can get away with just using "raw js and a decent MVC framework", which becomes unmaintainable very quickly.

There is no such thing that raw/vanilla js is unmaintable, what is unmaintainable is stuff that breaks regulary and vanilla/raw js never(almost?) breaks.

Er, what? The language is not what is breaking here, your application is. If you try to build a complex stateful application with no frameworks, you will more than likely create an unmaintainable buggy mess. You won't be able to reliably add new features without breaking something else.

And he continues: "So what is my proposal? I don't really know."

But then also: Use Polymer.

Summary: this guy doesn’t like hooks because he doesn’t like learning new stuff and he wants to throw out React because it changed a little bit. Doesn’t mention the benefits of framework changes or rationale behind them.

Definitely garbage YouTube click bait here. Don’t bother.

He does have a point that churn/the new hotness is a real issue, and the latest hotness in JS library/framework have a very short shelf-life. On the other hand, projects like Babel or Polymer, that want to be obsolete at some point, but will require minimal re-writing when that happens are excellent and future-proof.

"The new hotness" is not a problem. It is a problem when developers insist on using "the new hotness" regardless of whether it adds value. There are many thousands of applications using React without hooks that are working just fine and will continue to do so indefinitely.

There is a far less framework churn now than there was 10 years ago. React, Angular, and Vue have all been around for a long time now relative to previous JS frameworks. React makes a lot of changes but they are, on average, improvements. Not all of them are the best decisions and some are temporary band aids to support new features, but the constant iteration in response to changing expectations for web is one of it's strengths IMO.

Angular 1 or 2? Cause the latter seems to be 3 years old. Okay, facile argument, the others are 5-6 years old from a quick search.

> React makes a lot of changes [...] the constant iteration in response to changing expectations for web

maybe it's ironic we're having that discussion on HN, and i'm struggling to remember sites that have gotten better lately, not worse. then again, that's probably because of the bias to remember negative experiences

Definitely not a novel point. Nor particularly accurate anymore as other commentators have pointed out.

It's not like React.Component is gone, either. Still there. I think it's still the only way to make an error boundary component, too.

To be fair hooks are kind of a frivolous feature that add no new functionality (just another way to do something we already could). It does irk me a bit when library maintainers do stuff like this because it just introduces more complexity and more patterns into a framework that people feel the need to tap into. Smart devs will just opt not to use hooks, but it sucks that the industry will likely adopt it for no reason other than keeping up with the latest trends.

React peaked at v16.

> Smart devs will just opt not to use hooks

Couldn’t disagree with you more here. Smart devs use smart abstractions. Hooks is a smart abstraction because 1) classes and inheritance don’t belong in JS, 2) they allow for more code reuse, 3) they allow you to write simpler, more declarative code.

> 1) classes and inheritance don’t belong in JS

You gonna back this claim up? Because it doesn't stand on its own. Inheritance certainly doesn't gel with _React_ (use composition), but to say it doesn't belong in JS is rather naive.

> 2) they allow for more code reuse

You can already get just as much reuse out of React's context API

> 3) they allow you to write simpler, more declarative code.

This is rather subjective, but I'd argue it's not simpler, because it "hides" the state with internal magic, and it's not even more declarative because using a context (or composition) based approach would be just as declarative.

I'd actually argue it's far more complex, because each invocation of `useEffect` doesn't even have the same result! There's some behind-the-scenes magic going on that makes it harder to reason about and find bugs.

The nice thing about having classes is that it's very easy to understand what code runs when a component is initialized (constructor and componentDidMount) versus what code is run on each render cycle (the render method). Hooks just removes that whole distinction and throws everything into one place. Devs who are new to React will definitely struggle with understanding what is going on behind the scenes.

I usually don't look at videos (it takes too long) but I was complaining with myself that React is needlessly complicated so I checked it.

The point of the video is not so clear, maybe it's why reinventing the wheel again and again and not coming up with a good wheel once again.

First what I like of React vs (example) jQuery: despite the complexity a React (or Angular or whatever) application is infinitely more maintainable than the corresponding jQuery one. I converted one to React when I didn't dare anymore to fix bugs in a jQuery monster I created.

However, wrestling with dispatch, props, Object.assign, actions etc can't be the right way to do it. After all these web applications are the same thing we were doing in the 90s with VisualBasic or similar systems. Replace disk access or local Access dbs with JSON calls over HTTP, not a big difference and yet, coding a React app is a miserable experience. I think frontend developers should be paid twice as much as backend ones: they do a much more difficult job. For sure I don't want to do frontend development: it's not an efficient way to make money.

Some context: I'm mostly a backend developer now and I'm spending a few days working on a React frontend every two or three months. So I'm a little too rusty every time I start working with React. That doesn't help but I can't help feeling that code as complex as this smells of wrong architectural decisions. A collegue told me that Vue is much more pleasant to work with. I could give it a try if I'll ever have a personal project needing a complicated frontend. Server generated HTML is fine for everything else.

I heartily recommend Vue. Similar in principle to React, but but fewer things to remember. Still have to pass props etc but I'm not a front-end developer, more of a generalist and I find myself being very productive using Vue.

I agree with your colleague: Vue is a lot more enjoyable to work with. I've disliked React every time I've worked with it and Vue has always been a good experience by contrast. For some reason working with React always makes me feel like it's the Java of JS frameworks. The problem ultimately is, Vue has long since badly lost the mindshare battle, React won. That doesn't matter for every developer or situation of course.

I'm a fan of React but I posted the link because this time the author actually used React for many years. Usually, people criticizing it are still learning and are frustrated by React's vast and fragmented ecosystem stemming from its open nature.

The author's criticisms do not seem to be insightful. They boil down to "bah humbug stop changing things". Did you get something more useful out of it?

What advantage does presenting this in video form have over a blog post?

Just depends on the viewer. Some people prefer audio books to books.

videos provide higher ad revenue

Nothing - except being really fucking annoying and pretentious.

Because I wound never read this blog post. Video, on the other hand, I will listen while preparing my lunch.

The comments are a bit disconcerting. "Redux is trash"? It's a finite state machine. At its simplest level that's all it is. Now, I get that requiring it in every single React app makes little sense, but the library itself is just too simple to be considered "trash".

It's trash because people are dumb and it encourages them to store all of their state globally.

I'm pretty sure that is discouraged by the docs and the author. Just because a library doesn't pop up a bouncing anthropomorphic paperclip and specifically ASK you, "are you sure you want to store this state globally?", doesn't mean the library is bad. Just think of the brain-dead things the C language allows you to do with malloc! Yet that's not at all C's fault.

It might not be Redux's fault, but the result of Redux being a popular library is that many projects have all of their state stored globally. This would not be the case if Redux didn't exist. Call me consequentialist, but I think Redux has to share some of the blame.

The first 13 minutes are just a history of how we got to React. The remaining is the author saying it's bad, but that he doesn't have a solution.

Not worth the watch.

Waste of time - he never explains what we should use instead

Reply on news.ycombinator.com