For some reason, I see people in this thread whom I believe don't really understand why hooks were invented. Put simply, just like closures hold state in a function, hooks compartmentalize the component's lifecycle, they are basically `function(state, lifecycle)`. I linked to a Flutter thread elsewhere (on the topic of adding hook-like constructs to Flutter as well) that I've seen as one of the best examples of why class components simply cannot replicate the effects of hooks, due to the inherent limitations of classes [0].
The author uses an example of needing to initialize and dispose of a variable, and you must do this manually each time, for each variable. With a hook, you can abstract this behavior and say, given this lifecycle, I need this variable to be automatically initialized and disposed at the correct time. I write it once, and don't have to think about doing it manually anymore. Hooks are an abstraction over lifecycles, just as functions and loops are an abstraction over repeated procedures.
I am certain your comment was well intentioned, but it is quite striking how frequently the you are arguing against it, so clearly you must be an idiot defense pops up any time someone criticizes React[0].
> One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons.
There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level. People complain about observers, or transpiling being too magical, but at least those are straightforward in principle. I can see Rich's video on how svelte works and more or less get it, it's just that it happens implicitly. Semantic value here would depend entirely on the data type; I have no effective way of being sure of what is being implicitly generated.
> There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level
As far as I understand that quote, it's just about "reference equality" vs "value equality", something most programmers deal with often but maybe frontend programmers aren't used to it? Not sure why the quote doesn't include that naming for it, maybe it would help people connect it to concepts they already understand.
FWIW, I also think React has gotten to complicated and bloated, but I've been thinking that since hooks were introduced if not before, and mainly use React indirectly via Reagent, not directly.
I don't think React is approachable. It is just the most popular framework and has the biggest ecosystem, that is why it is used. Otherwise it is just not good in my view compares to others.
Also I don't think useMemo or useCallback were a reasonable compromise ever.
My initial reaction to a Tweet from Andrew Clark on the upcoming compiler motivated me to write[0]:
React is the new IBM: you should learn it, you should understand its faults, you should probably still deploy it. You’ll never get fired for picking it, but it’s going to be expensive, bloated, difficult to get right, and it’s going to be joyless implementing it every step of the way. React is “the status quo mindset — the biggest enemy of pure innovation”.
I think the project has completely gone off of the rails and is now going through these cycles of self-inflicted complexity only to be solved several releases later with additional complexity. All the while, not really addressing the core issues that affect DX and ergonomics.
It became the most popular in the landscape where all kinds of other frameworks existed. Because nothing beats immediate-mode-style API in terms of code clarity.
It’s getting harder to keep track of all the shiny new features. UI devs already deal with TS->JS compiler, tailwind compiler just to name two. Can’t imagine adding another compiler to the mix. Our already complex and fragile build pipelines just keep getting worse.
I understand the problems in scaling UI development. Just don’t think the solution is to build another layer of complexity atop the shaking foundation.
> Just don’t think the solution is to build another layer of complexity atop the shaking foundation
Why would we try to solve UI development issues any different than other parts of the stack? Building layers on top of shaky foundations is a true and tested approach in computer science and seemingly the only way to move forward somewhat.
All these features sound interesting in isolation, but I can't help thinking that react is stuck on the same treadmill its been on for years.
They keep solving important problems like memorization bugs, but these problems are all self inflicted. The API keeps getting more complex, and with a goal of backwards compatibility everything is additive.
Actions as a generic concept look interesting, but the idea of having every library expose both onSubmit and submitAction is just going to make things more confusing. I guess you use events for old code, and actions when you want the option to send the event to the server depending on the "use server" directive or pragma? And when the next thing comes along, I guess every library exposes 3 different ways to handle a form submit event?
Lots of valid points about the increase in complexity for React over the years, and that one should pick another more modern tech stack (Svelte, Solid, html, whatever), and I used to be thinking like that
But since maybe 1-2 years, I am back and betting on React for most of my serious projects (for the ecosystem, the ease of hiring, etc), but the most important point is the following:
React backwards compatibility is really good, and will stay so for a good reason: a LOT of Meta’s UI code is using old features (classes syntax etc), and Meta cannot afford to break those. If there are breaking changes, they must be “codemodable” (so, usable by everyone).
Meaning in terms of stability, I know my codebase today will still work fine in years ( or upgrade-able with minimal efforts). Of course there will be new shiny features, but I or my team will not have to rewrite old code all the time following tedious migration guides.
disclaimer: I am kind of biased as I work at Meta, but far from React.
I like about Vue that everything feels straightforward and if fits in my head. In other words I think it's powerful and at the same time simple. It had only once a big change, and even then it was very easy to understand. If you knew the options api, the composition api was very easy to understand.
Maybe Svelte is also like Vue, I haven't tried it. I've heard many react horror stories but I've never used it, so I don't know how true they are.
+1 for mobX. Dead straightforward, does one thing and does it well. Only worry is that it increasingly feels like an outsider in React. I'm working on an app that uses React, web components and mobX, and upgrading to React 18's concurrent rendering breaks stuff, and I'm not sure which of my relatively niche technologies (mobX or WC or maybe the interaction of the 2?) causes it.
Preact has been looking increasingly attractive as a library that does its own thing and nothing more. Anyone knows if preact signals are basically a drop in replacement for mobX?
MobX is how you get spaghetti code and state changes everywhere. That is why we (our company) moved away from the observer pattern that MobX and RxJS use.
Can anyone clarify how the compiler would fit into the workflow? Are we talking some kind of CLI that takes a JSX/TSX entry point as input and outputs a compiled JS bundle, like a replacement for Webpack/Rollup etc. but more specialised to optimise React code? Or something more fine-grained that operates on a single component/module at a time? Or something else?
Learning about the auto-memoization feature when it was called React Forget made it seem like a pretty natural extension of the functional component paradigm - separating out and memo’ing parts within components based on info that’s trivially available at compile time (maybe not trivial, I’m not sure how much work is being done by the compiler here).
Is this something that could be implemented as a language-level feature for some “dedicated” language for writing functional reactive UIs? Languages like ReasonML are meant to map more nicely to React’s model because of their expressiveness, but I wonder if it could be taken further.
For crossplatform mobile development, the only viable solutions in 2024 are React and Flutter, and the former has a wide ecosystem already while the latter uses a programming language, framework, and ecosystem only used in that particular use case.
The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.
> The goal behind "hooks" was to make React simpler for beginners
No, it had nothing to do with making it "simpler for beginners." It was to functionalize state changes in a way that was impossible with classes and other OOP constructs like mixins. There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]. What people don't get about hooks is that they are an abstraction over state and app lifecycle changes. It is better to think of them as akin to closures but over lifecycles, not just holding state as closures do.
I've seen this criticism several times on HN, but have never been able to relate to it.
I've been using hooks since they were introduced, in several teams (at several different companies), and I've never experienced them being complicated to understand, either for myself, or for team mates - even juniors who are new to React. In my experience, it takes very little time (<1 hour) to understand the basics of React, and once you have that mental model in place, hooks fit in immediately.
I wonder if it's the case that many people on HN are just used to some completely different libraries and thus are coming in to React with a completely different mental model? And that's the cause of this sentiment being so common here.
I'm building frontend apps since 2012. I did not like hooks but ok fine. But NextJS seamed to became the default way of building React apps. I could never grasp how people in twitter and everywhere seemed to be fine with all this complexity it brought. All of this for reducing some milliseconds in load times? How can this be the default? With create-react-app you could just compile your app and host it at S3 with CDN for pennies. With NextJS you can do static site but you have to be aware of several gotchas. It seems like made up problem and solution to make return for the VC money, what am I missing?
I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.
> The goal behind "hooks" was to make React simpler for beginners.
What makes you think this was the goal? React team has been trying to get rid of 'this' for a long time; I believe I saw someone say that it had some undesirable consequences for the fiber architecture and for the "concurrent mode" that eventually was transformed into a set of concurrent features. Alternatively, it is possible that they wanted a better reactivity model than the one based on component's lifecycle. Why does this necessarily have to be simpler for beginners?
I have a similar experience to yours. I'm using preact for most things now, sveltekit for anything full-stack or when I need static generation (great fro small/mid-sized projects, haven't build anything "enterprise" with it).
I wish Remix was preact. It looks like it has parts of preact and svelte I really enjoy.
I've been using Next.js since 2016/17 at small and large SaaS scale) -- I feel like they're building it like a VS funded SaaS now. The added complexity doesn't really pay off.
I have made hard decisions to fully return to vuejs for a few months, much simpler.React has lost itself totally thanks to vercel/next.js who hijacked oss projects for its short gain with VC's money.
If you look at their incentives differently, i would argue they doing well with their goals. Every "use server" is another vercel customer. Every preact user finds it harder to claim they are using react when apis showing up in react canary and being documented for nextjs don't exist for them.
Same realization. I started playing around with Rails/Hotwire and found that to be much more productive and far simpler. Haven’t used it for anything “real” yet, but I am enjoying it so far.
I couldn't agree with you more, but sadly the amount of inertia around React makes it very difficult to ignore or supplant. Especially if you're in the business of providing any kind of developer tooling.
The project I'm most excited about in recent years is htmx. Sadly I've yet to have the opportunity to work on any real projects with it. Some day, fingers crossed!
A lot of throwaway accounts on here recommending people switch to vue in 2024.
At least for now, I don't see any urgency to switch from React. There's more React developers than Vue, Angular, Svelte, htmx, and Solid combined. React is not quite as ergonomic as Vue or Svelte, but all are swiftly approaching feature parity.
Vue and Sevlte don't seem to represent a big enough boost in productivity to justify rewriting an entire generation of codebases.
To latch onto this comment; never switch an application's primary framework for the sake of switching. Consider other things, like time spent maintaining, hiring, training and onboarding required, support, etc.
Anecdote, we switched to React Native from a thing called Nativescript, primarily motivated by the dwindling development and support, and the huge overhead that Nativescript brought.
But I have to hold my hand up and say I didn't like Angular and the redux-style beating around the bush either.
React was closer to elm during the times of stateless functions and redux. Since then it's getting further apart from elm.
Redux was kinda of a poor man's elm but it got the right principles. However the JS community hates boilerplate code so, new, more complicated abstractions appeared. Also, it was too easy, with redux, to shoot yourself in the foot.
Since then, with hooks, things are just getting harder and more complicated in my opinion.
[+] [-] satvikpendem|2 years ago|reply
The author uses an example of needing to initialize and dispose of a variable, and you must do this manually each time, for each variable. With a hook, you can abstract this behavior and say, given this lifecycle, I need this variable to be automatically initialized and disposed at the correct time. I write it once, and don't have to think about doing it manually anymore. Hooks are an abstraction over lifecycles, just as functions and loops are an abstraction over repeated procedures.
[0] https://github.com/flutter/flutter/issues/51752
[+] [-] cooperadymas|2 years ago|reply
[0] https://news.ycombinator.com/item?id=35278169
[+] [-] preommr|2 years ago|reply
There's got to be another word for 'magic' to describe this kind of behavior because this is on a whole other level. People complain about observers, or transpiling being too magical, but at least those are straightforward in principle. I can see Rich's video on how svelte works and more or less get it, it's just that it happens implicitly. Semantic value here would depend entirely on the data type; I have no effective way of being sure of what is being implicitly generated.
[+] [-] diggan|2 years ago|reply
As far as I understand that quote, it's just about "reference equality" vs "value equality", something most programmers deal with often but maybe frontend programmers aren't used to it? Not sure why the quote doesn't include that naming for it, maybe it would help people connect it to concepts they already understand.
FWIW, I also think React has gotten to complicated and bloated, but I've been thinking that since hooks were introduced if not before, and mainly use React indirectly via Reagent, not directly.
[+] [-] mewpmewp2|2 years ago|reply
Also I don't think useMemo or useCallback were a reasonable compromise ever.
[+] [-] CharlieDigital|2 years ago|reply
React is the new IBM.
[0] https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/
[+] [-] sesm|2 years ago|reply
[+] [-] Already__Taken|2 years ago|reply
now it seems the magic Vue had has gotten better, and was copied over but worse to react.
if react can fix it by compiling it away, cool. but fixing computer bugs is even less approachable than webpack.
[+] [-] Karupan|2 years ago|reply
I understand the problems in scaling UI development. Just don’t think the solution is to build another layer of complexity atop the shaking foundation.
[+] [-] diggan|2 years ago|reply
Why would we try to solve UI development issues any different than other parts of the stack? Building layers on top of shaky foundations is a true and tested approach in computer science and seemingly the only way to move forward somewhat.
[+] [-] _heimdall|2 years ago|reply
They keep solving important problems like memorization bugs, but these problems are all self inflicted. The API keeps getting more complex, and with a goal of backwards compatibility everything is additive.
Actions as a generic concept look interesting, but the idea of having every library expose both onSubmit and submitAction is just going to make things more confusing. I guess you use events for old code, and actions when you want the option to send the event to the server depending on the "use server" directive or pragma? And when the next thing comes along, I guess every library exposes 3 different ways to handle a form submit event?
[+] [-] martpie|2 years ago|reply
But since maybe 1-2 years, I am back and betting on React for most of my serious projects (for the ecosystem, the ease of hiring, etc), but the most important point is the following:
React backwards compatibility is really good, and will stay so for a good reason: a LOT of Meta’s UI code is using old features (classes syntax etc), and Meta cannot afford to break those. If there are breaking changes, they must be “codemodable” (so, usable by everyone).
Meaning in terms of stability, I know my codebase today will still work fine in years ( or upgrade-able with minimal efforts). Of course there will be new shiny features, but I or my team will not have to rewrite old code all the time following tedious migration guides.
disclaimer: I am kind of biased as I work at Meta, but far from React.
[+] [-] gardnr|2 years ago|reply
[+] [-] argentinian|2 years ago|reply
Maybe Svelte is also like Vue, I haven't tried it. I've heard many react horror stories but I've never used it, so I don't know how true they are.
[+] [-] Rapzid|2 years ago|reply
No compiler necessary.
If React created better extension points for pluggable reactivity we wouldn't even need observer() wrappers. This is all getting kinda bonkers.
[+] [-] sesm|2 years ago|reply
[+] [-] CornCobs|2 years ago|reply
Preact has been looking increasingly attractive as a library that does its own thing and nothing more. Anyone knows if preact signals are basically a drop in replacement for mobX?
[+] [-] satvikpendem|2 years ago|reply
[+] [-] cal85|2 years ago|reply
[+] [-] RayVR|2 years ago|reply
[+] [-] udbhavs|2 years ago|reply
[+] [-] throwaway2990|2 years ago|reply
Why anyone would start a project with react in 2024 be beyond me.
[+] [-] Cthulhu_|2 years ago|reply
[+] [-] throwaway220033|2 years ago|reply
[+] [-] satvikpendem|2 years ago|reply
No, it had nothing to do with making it "simpler for beginners." It was to functionalize state changes in a way that was impossible with classes and other OOP constructs like mixins. There is actually a great issue thread on the Flutter GitHub that explains exactly why other solutions do not work correctly when compared to hooks [0]. What people don't get about hooks is that they are an abstraction over state and app lifecycle changes. It is better to think of them as akin to closures but over lifecycles, not just holding state as closures do.
[0] https://github.com/flutter/flutter/issues/51752
[+] [-] sunaurus|2 years ago|reply
I've been using hooks since they were introduced, in several teams (at several different companies), and I've never experienced them being complicated to understand, either for myself, or for team mates - even juniors who are new to React. In my experience, it takes very little time (<1 hour) to understand the basics of React, and once you have that mental model in place, hooks fit in immediately.
I wonder if it's the case that many people on HN are just used to some completely different libraries and thus are coming in to React with a completely different mental model? And that's the cause of this sentiment being so common here.
[+] [-] throwaway257ash|2 years ago|reply
[+] [-] slmjkdbtl|2 years ago|reply
[+] [-] azangru|2 years ago|reply
What makes you think this was the goal? React team has been trying to get rid of 'this' for a long time; I believe I saw someone say that it had some undesirable consequences for the fiber architecture and for the "concurrent mode" that eventually was transformed into a set of concurrent features. Alternatively, it is possible that they wanted a better reactivity model than the one based on component's lifecycle. Why does this necessarily have to be simpler for beginners?
[+] [-] iamflimflam1|2 years ago|reply
Even knowing why they are needed requires a deep understanding of what is happening.
Definitely feels like complex implementation details leaking upwards and influencing the public API.
[+] [-] rpastuszak|2 years ago|reply
I wish Remix was preact. It looks like it has parts of preact and svelte I really enjoy.
I've been using Next.js since 2016/17 at small and large SaaS scale) -- I feel like they're building it like a VS funded SaaS now. The added complexity doesn't really pay off.
[+] [-] synergy20|2 years ago|reply
[+] [-] technion|2 years ago|reply
[+] [-] revscat|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] mstade|2 years ago|reply
The project I'm most excited about in recent years is htmx. Sadly I've yet to have the opportunity to work on any real projects with it. Some day, fingers crossed!
[+] [-] lairv|2 years ago|reply
[+] [-] JackMorgan|2 years ago|reply
At least for now, I don't see any urgency to switch from React. There's more React developers than Vue, Angular, Svelte, htmx, and Solid combined. React is not quite as ergonomic as Vue or Svelte, but all are swiftly approaching feature parity.
Vue and Sevlte don't seem to represent a big enough boost in productivity to justify rewriting an entire generation of codebases.
[+] [-] Cthulhu_|2 years ago|reply
Anecdote, we switched to React Native from a thing called Nativescript, primarily motivated by the dwindling development and support, and the huge overhead that Nativescript brought.
But I have to hold my hand up and say I didn't like Angular and the redux-style beating around the bush either.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] hyfgfh|2 years ago|reply
[+] [-] omeid2|2 years ago|reply
https://elm-lang.org/
[+] [-] Couto|2 years ago|reply
Redux was kinda of a poor man's elm but it got the right principles. However the JS community hates boilerplate code so, new, more complicated abstractions appeared. Also, it was too easy, with redux, to shoot yourself in the foot.
Since then, with hooks, things are just getting harder and more complicated in my opinion.
[+] [-] codethief|2 years ago|reply
[+] [-] mrcino|2 years ago|reply
[+] [-] nesarkvechnep|2 years ago|reply
[+] [-] geobourazanas|2 years ago|reply
[deleted]
[+] [-] madmaniak|2 years ago|reply