I feel sorry though for someone getting into frontend dev now.
> is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.
I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?
EDIT: React is still an exceptional framework and this release is certainly an improvement.
My criticism is more FE development in general not just React.
It sounds bad, but if you can, do oldschool SSR with HTMX or the like.
It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better.
There are less bugs, less footguns with wrongly applied hooks...
If you need to do CSR, use Solid or Vue, but don't do React.
If you have no say in it: good luck!
Do you mean the whole field, so from B2B SPA apps to personal blogs? "If you want to replace jquery, use Vue!" would be more helpful to understand.
The problem is that we don´t know if the advice comes from a "bootcamper" that has only learned Javascript. You know, some people manage to build low-interaction sites that will render a blank page when Javascript is disabled.
The "why" is also of interest to see if the advice is applicable. If not react, then why not preact for instance?
eg: <todo-list><%for...><todo-item .../></for%></todo-list>
I've poked at `lit`, read through `htmx`, but really what I want is "custom elements" (including visual styling) on the front-end that I can map back to JSON on the backend.
The CSS side nudges towards tailwind (or similar), and modern (raw) CSS has undergone so many feature extensions and new capabilities, it's tough to find a good "modern" guide for building with it.
It just feels like there's a missing piece in-between: `let contact = new LdapContact(...)` and `<contact-summary .../> ; <contact-detail .../> ; <contact-search-result .../>`.
Vue has come closest, and setting aside a super-complicated "WebApp/SPA" with a ton of interactivity... what's a comfortable, modern, low-ceremony way to get to that?
Easier said than done.
There're still many high quality libs for React that are not available for vanilla JS or other frameworks. E.g. https://reactflow.dev/ (yes, they have a Svelte version, but not as feature rich).
Vue comes very close, though.
Avoiding the most popular front-end tech (or any tech) is a good tip for those who want to play Finding a Job in hard mode.
Being mindful of the never-ending-nirvana frontend spirit of churn, and after doing web development in VBScript, JS, JQuery, Mootools, Applets, Actionscript, YUI/Ext/Sencha, Backbone, Knockout, Angular1, Angular2, React, Vue1 – I'd say try Flutter. It's genuinely a breath of fresh air.
Except... Dart. If only Flutter was in Typescript it might have been a bit closer to nirvana. The Dart part is still keeping the frontend spirit of churn alive.
It's an interactive business analytics, one of those use cases where an SPA makes sense — 15 years ago it would have been a native desktop application.
We just follow the usual guidelines, no extraordinary optimization techniques or anything like that.
The main issue is React forces you to tell it which components to re-render. This causes a bloat of ceremony that makes it endlessly annoying (in comparison to global redraws) to write in.
I most certainly don’t.
As someone who has mostly done low level coding and used to generally dislike my few interactions with web frontend development, I was extremely surprised when I picked up React a few years ago for a personal project.
The whole thing feels like actual proper development. What a breath of fresh air compared to the situation before.
In professional projects with teams of developers contributing and PMs wanting feature flags, tracing, complex behavioral logic, it gets crazy.
Easy: By not using that optional feature.
If you’re like 99% of developers you really don’t need stuff like that until your app reaches a certain stage of growth, if ever - and React doesn’t force it on you.
> asyncio.as_completed() now returns an object that is both an asynchronous iterator and a plain iterator of awaitables. The awaitables yielded by asynchronous iteration include original task or future objects that were passed in, making it easier to associate results with the tasks being completed. (Contributed by Justin Arthur in gh-77714.)
"I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing python scripts today, how do you even start?"
Have you tried using v0 to generate a layout and a barebones application? It saves so much time. No more hunting for templates/themes, no more mocking.
But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions.
My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life.
Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.
Even the reference section of the site makes clear how far down the priority list the advanced hooks are.
My response has been to avoid SPAs as much as possible. YAGNI! Just use boring forms and server responses. Some component libraries can be server-rendered, minimizing the JS payload while giving you some primitives to build off of. Components are a really nice abstraction even in a pure server context. You can contain the goopy Tailwind code a bit.
It's not all bad. Astro seems pretty nice so far!
Why would that be true? Often people don’t know what they need to solve a particular problem.
You learn vanilla HTML/CSS/JS (I think Mozilla has good courses on those). After making a few websites that way, you learn Svelte and you live happily ever after.
Avoid React, NextJS at all cost especially since many of these new frameworks actively try to screw over new developers with PaaS.
I think React peaked with hooks around 2019. I write most of my front-end with the smallest 'React-like' library possible (Preact) using only functional components, and with as little 'magic' from useEffect etc. as possible.
I like to stay close to 'raw' HTML/CSS/JS when possible, but the web platform APIs are just a little to clunky and verbose for me without the JSX abstraction.
I don’t get how people get so paralyzed of making the most optimal decisions all the time that they end up doing nothing or procrastinating by convincing themselves they need to learn some other basic framework instead.
One mark of a framework with a future is that it supports its past. A framework with a lot of breaking changes is one that is not mature, and may never be mature.
Even with the substantial shift in React from classes to functions and hooks, old code still works. You probably don't want to start writing class-based React, so you want a tutorial written in the last 5 years, but those are hardly new and certainly not specific to React 19.
Getting started with Vue was so much easier, I never looked back to React.
I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess.
Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples
So you google how to use that library, but the learning resources assume knowledge of a different library...
When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon
As far as I know this usage ultimately derives from HTML `<form action={}>`.
With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework.
I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.
You'd slap together a Jenkins/Jekyll site and host it on github for free. It's easier now to set up a website than ever. But yeah that React sentence is pretty difficult to gronk.
You start where the docs say to start, https://react.dev/learn which wouldn't be mentioning this advanced feature, just like pretty much any tech. Reading postgres, python, etc release notes will have a bunch of scary sounding new features to a beginner, but those won't be making their way into the "Get started" section
It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps.
Not with React?
Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
The model they've chosen is the opposite of what one would intuit and because of this model, it is necessary to manage state a bit differently in React compared to Vue or Svelte.
Probably with something simpler like Alpine.js, or even JQuery. No beginner is going to be building the kind of web app that requires such a heavyweight framework like React. Don't bother with it until you know you need it.
The quality expected of apps over the last 20 years has skyrocketed, and the tools to handle those requirements have gotten increasingly complex.
https://react.dev/blog/2024/10/21/react-compiler-beta-releas...
That said, it doesn't change the APIs included in React itself, or the overall usage patterns. Ultimately it rewrites your component code to add a lot of conditional comparisons to see if props or state values changed, and uses that to trigger React's existing rendering optimization behaviors.
Long-term, I expect that the React Compiler _will_ result in a significant change in the DX for using React. React's default behavior has always been "re-render recursively regardless of props changes" [0], but people often assume it's "only re-render the child if the props changed". React Compiler actually makes flips React's default behavior to make that a reality.
[0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
When not, I focus on backend and devops instead.
Although some SaaS products make our life harder, with React only SDKs.
Yeah. For the last decade or so frontend has felt like standing on shifting sands.
In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going...
"the DOM is slow we need a VDOM!"
"the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!"
"oh wait but we now need a compiler!"
"oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!"
"maybe full page hydration wasn't such a good idea... we now need islands!"
Etc.
Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.
No, it is not. Your criticism is very specific to React.
React is unbelievably overengineered, classic case of creating solutions to self-invented problems.
Weren't jetpack compose and swift UI inspired by React? I saw it somewhere in the android docs and now its probably deleted, I can't find it anymore.
But then again, I don't have "decade" of experience in tech, yet. I have no idea if building huge web apps (i.e airbnb) using jquery or plain js with large teams is as enjoyable back then? My thought process is changed, I can't even think on how to solve the state management, dom manipulation, side effects etc with plain js anymore.
Nowadays I just built on what I'm familiar with and focus on what I want to build. who knows, maybe in the future I will also complaint about new frameworks and mention how good React was :)
I've interacted with a not insignificant number of people who seem to hold this opinion. Usually their arguments boil down to one of:
* Frontend engineering is always chasing the next shiny thing, and react is one of them. There's probably some truth to this historically, but react has been a thing since 2013, and pretty 'mainstream' since 2015 or so.
* Frameworks and libraries add 'complexity'. I almost never hear anything specific when I ask about what complexity they're referring to. IMO if you work on a non trivial application without a framework, you'll just end up inventing your own poorly maintained, poorly tested and poorly documented framework. This might be fine for a weekend project, but rarely something you should do at a company.
* People also often complain about the compilation/bundling step. This might've been harder to manage historically, but now with battle tested frameworks like expo, nextjs, meteor etc, there are very few reasons to write a webpack configuration or build pipeline by hand.
In defence of the haters, I think we’ve all seen our share of horrendously organized React SPAs. Dependency hell, (seemingly) infinite prop drilling, components thousands of lines long, the list goes on.
Some people think they hate React, when in reality they hate a specific implementation of it.
The hoops I have to jump through to get the back button working.
Same for people that have never used Angular, or only used the old AngularJS 1.x
I have more experience with Angular, but I don't hate any of the other frameworks, I've built apps with React, Svelte and tried out Vue.
The trend to shove web frameworks into everything has ushered in a nightmarish decade of slow, dysfunctional websites, that - despite being over-engineered to high heaven - hardly deliver an improved user experience compared to what we had in 2008.
There's a class of frontend dev for whom - no matter the question - the answer is always some unholy combination of React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit / etc - preferably running across two dozen Docker swarms, ruled by the Red Queen (kubernetes). "Oh, you want to put your CV online? Sure, let's spend the next three weeks plotting out the state flow diagram for your 'app'... "
The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess. The same fate awaits the rest of the frameworks, in time.
Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.
Incurred a bill of $800, and reached out to me. Gobsmacked!!
I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.
It's the apps with unique requirements that need to be coded, not some pages that present some info in some way that's slightly different, stylistically, and not standard at all.
- How things actually work are very hidden and unintuitive
- Very easy to make mistakes, easy to write low performance UI
- High cognitive load, constantly thinking about how many times things run, what's in dependency arrays, what should go in useCallbacks and useEffect etc
- Overused, part of community sometimes encourage people to use React and some dependencies that's unnecessary for the project, only adding overhead and complexity
- Easy to mix business logic with UI logic
I work with mobx at work which just does a better job of letting us focus on business logic. Components observe computed models directly, no prop drilling, no context. The `createTransformer` map function is the key to mapping dynamic collections to computed models, handles GC in cases where you want to go from computed model to another computed model so you don't manage a bunch of WeakMaps yourself.
The React maintainers and community buy into complexity too readily. Probably why SolidJS (which unlike mobx also provides the view layer) is gaining traction.
https://overreacted.io/making-setinterval-declarative-with-r...
I agree with this. Luckily there's some work being done on this - check out the new React Compiler[1]
> what's in dependency arrays, what should go in useCallbacks and useEffect
This lint plugin[2] from the react team helps quite a bit with this
[1] https://react.dev/learn/react-compiler [2] https://github.com/facebook/react/tree/main/packages/eslint-...
A lot of us complained, very vocally, about how bad MongoDB was.
So yeah nothing wrong with the concept of react, just the usual and terrible javascript ecosystem churn with stuff we don't need, but now everyone will have to update and so do we. Nice if you have a dedicated frontend team for every of your apps, not so nice for a small team that has to manage many apps across many clients.
I like major (potentially) compatibility breaking updates every 10 years or so, not every 3 weeks.
So yeah, we went off react to vanilla js, htmx and liveview type stuff which makes this all far simpler. Dev is also far simpler for us; all the pitfalls are no longer there. There might be some advantages to react in some cases; we won't look back; we never had a more relaxed team especially since we ditched nextjs and react; the trying out of other tech for frontend made us realize react was wrong for us all along anyway. ymmv of course.
I don't think that there are many good options for front end that are maximally stable out there:
https://endoflife.date/angular
Unless you want to look at something way more niche, you probably won't find something that has a main version supported for 5-10 years without major changes. Then again, that's usually not even the case with back end frameworks either, the closest you can get is either language runtimes like JDK (2014-2030, albeit the open source versions seem to end support in 2026), or maybe OSes like RHEL (e.g. 8 has a support timeframe of 2019-2029 or the extended option is until 2032).
In short, there is churn everywhere and I don't think you can simply pick any stack that is used for web development and will get exposed to the world (and therefore needs security patches), that will still work okay with no breaking changes along the way in 5-10 years or so. The only difference is how bad the individual choices will be.
as for why I personally choose React was due to the job market, community support, debugging exp, TS support, and JSX just felt much more natural to me. I don't go everywhere hating other frameworks though. I think its good that we're tackling the same problem with different solutions, we have more choices.
Also react uses (or promotes) web-hostile anti-features like document level event handling and virtual scrolling, which are PITA from a devtools tinkerer perspective.
useActionState: is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.
Delusional gobbledygook.
Could you elaborate on this? I'm not sure what an "async meta higher effect" is.
Reading in between the lines though, I suspect you're talking about state management. You might benefit from one of many state management solutions out there - redux, mobx, legend-state etc. Keeping and passing around local state spread out across lots of components can get unwieldy pretty quickly.
But I try to stay away from it at work and I would rather push Vue 3.
There's few reasons:
- React does not really have a framework as good as Nuxt, which is light years ahead of the terrible mess of Next, and much more solid than Remix (which oddly comes also out with questionable stuff baked in)
- React is easy and funny to learn, but it's tough to master properly when it comes to few several key aspects like..There could be a PhD in hooks complexity, and all of that to avoid using class based lifecycle which was uglier but...much easier to manage
- Performance. It's just not good as on alternatives. At some point you scale, SEO and performance matter, React bites you back. There's many issues I could list from server to client side rendering and this will never be fixed due to how React's rendering works. Not only that but on React alternatives like Nuxt you end up thinking about performance way later
- DX on aspects like styling. I've tried everything and the DX of authoring and maintaining the style of react components is just meh
SPAs might be a good idea even for simple / low traffic apps, if you don't want to write and maintain a backend. SPAs are easy to statically host on a CDN. They don't technically "run" 24/7, they can't "go down" unless the CDN does. They can use a serverless platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc. If you want to prototype, it makes much more sense to write a SPA.
It's not a pleasure to work with.
I know quite a few programming languages, ~20 years of software development career. And React is the worst tech.
Don't get me wrong, but I wrote a lot of React code at work, and used it for personal projects (for example: make210.com)
But every time you touch React you're getting this distinctive "meh" flavor that tells you - oh yea, baby, it's because you're dealing with React.
When I was doing audio engineering professionally you would find a bunch of engineers who had the same sort of mentality about outboard equipment. Specifically modern outboard which uses switching power supplies and the like in order to reduce power consumption and, ultimately, the cost of the gear.
You can’t help but feel a lot of people feel threatened by advances in technology as their ability to gatekeep diminishes with every iteration. In the audio example you’d no longer have to spend thousands of pounds on a Neve preamp to get a professional sound. You can buy a focusrite interface for a couple hundred and have decent sounding recordings.
Likewise with React/Vercel/NextJS. With those advancements a person (I don’t say dev as the docs make it so most people can fumble their way around) can deploy a simple website in a week or less depending on their personal ability to learn. As such those who made a living overcharging to make a simple site for a local business are seeing their income diminish.
Just my theory, anyway.
And anyway... the weird parts about React are kind of weird... some people just like Svelte more ;)
0. People are coming to React after doing X years of that other thing, which was was not necessary related to user interfaces at all, was not procedural or reactive
1. People are super confused by something reactive and procedural, it feels too "complex" and something messy usually comes out of their fingertips
2. People think what if they sign for React, they automatically sign for react-router react-video-player react-redux react-custom-div-tag react-img and so on, bringing a ton of unnecessary dependencies to the project and crying out loud that this "whole React framework" is too complicated and nuanced
3. People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks, which can solve every user interface problem in an effective way. Instead they watch 10-minute video on 2x speed which tells them to npm react-router, react-redux and react-custom-div-tag
4. People end up with a monster, which makes them cringe every time they are looking at it, and they can never ship it
5. People go and produce a big rant post to spread the hate with the title "How/Why I quit React and went back to Laravel, then finally shipped", sharing it here on HN
React is 10+ years old. Hooks are about five years old. There was react before hooks; and people who hate react don't always do so because they failed to learn the hooks api...
Also, the official react documentation is, predictably, a living document that keeps changing. I guarantee you that when react hooks were introduced in 2019, they were presented as a more convenient alternative to lifecycle methods, with a near-direct correspondence between the component lifecycle methods api and the hooks api. The useEffect hook was presented as a better and more powerful componentDidMount + componentDidUpdate combo. There was no talk of "you might not need an effect", which came out of several conference talks and culminated into a separate article in the docs. The first version of that "you might not need an effect" article appeared, according to github history, in 2022, three years after the early adopters had started using hooks including the useEffect. You were never supposed to update the state during render; now you are. You were always allowed to read component class properties during render; now with useRef, you aren't. And after all these years, react still seems to be in denial that sometimes you want some actions to happen only once over component's lifetime, upon its mounting; and you have to fight with the strongly encouraged StrictMode component for that privilege...
PS: I'm not a frontend engineer but I find this topic interesting.
Thanks!
The one real edge I'll give React is much better Typescript support due to tsx essentially being a superlanguage of TS. Vue's composables are very good, but it falls apart a bit in actual template usage. Tooling is also better, but that's also because it's simply used much more so has had more investment into making the tooling good compared to Volar for Vue.
But in my opinion everything else surrounding Vue makes it superior. Signals are a better state management pattern, there aren't all the insane footguns that React comes with, performance is better out-of-the-box and is practically impossible to fuck up compared to React where it's hilariously easy to make even the simplest of apps be performance monstrosities, the documentation is (IMO, I find React's docs (yes I've seen the new ones) terrible) best-in-class, the gilded libraries like Pinia, Vue Router, VueUse are far superior to anything in the React ecosystem...
I could keep going, but having worked with both more or less equally, I'd choose Vue 10/10 times over React, no questions asked. I can throw a junior at the codebase and be 100% confident they'll make something that's more-or-less idiomatic Vue code, even with the Composition API which is less stringent than the old Options API, whereas with React they'll always need hand holding and I'll always need to explain why things are rerendering twice or running terribly or what useMemo does or what useEffect does (or doesn't) do...
Today, 33% of vue downloads in the last 7 days are for vue 2.
There was a lot of things that were nice in the vue world like vite and vuex, but I'd never recommend vue to anyone, especially anyone that wants a good typescript experience.
here's an example library button using .tsx in vue https://github.com/vuetifyjs/vuetify/blob/master/packages/vu...
I have the exact opposite experience, I find Vue hilariously bad to the point of being repulsive. Now what?
It's harder to do poorly and even when you do, it doesn't punish you the same way that React does.
There are certainly more UI libraries available for React than any other framework [1]. But do you think that these are also clearly better? What would be your go to framework for React? To me, it seems that the trend is going to framework-agnostic or multi-framework libraries anyway (e.g. Ark UI or Zag).
That's doing a *lot* of heavy lifting here. That's like saying "D is infinitely better than C++, except for available libraries".
While my current Electron personal project will probably use Vue because I want to learn it, the change in libraries (and lack of plug-and-play support for whole companies' provided frameworks) is a real barrier to entry for a lot of work.
There are millions of developers happily using react every day. They just don't come onto HN to complain about the "woeful state" of frontend.
const [name, setName] = useState('blastonico')
...
setName('nailer')
let name = 'blastonico'
...
name = 'nailer'
I get that assigning variables is easier to understand, but it's way, way harder to actually scale and maintain. Check out flux architecture.
1. Write some solution with out a UI
2. Decide you want a UI
3. Add React
4. Be forced to re-architect your solution because react wants control of all of your state.
React is supposed to be the V (View) in MVC but it requires full control of the M (model) in MVC and bleeds into the C (controller) as well.
Someone will likely chime in that you can just tell React to re-render the entire UI every frame or write lots of custom functions to monitor your model but that's not really the point. No other UI paradigm requires this.
- design "UI struct" for what you want to display
- Have React fire off events when doing actions
- Those actions get piped into your UI-less solution
- Your UI-less solution updates the "UI struct"
- React updates the parts of the tree that was using part of your struct
if you design this struct in the right way, you can have the updates be _very_ targetted (like, React doing basically no extra work). But your UI struct needs to be really carefully set up so you're not firing things off all over the place.
I think it's still an easier problem than keeping your DOM in sync entirely, but it's unfortunately very easy to accidentally over-render still.
Are you referring to Electron apps or something?
It uses a 500-line router and a 500-line UI component lib.
I once loved client-side frameworks like React.
Then I realized: Great, we managed to add complexity wherever possible. In the backend, in the front-end, in the DevOps stack, EVERYWHERE. And more layers will be introduced to keep all that distributed complexity in sync.
sigh
We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.
First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own.
Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.
Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way?
Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.
Sorry, I have been around the block so many times, there’s now a moat around the block.
Well it wasn’t just ReactJS, the whole JavaScript ecosystem went mad with its libraries and tooling for all these libraries but React was particularly annoying to get started so they built create react app so you can have a hello world app in a reasonable time.
Yeah that just isn't true. No matter how much you want it, the days of html pages with anchor tags and <table> elements centering content are gone.
Move on man.
I stopped hoping for the reason behind changing the class components API to hooks.
Did you? You can always opt for a simpler framework and you can avoid server orchestation. If you are not in the position to choose then you could work on starting your own project if you think you will have a efficiency edge over the rest with your simpler stack.
Sure you can centralize your complexity. But that doesn't necessarily get rid of this.
You can put database queries, business logic, UI interactions, etc all in one place.
With enough front-end complexity, other state managers get in the way more than should. So, to anyone who might be tempted to hate on React, but really has just grown weary of endless walls of action constants, or plumbing props, or fighting nested providers/contexts, or resorting to pub-sub; give something like Jotai a shot.
https://github.com/pmndrs/zustand
https://github.com/pmndrs/valtio
To me it feels like Jotai has too much manual boilerplate and Valtio has a lot of proxy "magic" that while I do like it I don't feel like it would be a good idea for a team. Zustand sits right in the middle of boilerplate-vs-magic, and is what I chose for a large project we're doing now.
I ended up rolling my own solution [1] to escape all that so I could focus on getting things done. It's been working great for me in production. Too bad there's no popular option that works similarly.
For comparison, Valtio has the same kind of "counter" example at the top of their README (first and third code blocks): https://github.com/pmndrs/valtio?tab=readme-ov-file#wrap-you...
As a developer, I value solutions that never fail me. I wasn't driven to Jotai out of good taste. Simplicity and reliability are the benefits I find the most tangible. But Jotai's atomicity brings renderer optimizations as code splitting advantages that I haven't seen from the flux/redux clones before either.
I’ve used it in a largeish project and I liked it a lot.
I rally hope I never have to deal again with redux or sagas
I’d hate to have to deal with incompatible versions at the rate they release major versions.
If you try to stick with one version do you soon get stuck because you need to take a bug fix or security fix that’s only available in a later major release (but updating breaks other things)?
I want to build software on a stable platform so I can spend time on improving the software or writing something new, not keeping up with updates.
React is stable, upgrading it is painless as long as you don’t ignore deprecation warnings. What can be annoying is other (abandoned) dependencies holding you back from upgrading.
Maybe if you have a small app. React is as bad as going from angular to angular 2
- https://macwright.com/2024/01/03/miffed-about-react
(looks like the author may have an HN-specific redirect, so you might need to copy-paste that URL)
const error = await updateName(newName);
- People really like Result structures
- People who wrote the API believe in the "operational issues and business issues should not be comingled" philosophy (so this function might raise on a connection error, but it _won't_ raise when there's simply an error like a name conflict)
- People who wrote the example write Too Much(TM) Go
ref as a prop: Refs can now be used as props, removing the need for forwardRef.However, I'm disappointed (but not surprised, this was listed as out of scope for 19) that triggering Suspense is still basically "use a framework that supports it." I have not been able to find any documentation or blog posts about the mechanism. I've tried to figure out how it works by looking at TanStack Query, but I've had limited success so far. I've found they're copying React's twist on Promises [1], but I haven't gotten this to work yet.
I know the general idea is you throw Promises, but Suspense explicitly forbids using promises created during rendering. This means you can't just interrupt the component's initial render to load some data, and then restart it when its data is available. This means the component needs to deal with null data somehow, instead of, e.g., being able to call a custom `useSomeData` hook and rely on it to first suspend and then return the loaded data. Not having to deal directly with loading states in individual components could simplify things quite a bit.
Has anyone explored this side of Suspense?
[1]: https://github.com/TanStack/query/blob/main/packages/query-c...
- https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i
Big picture as I understand it:
The legacy and always-undocumented-but-everyone-knew-about-it approach was throwing a promise while rendering.
`use` still actually does the same thing, but it also attaches some extra status fields to that promise, _and_ checks to see if you're consistently passing in the _same_ promise reference.
In other words, it's the job of an external data fetching library to keep track of what query entry is being asked for, create and save a promise per cache entry _outside_ of the React component tree, and then return that promise somehow so the app developer can pass it to the `use` hook. In a sense, it's an async `Map`.
As another example of this, my former teammate Brian Vaughn (previously on the React core team) ended up building his own implementation of that behavior in the conveniently-named `suspense` package:
- https://suspense.vercel.app/
Ultimately, the `use` hook and Suspense _does_ do exactly what you're asking for - the rest of the component gets to assume the data _does_ exist, since `use` will only let the execution continue once the promise has resolved.
If you're going to add something to the main project, it should be well-designed, clear, and in good taste. React won over things like Angular because the latter had poorly designed abstractions. It was supposed to be "just javascript" (which was always more of a vibe being actually true).
Just look at wtf actions are. In their blogpost[0], the old way of doing things is only a few lines more, but is much clearer. The 'useTransition' still has to update the error state - but at least it saves you from typing the pending state!
But of course, you're not supposed to use this directly, you're supposed to use useActionState. And this blog post makes it's usage very clear by just returning null to show something that's supposed to update state. So very clear, and intuitive /s
Stuff like this really should've been in a separate library. It baffles my mind that core behavior like state management is left to external solutions, but then random crap like this makes it into the main project.
A description fit for React itself.
Server Components also look fairly complex, and I'm glad I haven't had to deal with them so far.
The improved error messages on hydration errors are welcomed. The <Context> as a provider and ref as a prop changes are nice QoL changes.
Overall, I like React/Preact as far as building SPAs go. Using it with a feature-rich component library (say, MUI) and a simple state management solution (like Preact Signals) makes it very straightforward to build SPAs, as far as I'm concerned. But I worry about the complexity creep. The descriptions for the new hooks in those release notes put a massive cognitive load on me just by reading them.
The React Compiler, on the other hand, is a much needed tool. It should result in components that are less complex, as the programmer won't have to write typical optimizations by hand, as part of the component itself. I'm looking forward to its release and eventual integrations with Vite and etc. From what I heard, Preact will support it too.