Hacker News Reader

Comment by megaman821 | Hacker News Reader

The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many caveats and such a terrible API. A magic "use client" string at the top of a file is just ridiculous. React code is nearly impossible to understand and write without extensive external documentation now. I feel sad for the future developer that has to modify this type of code ten years from now; I hope Google is good at searching decade old documentation to figure out what the hell is going on in old React code.

View on HN

This is how it always goes. JQuery was a response to browsers having poor standardization. Then it became a larger and larger ecosystem, and the code owners started getting megalomaniacal (I'm sorry, "live" is deprecated, please us the function "on" which does the exact same thing, we just liked the name better, thank you for complying). It became an ecosystem. Every 3rd party library was designed to integrate with JQuery. Soon there was JQuery UI, a UI library for adding modal dialogs and tooltips.

And then someone realized that browsers had long since reached standards parity, and javascript engines were getting really fast, and re-rendering the DOM was GPU-accelerated, and we just needed a simple little library. And Angular and React were born (and Ember but we don't speak of satan in this house).

React feels like it's following the exact same trajectory. It was created out of necessity, it was the best framework for a given point in time, but it's being stretched to handle the changing landscape, and it's feeling very kludgey. I expect that soon, very soon, someone will release the new paradigm. Probably just as soon as WASM is able to manipulate the DOM without JS hacks, which has been on the roadmap since before there was a road.

Agreed. IMO, it all started with Hooks. Things really went downhill from there. useEffect is terrible! Example, how easy it to forget the dependency array?! Because of that, you have to setup linting rules to fix the poor API provided by that hook...

Hooks felt like a big make-work project to let folks claim high-impact commits on a project that didn’t really need any of those, anymore.

What does this expression mean, make-work project?

Digging a hole and filling it back up again. Work for the sake of having something to do.

Ah I understand it now thanks. Not an uncommon thing in many places!

HN is a funny place.

A useful feature that an insane majority of React devs have come to prefer is "downhill."

Kids these days.

Many folks were criticizing hooks when they were introduced.

Of course React devs will "prefer" it; they are the idiomatic way to adding state/triggering effects in React.

There is zero functionality that has been removed from class-based components.

Devs use hooks primarily because hooks are better.

> There is zero functionality that has been removed from class-based components.

No, but the React ecosystem has almost collectively migrated away from class-based components or deprecated support for them.

> Devs use hooks primarily because hooks are better.

You avoid much of the dependency array issues by using class components. But you have to deal with `this` and it's significantly more keystrokes. It's more of a tradeoff in my opinion.

Well yes that's exactly what I said: it had been very very widely adopted

I don't see where you said that. It sounded to me like you were insinuating that hooks are inherently better than class components, and that zero functionality has been removed from class components, they are still viable (but they have largely been left in the dust by most popular libraries).

Also, devs don't use hooks primarily because they are better. They use them because they are idiomatic React in 2023.

That's akin to saying people don't like Taylor Swift's music because it is good, they like it because it is popular.

:hmm:

It is not akin to saying that. Please argue in good faith [1]. Writing idiomatic React code makes a lot of practical sense (easier-to-find examples e.g. in the docs, wider library support, onboarding newbies). You can choose to use hooks while acknowledging the tradeoffs from class components.

[1] https://news.ycombinator.com/newsguidelines.html

> zero functionality has been removed from class components

yes, exactly!

> They use them because they are idiomatic React

right, and do you think it'd be easy for a feature to become idiomatic if it wasn't an improvement over the previous patterns?

As someone who used to use React and now has to grapple with an in-house web framework: hooks are right on the money and offer tools backing some of the best devex in web right now.

I've been using React and writing it professionally since early days before they even supported using ES6 classes. I have also answered questions for years on one of Reacts largest discord communities.

Hooks were nice when they came out, but woefully under-documented. The fact that decent docs for hooks first development came out literally just this year when hooks have been out for years is kind of a shame.

As opposed to useEffect, most other hooks are fairly straightforward, but the fact it years of articles upon articles of mistakes and documentation to explain useEffect to both experienced and non-experienced devs alike shows that it really wasn't that great of an API for end users.

In fact the most common topic nowadays is how much you need to avoid useEffect, especially if you're not a library developer. None of this was documented/mentioned when it first came out.

Yes it does enable powerful workflows, but plenty of other frameworks/libraries handle the same thing in a nice way with much less drawbacks than react. (ex: automatic dependency tracking, etc)

The number of times I have to tell people to stop putting things in effects at all, or that the reason something isn't working is a stale callback due to missing dependencies in my opinion shows that its not really a good API for the average dev to be using.

Your last paragraph rang so true. Webpack will tell you that you are missing a dependency and ask you to include it or remove it. I feel useEffect is a fine api. It’s not the apis fault if I shot myself in the foot with it.

I find it's mostly the kids who like hooks, and the older devs who've been around since jQuery or further back, who dislike them.

For what it's worth, that's not at all my experience on the teams I've worked with. I was around when hooks were released and it was an immediate and significant improvement to our team at the time.

I'm 49 and started with the Commodore 64, and function based components with hooks are so much cleaner than the old class based components, it's unbelievable.

The classes had closely related functionality spread out over several different methods making them hard to understand at a glance, function based components are very concise.

I think people who dislike hooks tend to overuse useEffect (it's rarely needed) and to do too much inside components rather than inside custom hooks.

My experiences with jQuery are literally the exact reason why I like React.

I strongly suspect most HNers who are overly critical of React (and/or general web framework complexity) have never had to write and then maintain a large web application in jQuery.

JQuery is just a hammer. Its not a framework. It does provide utilities like selectors, events, triggers, dom manipulation etc. React is a component based framework. It contains pages, routes, state management, caching etc. You cannot compare those two. In a way jQuery is low level just above vanilla. Wheras react has a minimum of 500 execution layers. Thats why its slow and painful in many cases.

To be pedantic, React is a library, and doesn't provide page abstractions, routes, or state management outside useState and useReducer. It also doesn't have very strong opinions about how you structure your application (what a framework does). That's what Next.js is for.

I agree with your overall sentiment though.

> It contains pages, routes, state management, caching etc.

React does not have routes or caching. It has about as much management as jQuery.

Not talking about React, I’m talking about effects. Two very different things. I love React, I don’t love hooks or effects.

I don’t think application state belongs inside the rendering machine.

I think this is an artifact of HN's voting system. Most readers probably don't have enough karma to even downvote. For the ones that do, guideline discourage downvoting for comments that you disagree with.

And I can see why the majority of HN readers would upvote the top level comment. Particularly since it's a popular re-hashed opinion.

Top comments aren't a good survey of the opinions of a specific community for that reason.

> HN is a funny place.

Full of (ex?) React devs. There are way better things out there now if you are starting a project from zero.

In my experience, a lot of people don’t actually know how to use hooks correctly and find them frustrating as a result. It depends on what you’re used to, but I find that class based components leave too much room for scattered logic. Let’s not also forget those who abused `shouldComponentUpdate`.

Wait until they find componentDidUpdate and the cascade of if statements to handle what useEffect does very elegantly.

Every other framework not only has its own implementation of hooks, but notably: every one of them is faster, smarter, easier to write, or a combination of all three.

I agree that useEffect is bad.

But there are other SPA frameworks that do things better. In fact, just about any other framework does things better.

In your estimation, what framework has best in class hooks?

Some alternatives are:

Vue3/composition API -- probably the simplest if you're coming from React. Definitely feels like it was inspired by hooks.

Svelte/store -- svelte has a term called 'hook' but it's unrelated. The equivalent would be Svelte's store.

The other frameworks use something called 'Signals' (Preact, Qwik, Solid, Elm and even Angular/backbone though I don't personally have in depth knowledge of all of these).

IMO, I would prefer Svelte if you are adventurous, or Vue if you like React but just want something like 'better React'.

I mean, Svelte/store is something completely different though, isn't it? it's more akin to Jotai/Zustand/Redux and friends than it is to hooks. If you had to compare Svelte with React, the thing "closest" (while stretching that word very much) to hooks would be the `$` reactivity things Svelte does? Because if you want a state management solution, react has that as well (many, in fact). Just not built in, and a lot of them work really well

You dont have to specify the dependency array, it’s an optional optimisation.

Effects are not required to be idempotent, so it's not just an optimisation. React documentation has an example where the effect establishes a network connection. Even if there's time to connect between renders, the remote system doesn't necessarily handle such short-lived connections.

This isn’t quite true. If your effect depends on state, that state must be included as a dependency.

This is easy to miss, so you install an eslint plugin to warn you about missing dependencies.

This causes the opposite problem - adding dependencies unnecessarily to silence the warning. Then you need to ensure those dependencies are stable to avoid running the hook on every render. Or ignore the warning with a comment, and you’re back to square one.

It’s all too easy to write an effect that either doesn’t run when it should, or runs when it shouldn’t. This is especially true for inexperienced developers.

I switched to React when jQuery (and particularly storing state in the DOM and lots of custom events called) became a PITA.

I don't feel that React has reached that tipped point yet, but when it does I'm hoping we'll all move to Sveltekit or something like it.

I despise almost every single web framework written in the last decade. They always feel like byzantine monoliths of complexity built from tons of layers over existing libraries. They invent tons of concepts, always require patching, and have an army of sycophants who believe building a web framework is basically rocket science and only a select few are ever capable of such a feat.

SvelteKit is the first piece of web tech that I actually enjoy using. It’s the rare piece of tech that knows its lane, stays in it, and excels at it. It is marked by fewer features that work well together vs lots of features that sort of work well together.

You can read the docs in an hour or two and then start to get an understanding of what it’s doing.

Basically, it feels like it was made by someone who really understands the medium, thought deeply about how to distill that, and iterated to improve on it. (I get same vibes from Vue, but don’t have much experience there)

I remember when HN said that about React. Lololol

Totally fair comment. Time will tell.

Edit: I'm just happy to find something that I like to make web stuff in. Now I can make some apps and actually enjoy the process.

How do devs generally feel about Vue 3?

So far it seems really amazing even for the most complex apps. I’ve built 5 nontrivial apps with 2 being 2+ year projects

I haven’t found a “ceiling” yet

> The function useEffect has so many caveats and such a terrible API.

Really? What caveats?

The only maybe oddity that I can think of is that if the deps array is omitted it always runs.

What API would you prefer? Something more like signals?

This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive.

[0] https://react.dev/learn/you-might-not-need-an-effect

That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples.

- Don't use effects for things that aren't genuinely effectful

- Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again.

Neither is React-specific.

tl;dr Don't use useEffect if there is an alternative.

That's a bunch of examples where there are good alternatives.

In particular that it's OK to directly call setState inside functional components was a surprise to me (when I read that some months ago), it does make things simpler.

Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way.

I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it.

You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.

But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc.

Hooks imo are great, as they are pretty explicit and low level.

Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.

I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.

I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones.

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

Thats a cool project.

>But I don't think the "pretend it isn't" makes any sense

Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it.

>I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones.

I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well.

I'd probably like React better if it had a compile layer on top of its more functional parts?

As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.

I don't think React ever pitched view as a function of state actually. Many in the community latched onto that, and some React-inspired projects tried to make that a thing, but I'm positive that was never the pitch from the core team, in fact very certain of this.

Lifecycles existed since the first version, and they were always absolutely critical. Hooks just fixed many of their issues and made them more elegant, composable, and simple to write.

>I don't think React ever pitched view as a function of state actually. Many in the community latched onto that, and some React-inspired projects tried to make that a thing, but I'm positive that was never the pitch from the core team, in fact very certain of this.

If it quacks like a duck..

> and in an ideal world I shouldn't be this granular about it

Hm, could you give an example of this ideal performant state management world? Angular? Vue? Svelte? MobX?

Svelte is a good example. But you don't have to go that far; Solid and Preact have signals with auto-tracked dependencies.

As another commenter mentioned, yes it's less low level than managing your own dependencies, but then again, most React apps are already wrapped in layers and layers of abstractions/context providers/selectors and use Jest as their test runner (which injects the global namespace with functions) and does other black magic and weird metaprogramming, so I think most React devs are already OK with less lower level stuff.

I'm a bit surprised the poster was asking for something more magic not less.

I mean, I am OK with magic, but it has to remain magical to me. The moment I have to deal with the magic, I don't want it anymore.

Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.

The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this."

> What API would you prefer? Something more like signals?

Yes. Or full tree redraws like Mithril.js did 8 years ago.

React does full tree redraws (well, unless you use memo).

useEffect is for side-effects.

It does not. Child components will only render when their parent component re-renders or for example, its state changes.

Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).

Class components have "shouldComponentUpdate()" that avoids this entirely.

Or you installed the lint rule once 4 years ago and never had a problem again.

Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.

> That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with

I don't really agree with this except to the extent that, sure, it would be ideal for all APIs and indeed the entire syntax of your programming language to be so well-designed that you don't need any lint rules to catch common mistakes. I'd love it if my static type checker could catch most mistakes like this (although the boundary between linting and static type checking is fuzzy).

But in practice, you're almost certainly going to either 1) have a linter or 2) have strong resolve that you will not make any easy mistakes that a linter could catch. And if you're in the second boat, it doesn't make sense to single out this particular easy mistake, given that omitting arguments is always an easy mistake to make in JavaScript.

> Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule.

Which linting rule?

> That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.

Yes, not to mention eslint is slow with large codebases. Fingers crossed for the Rust(?) rewrite.

The linting plugin is eslint-plugin-react-hooks[0], which enforces React's "rules of hooks"; it can detect when you access a value inside a React hook and will warn you that you should add it to your dependency array. It enforces some other rules here and there but that's the big one worth caring about the most. I would consider it essential for working with React hooks.

The only downside is that sometimes, the rule can end up being overly aggressive and tell you to add things which you explicitly don't want in your dependency array, but it's helpful probably 95+% of the time and not hard to opt out of or work around as needed.

[0] https://www.npmjs.com/package/eslint-plugin-react-hooks

Ok, these are the linting rules I was thinking of when I mentioned this in the other comment: https://news.ycombinator.com/item?id=37410666

As you already mentioned, it's not a silver bullet.

Can you be more specific which linting rule you're talking about for the sake of readers who may be unaware, and perhaps mention how this completely solves this problem? Because 1. a linting rule does not absolve this from being a footgun and 2. if you're talking about 'exhaustive-deps' there are many cases where following the linter here has caused infinite render loops among newbies across multiple teams I've worked with. Also see this highly contentious thread: https://github.com/facebook/create-react-app/issues/6880

The number of times I still see people not follow the lint rule even when it is installed, or use things like eslint-disable because its not always intuitive how to get around certain scenarios kind of rules this point moot.

In my opinion if people have the rule installed and still feel the need to disable it then it shows there may be an issue with the API itself. This is coming as someone who has written React for a living since before even ES6 classes were supported.

I see it relatively often, including in production codebases where people just disable the rule because they don't know how to write the sometimes non-intuitive way to get around it.

This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc).

useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.

Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that.

Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.

> As long as the JavaScript VM and the DOM uses non-blocking async models

The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).

While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.

It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).

THAT'S THE BEAUTY OF IT!

Thing about async/await.

  const a = await doThing();
  const b = await doOtherThing();

The order of the written code and the order of the executed codes are two different things. Being able to write code in proximate/logical order is a enormous relief, even if things don't actually happen like that.

Same with hooks.

To be fair I wasn't very clear, but what I meant was like this:

  function SomeComponent({ someProp }) {
    function doStuff() {
      // do stuff
    }

    useEffect(doStuff, [someProp])
  }

This trivial example is easy to read, but as more state and effects get added to a component, it quickly becomes fairly cumbersome to figure out the exact order in which your code runs.

They're side effects, by the very nature of them, if you're putting them in your code you shouldn't care which order they run.

It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...

I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'?

[0]: https://immerjs.github.io/immer/

> I hope Google is good at searching decade old documentation

Google isn't even good at searching recent documentation, from my experience.

It will turn out to be a great conspiracy where the React team are being encouraged to make it so only LLMs can make sense of React code in future.

Agreed. React is great but I really do not enjoy writing it. Much prefer Vue

Reply on news.ycombinator.com