HN Theater @HNTheaterMonth

Well it makes perfect sense to me why React keeps reinventing the wheel every other version and why it's a hot mess. This video makes more sense now as to why they don't seem to have any direction https://www.youtube.com/watch?v=iRo18pUs61Q. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.

⬐ arcturus17

I have absolutely no clue what you're rambling about, but if frontend dev shouldn't consume braincells, you go on and code a complex frontend in vanilla JS and then serve that plate of hot spaghetti to the devs coming after you.

⬐ richeyryan

That video is quite poor in my opinion. He comes so close to a bunch of very interesting questions like how can state management and effect management be done in a good, scalable way that maybe isn't tied to our view libraries? He then admits he has close to no opinion on the matter and suggests web components which is about a step above the jQuery scenario he described in the beginning.

The way I see it the advent of React was basically a rejection of the imperative MVC model that was prevalent with the likes of Backbone in favor of a more functional one. The first prototype of React was written in Standard ML. The evolution over the years with flux, redux and hooks was basically answering the questions that were arguably solved in MVC already but coming from the angle of declarative, immutable approaches. Where does state live? How do I handle asynchronous effects? How do I abstract that behavior from my views?

I don't think the community has answered those questions definitively yet and a lot of the interest seems to be in refining the view mechanics with the likes of Svelte rather than really getting to grips with how to best handle long lived application state and the effects that operate on it.

One thing I could see being the case in a couple of years, and in some ways the video does reach this conclusion, is that the reactive, stateful layer will be abstracted from the view and how you render your data will be almost like choosing a templating engine on the server. It could be React, Vue, Svele, Marko, Web Components, whatever. Those libraries and components will handle your dropdowns opening and closing and your tooltips showing but your real application state that distinguishes your product from another will live somewhere else and will be less subject to churn.

⬐ baron816

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.

⬐ striking

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.

⬐ guitarbill

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.

⬐ ntdb

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

⬐ baron816

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

⬐ notus

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.

⬐ guitarbill

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

⬐ viklove

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.

⬐ baron816

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

⬐ viklove

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

⬐ pmontra

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.

⬐ potta_coffee

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.

⬐ adventured

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.

⬐ macando

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.

⬐ ntdb

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?

⬐ css

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

⬐ mavsman

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

⬐ wp381640

videos provide higher ad revenue

⬐ GhettoMaestro

Nothing - except being really fucking annoying and pretentious.

⬐ TickMark

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

⬐ nobleach

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

⬐ viklove

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

⬐ nobleach

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.

⬐ viklove

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.

⬐ jypepin

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.

⬐ paulsutter

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

⬐ ntdb

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

⬐ phailhaus

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.

⬐ olavgg

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.

⬐ phailhaus

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.

⬐ ryannevius

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

But then also: Use Polymer.