Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I used to think that React is awesome, but this has gone too far. They just don't care about JavaScript.

1. They introduced hooks which must be called in the same order for every execution. You can't put hook inside `if`. Hooks are based on magic. This is terrible design.

2. They didn't adopt async/await, inventing their own suspend stuff.

3. Now this: they just convert the source language into something else.

The JSX idea is gold: introduce XML-like template syntax into the language to avoid need for foreign template language. Make XML templates valid at startup and even with proper types for TypeScript. This is very important advancement compared to text templates which are used everywhere else.

The stateless render function is good. Emit desired-state, let framework to reconcile current state to desired state.

But rest of React is not gold.

View on HN

Hooks are not magic, they just increment an index that's used to access the state, which is saved in an array. So you have to call the same hooks at the same time on each component function call. That's it, zero magic.

Async and await is not useful for React, Suspense is done out of necessity. It's have to be generators if anything - but Suspense is older than wide support of generators and async/await too.

You don't have to use hooks nor Suspense at all - just use your own state management and pass it as a prop at the root render call, or no state at all.

> Hooks are not magic, they just increment an index

I think it’s reasonable to wonder why they’re implemented in such a strange and brittle manner as that. Vue needs no such weirdness, the composition api just uses normal scoping in JS.

I'm not sure why you're being downvoted.

Your comment might not bring much new information, but I agree with what you say.

Except maybe for one thing: "state" is about observability. That's what justifies the "rules of hooks", not the inplementation details.

I guess people call hooks magic because they look simpler than they are, as if their implementation would rely primarily on closures, which is not the case.

But they play very well with reasoning about closure scoped inside of React components.

Regarding async/await, I'm really pretty much torn. Why can't Suspense wait for any Promise to resolve? Or has this changed by now?

Regarding conditional hook calls: this is really a non-issue in practise, it sometimes even helps with code quality.

Would you initialize an observable property of an object/component conditionally?

I think I'd prefer to avoid that as well.

Conceptually, a `<Suspense>` component acts like a `try` boundary around a given component subtree. If _any_ component inside of that subtree suspends, it needs to "bubble up" to the ancestor `<Suspense>`.

But, React implements the core component tree rendering logic via a single `while` loop that iterates downwards. That's flat, logic-wise, whereas the tree is nested.

Meanwhile, React already had similar behavior for its error boundaries, where a thrown error in a component would get caught by the component rendering logic and it would "bubble up" to the nearest error boundary.

So, they opted to implement Suspense's mechanics the same way, except that instead of throwing an error, you throw a `Promise`.

Meanwhile, React components on the client have always been pure synchronous functions. No `async/await`, no generators, and thus no support for returning a promise from a function.

With React Server Components, React now supports `async function` components _on the server only_. They've done some prototyping with support async components on the client (and I think even briefly accidentally had a couple releases where that technically was turned on), but there's some kind of either technical issue or release planning issue that's kept them from building out that support for client components (possibly support for `AsyncContext` in browsers).

Thanks for your explanation.

What I don't understand is why there's no easy way to conditionally render a subtree depending on promises contained in the props of the top-level component.

Kind of like a guardian HOC triggering a re-render whenever all props promises resolve.

Is it because that would be a one-time thing and not synchronously reactive?

Seems like people reimplement or reuse this kind of thing all the time, but often using useEffect (transforming side-effects into state, losing deterministic rendering).

You're right that this would get ugly really fast with nested suspense boundaries though.

Hmm. Trying to understand what you're suggesting here.

You can pass _any_ JS value as a prop to a child component, and there's nothing special about any of that as far as React is concerned. You can pass a primitive, an object, a Promise, an AbortController, a DOM node, anything. All React cares about is "here's what gets passed into the child".

Suspense has a couple key bits of behavior: it needs to let _deeply_ nested components trigger the _nearest_ Suspense boundary, and it also needs a way for React to know when the async behavior is done (ie, the promise resolves) so that it knows when to re-render. Throwing a promise is certainly unusual conceptually, but makes sense in light of those constraints.

(I'm probably misunderstanding what you're envisioning and didn't manage to answer it properly - feel free to clarify with an example if you'd like!)

Yes I'm not sure myself if what I say makes sense when thinking it through again.

