Hacker News Reader

Comment by stevebmark | Hacker News Reader

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge to other systems, like vanilla Javascript is. React is great because it's vanilla Javascript, expressions all the way down, and lifecycle methods, which everyone is used to. Hooks are a new non-vanilla-javascript paradigm with special and sometimes tricky rules. Other than, there's no reason to write React unless you're using hooks, and I wonder what the next major paradigm shift will be. I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

View on HN

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler.

Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D

(Sagas are a powerful pattern, I'm sure someone here is about to reply about how they're making good use of them. But I'd bet 99% of people using the redux-sagas library could be doing something simpler).

I have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop

They're just redux middleware implemented with generators, so you can do some nifty things with it if your use case requires. I've used sagas on a several projects and they all actually did need that type of tool but I've chosen thunks on other projects when fetching logic was simple.

I tend to use Sagas now as my go to but I am comfortable with them. I would agree with most of the sentiment on here that they are more complex, though not because of Saga's API but because one really has to understand the core workings of the framework to not screw the pooch. For many their first exposure to generators is via Saga and that is just the tip of the iceberg. One really needs to understand what all the takes are doing as well as how Saga utilizes async and await style logic. To me, Saga's a very readable and very easy to debug but some dragons lie below the API and one has to understand that those dragons are doing magic a lot differently that other frameworks do magic. It's just not a framework where you get to ignore what the magic is doing for you as you will create nasty bugs due to lack of understanding about what the framework is trying to do and it becomes easy to fight against it out of ignorance. That being said, my general opinion is that I like Saga and we generally choose to use it as a team.

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior.

I wrote about why I chose thunks as the default in our Redux Toolkit package:

https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

and our Style Guide docs page specifically recommends using thunks as a default:

https://redux.js.org/style-guide/style-guide#use-thunks-for-...

I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.

One of the things I love about ClojureScript's Reagent library is that I will never need something like Redux because Clojure has was Redux does "for free." Reactive state management is baked in at the language level.

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say:

> If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable.

Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3").

How are we supposed to deal with these things with thunks?

Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you.

Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead.

[0] https://redux-toolkit.js.org/api/createAsyncThunk

[1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...

+1 for being on board with whatever killed render props and a bunch of HOC's.

Mostly like them, but still not sure the canonical way to write update logic comparing prevProps to current props and running something if it changed where there is more than one dependency though. Need to store prev value in state to compare, or best to ignore the exhaustive deps warning and only run when the prop in question changes? Swear I looked all over and couldn't find a good answer.

What's the problem with render props? You need a component to provide values to its unknown children, you either do render props or you need to clone the children injecting them the values. I find render props to be a much more clear pattern than clone. It also works nicely in TypeScript doing the proper type checking. Am I missing something?

Edit: I think I missed the point. Hooks do make providing state to children simpler in a lot of cases. I just don't hate render props that much :)

Yes, I honestly wonder if, with a few minor changes to make it more conventional js, you could address a lot of the criticism.

Suppose you replace:

  const [count, setCount] = useState(0);

with

  const [count, setCount] = this.useState("count", 0);

I'm just speculating idly, but if you use `this`, it's clear how the function knows it's component. If you pass an explicit key, I don't think you need the order to matter. And if the order doesn't matter, well, conditional logic ought to work normally, even if it's a bad idea?

I have no idea if there's a compelling reason this wouldn't work, but if it would, it seems like it could take a lot of the magic and nonstandard behavior out of the API.

> React is great because it's vanilla Javascript

What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.

Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).

> an absolutely huge departure from vanilla JavaScript

Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

For example Angular templates, stuff like Razor in .NET, etc?

Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup.

If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations.

From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.

The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way.

Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical.

P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.

> From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application

I don't think that's true at all. I find react-hyperscript[0] and friends terser, more regular and just as easy to work with as JSX.

[0] https://github.com/mlmorg/react-hyperscript

That's just reductio ad absurdum claim.

JSX is one simple conversion while coffeescript or elm are entire turing-complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.

Yeah, all of the dynamic parts of JSX are Just Javascript.

You can also look at JSX and know exactly how it will compile to Javascript because it's so simple. (foo && <Component {...props} />) -> (foo && React.createElement(Component, props)).

It really is just React.createElement calls. It just isn't a huge departure.

Meanwhile, what Elm compiles to is very nontrivial. The comparison only makes sense if you never actually looked at what JSX does thus mistake it for something much more complex.

Try it out yourself: https://babeljs.io/repl

"just convert" is in itself a huge departure from plain Javascript (in the sense that you now need a whole transpiler to get anything running at all, vs just running the source code as is)

The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.

<Foo bar="baz"/> = Foo({ bar: "baz" })

<Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })

Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)

I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.

I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).

The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.

This argument maps to CSS-in-JS, too. It's a misunderstanding that this pattern would be rejected outright.

JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.

It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.

None of that matters to a React developer. If you know JavaScript, you know JSX.

I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important.

(also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)

We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.

> We're talking two different things. I'm talking about the developer perspective. You're talking about browser.

I'm not. I'm talking about a programming language. It has a spec.

"if you know JavaScript you know JSX" - JSX is just a JavaScript expression.

This is nonsense. Where is JSX in the JavaScript spec?

You talk nonsense just for the sake of it. I never said JSX is in the spec. If you know JavaScript basics (what an expression is), it takes a minute to understand JSX.

You're talking about something different to me then criticising me for it. The quote I was originally replying to was:

> React is great because it's vanilla Javascript

React is not vanilla Javascript. "it takes a minute to learn JSX" isn't disgreeing with that statement.

If you oppose JSX, then you should doubly oppose Angular Templating language, since that's an entire language construct that gets compiled to JS function calls. Broader point: We need some syntactic sugar on top of JavaScript for writing UIs. JSX is about as simplistic of an abstraction you can get it. It's incredibly easy to reason about its pre and post-compiled syntax. Not the case with other paradigms.

> the major complaint I have about hooks, which is that it's no longer Javascript

Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.

It is JavaScript, but it doesn't feel like JavaScript. What looks like a pure function isn't actually, and can do a different thing depending on where and when you run it, all hidden in some magic within the React library.

JS is one of the most un-opinionated, flexible language around, I do not believe there is a one true way™ of doing JS. For example, React and Angular have very different approaches (functional vs OPP) on how to JS.

I do agree that having something do a different thing depending on where and when can be counter-intuitive.

Meaning that instead of using existing JavaScript structures to provide instance state, it's re-implemented in an abstruse way that creates a whole bunch of constraints on your code and new rules to keep in your head at at all times that are react-with-hooks-specific.

Reply on news.ycombinator.com