5 ms·

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 s

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.

pininja 2y ago
Is Preact a fine alternative if all you’re after is JSX and declarative UI?
- Maxatar 2y ago
  Preact is an excellent alternative to React that keeps things minimal, understandable, and fast.
  - threatofrain 2y ago
    You must be ready to build a lot yourself. As nontrivial as can be.
    - PaulHoule 2y ago
      One radical lightweight alternative to React is Svelte https://svelte.dev/ 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.
robertoandred 2y ago
Async/await and suspend are not at all comparable.
terandle 2y ago
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.
PaulHoule 2y ago
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.
WorldMaker 2y ago
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/ https://worldmaker.net/butterfloat/
- jysh 2y ago
  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/ https://react-rxjs.org/
- recursive 2y ago
  This sounds very similar to the development of my project. Basically every word of that could apply to https://mutraction.dev/ https://mutraction.dev/
- wetpaws 2y ago
  [dead]
- mark38848 2y ago
  Observables aren't magic. They're just shit.
throwAGIway 2y ago
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.
- moritzwarhier 2y ago
  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.
  - acemarke 2y ago
    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).
danielvaughn 2y ago
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.
rafark 2y ago
> 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.
satvikpendem 2y ago
Hooks solve the problem of composing lifecycle effects. How would you do it without a hook-like pattern?
diob 2y ago
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.
- cageface 2y ago
  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.
sunshinerag 2y ago
If anyone likes the idea of JSX but with python, checkout https://pixyverse.dev https://pixyverse.dev
otabdeveloper4 2y ago
> They just don't care about JavaScript. Good. JavaScript sucks.

pininja 2y ago

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

Maxatar 2y ago
Preact is an excellent alternative to React that keeps things minimal, understandable, and fast.
- threatofrain 2y ago
  You must be ready to build a lot yourself. As nontrivial as can be.
  - PaulHoule 2y ago
    One radical lightweight alternative to React is Svelte https://svelte.dev/ 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.

robertoandred 2y ago

Async/await and suspend are not at all comparable.

terandle 2y ago

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.

PaulHoule 2y ago

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.

WorldMaker 2y ago

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/ https://worldmaker.net/butterfloat/

jysh 2y ago
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/ https://react-rxjs.org/
recursive 2y ago
This sounds very similar to the development of my project. Basically every word of that could apply to https://mutraction.dev/ https://mutraction.dev/
wetpaws 2y ago
[dead]
mark38848 2y ago
Observables aren't magic. They're just shit.

throwAGIway 2y ago

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.

moritzwarhier 2y ago
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.
- acemarke 2y ago
  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).

danielvaughn 2y ago

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.

rafark 2y ago

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

satvikpendem 2y ago

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

diob 2y ago

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.

cageface 2y ago
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.

sunshinerag 2y ago

If anyone likes the idea of JSX but with python, checkout https://pixyverse.dev https://pixyverse.dev

otabdeveloper4 2y ago

> They just don't care about JavaScript. Good. JavaScript sucks.