I was thinking something like

  <WithPromises asyncProp={promise} asyncProp2={promise2}>
    {(resolvedValues) => children(resolvedValues)}
  </WithPromises>

But that's already possible to do yourself I guess, but better in different way.

E.g. not using a function prop as "children" etc.

Many libraries also provide nice and clean interfaces to provide async state (e.g. react-query) and then of course there's good old useEffect.

I think I see why they use a different approach.

Guess I'd mainly just love a streamlined API for data fetching built into the core.

Right now it's a lot better to just have async code outside of react change prop values.

Love the section on client data fetching in the react docs though.

Generators were in every browser in early 2017 and Suspense was in late 2017?

Latest version of every browser, not every browser version I was forced to support because it was still used by a big chunk of users...

When it comes to composition, hooks are a godsend. I don't understand how so many dislike them, they were what made me finally go "wow, react is better than backbone / marionette". Well, that and being able to do <></>. Although to be fair marionette struggled with that sort of thing too (replaceElement anyone?).

Once you learn the basics, as long as you stick to them you can write code so fast / solid.

I haven't bothered with anything beyond hooks, so maybe that's why I'm content.

Exactly. React made composing components natural. Hooks made composing state and logic natural. For all its faults React deserves a lot more credit for this. Really the ideas behind hooks need a new language to make them shine and this compiler is a step in that direction.

I explored using TSX in a non-React way and have been quite proud of my results [0]. I mostly understand hooks and I get why they went that direction, but I swapped hooks for RxJS Observables in my library. I know for some developers they are just as hard to "understand" as hooks, but no one has ever accused Observables of being "magic", at least. Observables end up looking like hooks in basic component examples, but then you can pull them out and reason with them very easily in "view models". In some ways my library feels more like the early days of React when React was just a library, but with some modern benefits.

[0] https://worldmaker.net/butterfloat/

That's a great library! Looking forward to use it in some personal project.

In a React-based project, I managed to use RxJS through react-rxjs[0] to manage events and state. Thanks to it, I was able to fully streamline state management in that project.

[0] https://react-rxjs.org/

This sounds very similar to the development of my project. Basically every word of that could apply to https://mutraction.dev/

Observables aren't magic. They're just shit.

I used to really think hooks were crazy, but now I see them as a reasonable way to write a “DSL”. They are very nice from the viewpoint of reuse and software composition. I have even implemented things in Python that work like hooks.

React does let you do a lot in async, when you are managing the rendering of components something like Suspense could be the right idea but I have a very big application that breaks some of the rules of React but gets away with it and I don’t know how it will do in React 18.

> The JSX idea is gold: introduce XML-like template syntax into the language to avoid need for foreign template language. Make XML templates valid at startup and even with proper types for TypeScript. This is very important advancement compared to text templates which are used everywhere else.

It’s really nice. It started in php as xhp in the late 2000s and was later ported to JavaScript as jsx.

I'm currently building a framework that's essentially "imperative JSX". It sounds like a step backwards but I built a todo app last night with it and I really like the model I came up with. It resolves virtually all of the weird issues with state management in React, because state management is now orthogonal to the render tree.

React Server Components are async/await. Suspense works with async/await to show loading indicators (it is not a replacement as you are implying). They said they have plans to bring async await to Client Components but they need the AsyncContext tc39 proposal to come to JS first.

The worst part of react is all the FUD hacker news creates about it every time they try to innovate to make the web's defacto framework better.

Async/await and suspend are not at all comparable.

If anyone likes the idea of JSX but with python, checkout

https://pixyverse.dev

Hooks solve the problem of composing lifecycle effects. How would you do it without a hook-like pattern?

Is Preact a fine alternative if all you’re after is JSX and declarative UI?

Preact is an excellent alternative to React that keeps things minimal, understandable, and fast.

You must be ready to build a lot yourself. As nontrivial as can be.

One radical lightweight alternative to React is Svelte

https://svelte.dev/

which is completely dependent on a compiler since it bakes in all of the updating logic at that stage. I haven't done big projects with it but for little projects I have been amazed at the speed and the small size of the bundles.

> They just don't care about JavaScript.

Good. JavaScript sucks.

Reply on news.ycombinator.com