[HN Gopher] React 19
___________________________________________________________________
React 19
Author : gajus
Score : 159 points
Date : 2024-12-05 18:50 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| riffic wrote:
| here's what really matters: https://endoflife.date/react
| captn3m0 wrote:
| PRs are welcome to add the new release (and merge all the 18
| minor releases).
| efields wrote:
| Imagine if HTML5 had an EoL.
| nicce wrote:
| Some day
| mardifoufs wrote:
| React is very backwards compatible, so the eol is much less
| impactful than for say, vuejs
| demarq wrote:
| Awesome release.
|
| 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.
| orliesaurus wrote:
| Maybe not with react
| OtomotO wrote:
| My tip: you start by avoiding React altogether.
|
| 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!
| audessuscest wrote:
| HTMX is certainly easier, but it's the worse if you want to
| actually _learn_ FE
| digdugdirk wrote:
| As someone who isn't a web developer, what do you mean by
| that?
| audessuscest wrote:
| HTMX abstracts functionality into pseudo-HTML attributes,
| allowing you to handle tasks like event binding and
| DOM/content manipulation that would typically require
| JavaScript. By using HTMX, you primarily focus on
| learning HTML and its attributes, with minimal need to
| learn JavaScript.
| baq wrote:
| Not sure how to interpret what you're saying.
|
| HTMX allows you to learn the very basics: the HTML which is
| almost verbatim turned into DOM which the browser renders.
| It's _the_ FE. Everything else is layers upon layers of
| abstraction which ultimately compile down to the DOM
| representation of HTML.
|
| ...or to put it differently, quoting HTMX 's author: using
| HTTP to transfer HTML? How queer!
| audessuscest wrote:
| Sounds like you don't know anything about FE except
| htmx...
| szundi wrote:
| He has a point though
| akdor1154 wrote:
| Strong disagree, it would be a great way to learn vanilla
| html/CSS/js without kneecapping yourself.
| audessuscest wrote:
| How do you learn JS by using htmx exactly ?
| runako wrote:
| Couldn't one say the same thing about using any framework
| that provides capabilities that otherwise would have to be
| learned?
| wslh wrote:
| Is discussing React vs. HTMX like comparing apples to
| oranges?
| recursive wrote:
| Maybe, but it may be reasonable to do that sometimes. What
| fruit should we bring to the picnic?
| Tade0 wrote:
| Or what goes well with milk.
| keb_ wrote:
| Yes. Something HTMX evangelists always forget to mention is
| that HTMX is not a replacement for React -- HTMX + a
| backend is. This introduces a whole new layer of
| complexity; it's a total tradeoff. That is to say there are
| probably React apps that would be better as HTMX apps.
| exceptione wrote:
| Also, does that currently mean that the backend will be
| Javascript?
|
| In the browser we have no choice, but I prefer to prevent
| that accident from spreading to my servers.
| keb_ wrote:
| No. Backend can be anything.
| thunky wrote:
| > HTMX is not a replacement for React -- HTMX + a backend
| is
|
| Most React apps need a backend too.
| klaussilveira wrote:
| Still no good component or UI libraries for HTMX.
| clivestaples wrote:
| This is the sticking point for me. I get so many gains in
| Rails but I quickly sink into time-consuming component
| research/building. My eyes are always open for HTML/JS
| component libraries along the lines of react-aria.
| Weetile wrote:
| I've had a great experience using Golang + HTMX + DaisyUI
| using the tailwind-cli-extra standalone tool, negating the
| requirement for npm at all.
| nox101 wrote:
| Can webcomponents be trivially used with HTMX?
|
| Like for example: https://shoelace.style/
| klaussilveira wrote:
| Shoelace is great, but not robust. No data table, no
| date/time picker, no pagination, no sidebar.
| alexpetros wrote:
| Anything that can be loaded as a stylesheet or a script tag
| works great with htmx. These are not htmx-branded
| libraries... because they're just web libraries.
| klaussilveira wrote:
| Right, but then you are glueing things together and
| mixing and trying to match CSS so they all play together.
| AirDatepicker here, tomselect there, datatables here,
| popper there. All of sudden you lost a lot of time trying
| to make things look like one cohesive unit, when you
| should be doing your app.
|
| Meanwhile, I have v0 generate the whole skeleton for me,
| with composable reusable components, and just got the API
| done.
| mlboss wrote:
| That is exactly the point of HTMX. Use your backend stack
| and sprinkle some hx tags.
| exceptione wrote:
| The problem I have with many of such advice: 1) what do you
| precisely mean and 2) why do you think so.
|
| 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?
| hirako2000 wrote:
| My main dislike for React is that I'm constantly learning
| React, its intricacies and idiosyncracies.
|
| Disproportionate amount of energy I would rather spend
| learning JavaScript, something that would last.
|
| Using React since 2013. Each release is an excitement,
| until I realise some chunk of concepts which altogether
| took months to fully grasp, are gone. Some even needed to
| be unlearned.
|
| A lot of abstractions.
|
| React doesn't make you a better developer, it makes you a
| better React developer.
|
| I don't feel that with Vue. I don't feel that with most
| libraries I use.
| qt31415926 wrote:
| > React doesn't make you a better developer, it makes you
| a better React developer.
|
| React's pure component functional style translates really
| well to nearly every other type of software development.
| impoppy wrote:
| It doesn't necessarily mean that React does it right.
| When building React apps, developers spend too much time
| on designing architecture for many things that should
| have been taken care of by the tools they are using. The
| more I am in web development, be it backend or frontend,
| the more I'm disappointed that declarative programming is
| still not a thing. One too many hours wasted on reducing
| boilerplate, replacing big boilerplate with smaller
| boilerplate, optimizing boilerplate and writing that
| boilerplate. While still being far from perfect, other
| frameworks like Vue and Svelte do great job at making the
| developer write less boilerplate and more business logic.
| erokar wrote:
| Practically every frontend framework uses components. The
| problem with React is that so many of its abstractions
| are leaky and forces a lot of accidental complexity on
| the developer.
| johnfn wrote:
| Why is this attitude so pervasive? It's akin to writing
| backend and saying you should avoid Postgres altogether and
| use text files saved on the hard disk.
| mollerhoj wrote:
| How are these two scenarios comparable?
| mixedCase wrote:
| Because both are ubiquitous to the point they basically
| dominate a large part of a usecase's toolspace.
| mlboss wrote:
| Sql syntax does not change every month
| MarcelOlsz wrote:
| Just use Vue lol.
| ramses0 wrote:
| I've avoided React as much as possible. Dabbled (positive
| experiences) with Vue. What's your recommendation w.r.t.
| "Components"? I've tried doing web-components from scratch
| (frameworkless) but nested web components have nasty gotchas.
|
| 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?
| deadbabe wrote:
| Just start.
|
| 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.
| jfengel wrote:
| It helps to know that the basic tutorials still apply. You
| don't need these advanced features. Certainly not for basic
| projects, and possibly not ever. After all, people
| successfully wrote React apps without it.
|
| 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.
| trgn wrote:
| hooks was the beginning of the end imho. it replaced nicely
| encapsulated OO, with unmaintainable functional cruft.
| runtime footprint of react has vastly increased, and code
| has gotten harder to debug.
| rglullis wrote:
| When I wanted to make a SPA for a project, I also wanted to
| avoid analysis paralysis. So I looked at Vue and React.
|
| Getting started with Vue was so much easier, I never looked
| back to React.
| deadbabe wrote:
| Do you ever wonder about the road not taken?
| rglullis wrote:
| Let me rephrase. I never looked back at React as the
| default option for any greenfield project.
|
| I still have to deal with React codebases, and every time
| I do I dread it.
| moffkalast wrote:
| Life is a never ending series of forking roads not taken,
| you take some and you leave others unexplored, there's an
| near infinite amount of things to learn and we only have
| so much time to learn them. It's not feasible to worry
| about it.
|
| I presume most people learn to deal with that when
| they're like, twelve, or something. Otherwise you just
| live with constant regret and FOMO.
| iterateoften wrote:
| The rest of react still works. It's not like it's a primary
| entry point or required. Looks like an advanced feature.
| pier25 wrote:
| > _I feel sorry though for someone getting into frontend dev
| now._
|
| 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.
| threatofrain wrote:
| SSR was essential and the motivation was stuff like SEO. For
| people who care that was uncompromisable. For people who only
| care about SPA the conversation has been frozen for almost a
| decade; almost all the innovative fury has been on the
| SSR/MPA/hybrid side.
| pier25 wrote:
| > _For people who only care about SPA the conversation has
| been frozen for almost a decade_
|
| I don't know, there's been a lot of stuff since 2014.
|
| In client-side React we've seen stuff like react-query,
| mobx, etc which weren't there a decade ago. Back in 2014
| everyone was still using redux (ugh).
|
| Or Svelte and SolidJS which have brought massive
| improvements in performance and reducing JS with signals,
| compiler, etc.
| acemarke wrote:
| FWIW, both Redux and Mobx were invented in 2015.
| pier25 wrote:
| Thanks for the clarification. It was a long time ago!
| threatofrain wrote:
| And if you're still using React with Redux you're doing
| just fine for SPA development, as in you're actually
| still _modern_ and not merely fine. React Query is the
| only new development you listed that SPA professionals
| may want to think about, and even then only a little. It
| 's a life convenience tool for making async calls to
| foreign APIs easier (for internal APIs you probably want
| RPC-like experiences with type and client generation).
|
| Meanwhile MPA people are redefining the boundaries of
| work by marrying the frontend to the backend. They are
| doing some big re-architecture type stuff, and it is very
| interesting, far more interesting than React Query being
| the better Axios. If I had to lead with an argument about
| interesting changes on the SPA side, I would've lead with
| the ongoing improvements to CRDT libraries. It's niche
| but there really isn't much of a revolution going on
| otherwise on the SPA side.
| pier25 wrote:
| > _as in you 're actually still modern and not merely
| fine_
|
| Not sure what you mean by "fine".
|
| There's nothing modern about client-side React. To get
| some perspective consider that more time has passed since
| today to the release of React in 2013 than from React to
| jQuery in 2007.
| jazzyjackson wrote:
| "screw it, lets compile it into a WASM blob that renders it
| all on a canvas"
| eddd-ddde wrote:
| That'd be unironically simpler than the current state of
| things.
| pier25 wrote:
| Nah. There's so much stuff that would need to be
| implemented.
|
| Just think of all the functionality related to text that
| browsers give you in HTML: styles, spellchecking,
| selection, accessibility features, etc. And that's just
| text.
| gf000 wrote:
| It would be significantly worse, unless there is a very
| good reason for that (e.g. some app like Photoshop could
| work that way).
|
| You lose any form of accessibility, inspectability,
| AdBlocking won't work, in many cases even mouse
| select/copy-paste won't work..
| eddd-ddde wrote:
| I didn't say it'd be better. Just it would be simpler.
|
| No need to learn html, css, JavaScript, bundlers, etc,
| etc.
| gherkinnn wrote:
| You will inadvertently reinvent the browser inside a
| browser but worse.
| TimTheTinker wrote:
| Seriously, I think there is a possible future where a
| macOS-like reactive UI toolkit is developed that compiles
| and deploys to the web via WASM. Maybe even a compiler that
| takes something like Xcode's Interface Builder's .nib files
| (and associated code). Microsoft tried something like that
| with Blazor WebAssembly. It works really well, but I think
| a fully data-reactive model like Apple's could be even more
| successful when applied to web apps.
|
| Whatever the case, I think very few companies have reached
| the excellence of native macOS interface design in the
| context of a web app. Figma is a lone exception; for anyone
| else to achieve what they have, they'd have to reinvent the
| wheel yet again in so many small ways. (Have you noticed in
| Figma how moving the mouse down and to the right diagonally
| from a menu item to its associated submenu does _not_ cause
| the menu item and submenu to be deselected? That detail,
| and so many others, are straight-up macOS-inspired UI
| craftsmanship.)
|
| We need a reusable toolkit that lets ordinary developers
| achieve Figma-level UI excellence in web apps.
| mejutoco wrote:
| Dreamweaver existed even earlier. I hope something like
| what you mention (flutter) does not become popular
| because of accessibility.
| colonelspace wrote:
| > Maybe even a compiler that takes something like Xcode's
| Interface Builder's .nib files
|
| Please never let this happen.
| nox101 wrote:
| I don't agree but if you're looking for something that
| renderers everything in a canvas it's called Flutter
| https://flutter.dev/, and strangely it's made by Google,
| even though Flutter's success means the end of scraping
| the web for search.
| mattgreenrocks wrote:
| Parent speaks the truth.
|
| The amount of fiddling and tweaking required for web UI
| feels substantially higher than any GUI toolkit I've ever
| used. And I've used a lot of them!
|
| I suspect this isn't seen as a problem because Vite and
| friends do an amazing job of hot reload. But it is still
| a helluva brick wall to shipping things.
| Muromec wrote:
| A11y enters the chat with their buddy "compliance"
| klaussilveira wrote:
| It's hard not to use Next.js and React due to the insane amount
| of building blocks to built on top of. Not to mention design
| libraries and component libraries, such as Radix and shadcn. If
| you don't have the design skills, or the time, nothing beats
| that.
|
| 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.
| hi_hi wrote:
| I went down this path very recently as a React newbie, for
| the exact reasons you stated. It looked like I'd be able to
| save a bunch of time, and I'm sure I did.
|
| 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.
| klaussilveira wrote:
| I understand that sentiment, although in an opposite away:
| for large projects with multiple devs, I'd prefer something
| like Rails or Django, precisely because they are battle-
| tested with a lot of official documentation. Things are
| done in one specific way and the team can just agree to
| whatever the framework recommends. And there are clear
| guidelines for pretty much everything.
|
| However, in solo projects, I want to spin something up
| quickly. I don't want to spend my scarce weekend time
| designing yet another date time picker. Or having to write
| hackish CSS to try and make whatever time picker library I
| chose to match the CSS of Bootstrap. And then everything
| falls apart because some other library does not fit into
| the overall style (looking at you DataTables). In React
| land, I don't have to worry about this. I just throw
| components together, link it to my API where the show real
| is, and call it a day.
|
| UIs are just UIs. They should be plug and play. So much
| time is wasted redesining data grids and data tables and
| pickers and filters for the 1000th time.
| RandomThoughts3 wrote:
| > I feel sorry though for someone getting into frontend dev
| now.
|
| 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.
| typeofhuman wrote:
| > personal project
|
| In professional projects with teams of developers
| contributing and PMs wanting feature flags, tracing, complex
| behavioral logic, it gets crazy.
| yazaddaruvala wrote:
| I'd say even more so for professional projects you're
| better off with React.
|
| Been there and done that with and without. Junior (and
| Senior) devs fundamentally don't read the docs. That and
| requirements churn are the problems.
|
| Given that, it ends up so much better with React.
| vundercind wrote:
| I liked redux, but its vocabulary was the last thing core React
| should have adopted from it.
| acemarke wrote:
| I maintain Redux, and I don't think Redux inspired this
| particular term usage (which came from the "Flux
| Architecture" pattern.)
|
| As far as I know this usage ultimately derives from HTML
| `<form action={}>`.
| vundercind wrote:
| Ah, different "action", then? The presence of "reducer" had
| me assuming the action was also analogous.
|
| FWIW I liked Redux enough that I once half-reimplemented it
| for Brightscript so the UI guys would have something
| familiar to work with when they had to touch Roku apps. I
| always taught Redux initially using different terminology,
| though, because I found that _most_ of my time learning it
| (which, mercifully, still wasn't _that_ long, because it's
| small and pretty sensible) was figuring out the vocabulary
| ("do... do they just mean 'event'? Well if so surely they'd
| write 'event', so I must be wrong...")
| acemarke wrote:
| Hmm, that is a good point that `useActionState` accepts a
| reducer-like function (although I think it's async in
| this case?).
|
| And yeah, half of Redux's terminology is simply because
| the existing Flux Architecture libraries from the prior
| year all used those terms. There were several debates in
| the issues about whether to name them "actions",
| "events", or something else, and the conclusion was
| "let's just stick with the existing Flux terminology":
|
| - https://github.com/reduxjs/redux/issues/891#issuecommen
| t-147...
|
| FWIW, as I've revamped the Redux docs over the years, I
| have specifically made sure we describe the "actions ===
| events" aspect:
|
| - https://redux.js.org/style-guide/#model-actions-as-
| events-no...
|
| - https://redux.js.org/tutorials/essentials/part-1-overvi
| ew-co...
| vundercind wrote:
| That's great--my experience is years out of date, so my
| gripes may well be obsolete :-)
|
| Thanks for the work on a project that I got good use out
| of, and happen to personally like more than I do _most_
| software.
| vouaobrasil wrote:
| I love website design for personal projects, but it is the
| least attractive of all development fields due to this
| complexity. I'm sure some people like it, but I found website
| dev a lot more fun 20 years ago...
| meme3 wrote:
| > Imagine you decided to start developing websites today, how
| do you even start?
|
| 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.
| can16358p wrote:
| I get NextJS but how does React itself try to screw devs with
| PaaS?
| mhnthrow wrote:
| The Getting Started docs recommend against using vanilla
| React and nudge you towards NextJS and similar frameworks
| because you're gonna end up needing that stuff eventually
| https://react.dev/learn/start-a-new-react-project
|
| So new projects have to actively not follow the recommended
| approach in the docs if they want to use vanilla React.
| billti wrote:
| It's funny to think back now that JSX had such a strong
| negative reaction on launch. That's the one thing from React
| I love - having a declarative and strongly typed markup for
| HTML in my JS/TS code.
|
| 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.
| exceptione wrote:
| I learn Svelte has a template language.
| norman784 wrote:
| It is not very different from mustache, or other older
| template engines and it's really needed because there is no
| conditional html rendering, loops etc in the HTML spec
| itself, I like that more than how Vue does.
|
| But otherwise, Svelte has a very low surface, everything
| else is just standard vanilla JS/Html, also one thing that
| Svelte has over other frameworks is that vanilla JS
| libraries just work, no need for a wrapper any.
| mattgreenrocks wrote:
| Some devs point at Svelte and say, "not many libraries,
| it can't be very good!" What they don't realize is it
| doesn't need a cottage industry of tiny adapter
| libraries, JS stuff works fine.
| nailer wrote:
| I'd hoped this release would have added a compiler and
| drastically simplified the syntax to something close to a
| modern framework. I know React is eventually going to do that,
| but it feels like React has been drowning in overly complex DX
| for at least the last 5 years.
| acemarke wrote:
| The React Compiler is currently in beta:
|
| 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-...
| umvi wrote:
| Yeah I'm getting kubernetes vibes from all the abstractions
| mentioned in a single sentence. I'm sure the abstractions are
| needed and/or powerful to accomplish React's goals, but it's
| just a bunch of extra stuff added to the learning curve which
| makes it harder for outsiders to understand and contribute to
| the code.
| mattgreenrocks wrote:
| It's insane that the total complexity of the ecosystem has only
| grown in the past decade, despite the amount of time and tools
| trying to contain it. I have a hard time seeing that
| expectations rose accordingly alongside this. I'm half-
| convinced it is tolerated as a collective subconscious
| gatekeeping/total employment mechanism.
|
| 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!
| Stevvo wrote:
| "My criticism is more FE development in general not just React"
|
| No, it is not. Your criticism is _very_ specific to React.
| ww520 wrote:
| Why is state management so complicate in React?
| CharlieDigital wrote:
| React is the only major FE lib/framework that basically re-
| renders each (affected) component and sub-tree on update
| cycles.
|
| 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.
| o_m wrote:
| The attitude I've heard from many frontend devs is that they
| acknowledge that AI will do most of the work. v0 and Bolt will
| do most of the work. Not because it does a better job, but
| because there will be a race to the bottom where employers
| don't want to pay for anything else. So this might mainly be a
| problem for the AI to learn.
| markandrewj wrote:
| I generally feel the opposite way. React was changing every few
| weeks when I started using it, the docs and API are much more
| stable and consistent now. In general web standards are more
| stable then ever also. People younger then myself won't have
| learn 100s of layout hacks to get their pages displaying
| properly cross browser, or sometimes even in just one browser.
| This is just my perspective, although I also understand
| JavaScript fatigue, I feel it is actually one of the best times
| to start learning.
| lukebuehler wrote:
| It's not that bad. I started basically from zero about a year
| ago, have been doing react maybe 20% of my work time since
| then, and I would say I now understand and can use most
| concepts/features in react.
| Cthulhu_ wrote:
| I'm trying to parse that sentence and as it turns out...
| probably nothing is relevant to me that just writes end user
| front-end stuff. Most React development is in the backend /
| rendering or for specialists that write libraries, feels like.
| pjmlp wrote:
| My main approach, when it is something I control, I stay as
| much on .NET and Java solutions for Web development, with
| minimal JavaScript.
|
| When not, I focus on backend and devops instead.
|
| Although some SaaS products make our life harder, with React
| only SDKs.
| Taylor_OD wrote:
| > Imagine you decided to start developing websites today, how
| do you even start?
|
| 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.
| thorum wrote:
| > 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?
|
| 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.
| rdsubhas wrote:
| In my experience, React was an interesting take, but it had
| certain flawed red-flags that were ignored from the start. I
| wrote posts about it, but was doomed as a skeptic. The original
| fundamental premise: let's do one-way binding with virtual DOM,
| re-render, diff - did not make fundamental sense. Double the
| memory in browser, complete re-render & diff for every
| interaction? The answer was: Make it reliable, then make it
| fast. Now, it's full of hacked-up constructs attempting to make
| it fast - but it's neither fast nor reliable. At least with
| honest two-way binding frameworks, fast is guaranteed, and
| reliability comes from my experience. With React it's just a
| mess. I pity all the frontend engineers who's first intro has
| been with React, because unlearning is much more difficult than
| learning.
|
| 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.
| simplify wrote:
| Virtual DOM is not inherently an issue. Many libraries use it
| and are much faster than React.
|
| 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.
| cyral wrote:
| The blog post is an easier read:
| https://react.dev/blog/2024/12/05/react-19
| nailer wrote:
| const error = await updateName(newName);
|
| Why would updateName return an error? Why not just throw an
| Error like JS/TS?
| Mogzol wrote:
| It's just an example async call, it could be anything. It's
| not the important part of that code example, it's only
| purpose is to show that an async call is happening. It could
| be written as a try/catch, or it could be written how they
| wrote it. I guess they chose that way because it's short and
| to the point.
| BillSaysThis wrote:
| updateName is a call to the backend/server to update the
| database...
| htunnicliff wrote:
| One of the best parts of this release: ref as a
| prop: Refs can now be used as props, removing the need for
| forwardRef.
| blastonico wrote:
| I see people complaining a lot about React, why is it? What are
| the alternatives?
|
| PS: I'm not a frontend engineer but I find this topic
| interesting.
|
| Thanks!
| bandrami wrote:
| Using a scripting or templating language on the server to form
| and send HTML and CSS to the client as $DEITY intended
| Muromec wrote:
| Django is still there and is still better than Phoenix by the
| way. I didn't really touch it in about 10 years, but ...
| nothing changed. It's amazing!
| vundercind wrote:
| Unironically this. The fastest "web apps" I've seen that
| weren't _absolutely required_ to be javascript-heavy to
| operate by virtue of what they do, have been mostly or
| entirely rendered server-side and have just sent entire pages
| for most interactions. Still performed better than 99% of
| webapps.
| nailer wrote:
| Svelte. Rather than const [name, setName] =
| useState('blastonico') ... setName('nailer')
|
| You do: let name = 'blastonico' ...
| name = 'nailer'
|
| Also a single .svelte file includes everything you need for a
| component (HTML, JS, CSS), so it's easier to manage.
| efields wrote:
| Vue is also nice.
| nailer wrote:
| Yep. Svelte's SFC was inspired by Vue. If you like Vue
| you'll like Svelte which is familiar but adds a compiler
| for simpler syntax.
| spoiler wrote:
| I honestly don't feel like Svelte makes things simpler.
| And I'm saying this as a "fan" of Svelte and think its
| compiler is very cool.
|
| It just feels a bit weird that there's special .svelte
| specific rules.
|
| Runes kinda fix this, but it's still a bit weird.
|
| I think Solid or Vue are much simpler (but only did small
| projects in them) and have a simpler mental model. I've
| not yet used Preact, but heard good things about it
| sensanaty wrote:
| Yeah I like Svelte a lot, but I can't help but feel Rich
| feels the need to _be different_ , and not necessarily
| always in a good way. SvelteKit routing[1] is an example
| that pops out at me as being genuinely bafflingly bad to
| the point of comedy.
|
| [1] https://svelte.dev/docs/kit/routing
| ptrwis wrote:
| let name = $state('blastonico')
| namrog84 wrote:
| I know some people didn't like this change. I think it
| works well to help make it clear and obvious to reactive vs
| non reaction changes.
| phailhaus wrote:
| `setName` makes sure that state changes are queued up for the
| _next_ render, allowing you to treat all state and props as
| constant within the current render. If you are just assigning
| variables directly, then your state is changing _within the
| same render cycle_ , which can lead to all sorts of nasty
| bugs that are difficult to replicate.
|
| I get that assigning variables is easier to understand, but
| it's way, way harder to actually scale and maintain. Check
| out flux architecture.
| ww520 wrote:
| Just curious. How does that work on changes between
| depending states within a cycle? E.g.
| [foo, setFoo] = useState(1); [bar, setBar] =
| useState(); setFoo(10); setBar(foo * 2); //
| Is bar 2 or 20 at this point?
| sensanaty wrote:
| Vue is infinitely better in pretty much every way other than
| available libraries (specifically UI libraries and some stuff
| like Motion, though that's soon-to-be framework independent),
| but to be honest I've never felt that problem in my 6 years
| working with both, and especially in more recent times pretty
| much everything is framework agnostic anyways, even the big
| popular ones like TanStack Query.
|
| 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...
| CharlieDigital wrote:
| Another vote for Vue.
|
| It's harder to do poorly and even when you do, it doesn't
| punish you the same way that React does.
| FrontAid wrote:
| > specifically UI libraries
|
| 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).
|
| [1] https://frontaid.ch/web/ui/libraries.html
| seanvelasco wrote:
| Solid.js is the real alternative to React
| breadwinner wrote:
| You don't need a complex framework like React. Check out this
| SPA app:
| https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
|
| It uses a 500-line router and a 500-line UI component lib.
| azemetre wrote:
| I feel like most of the issues devs have with react are the
| community surrounding it. Lots of churn and burn libraries with
| breaking issues and changing APIs, NodeJS issues that effect
| the ecosystem (like node-sass vs dart-sass), and a snake oil
| aspect from charlatans that you see on social media (granted
| this is not limited to react, but it feels like react has the
| most of them).
| nox101 wrote:
| My experience
|
| 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.
| pixelsort wrote:
| There are 45 comments so far and 7 references to "redux". I'm
| just gonna rep for the Recoil clones here and mention Jotai,
| which likely already works with React 19 without any necessary
| changes.
|
| 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.
| 0xblinq wrote:
| +1
|
| 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
| babyshake wrote:
| When I go to Jotai npm docs page
| (https://www.npmjs.com/package/jotai) I don't really get the
| impression of how this helps get away from using a lot of
| different context providers or Redux. The nice thing about
| context hooks is they are composable, combined with cached
| queries you can have a decently maintainable pattern. How does
| Jotai provide a tangible improvement on this?
| pixelsort wrote:
| The benefits would depends on how your code is structured,
| which dependencies you use, and overall complexity. Contexts
| provide and elegant developer experience, up until they
| don't. Have you ever implemented nested SplitView components
| under Dockview? It can be brutal on contexts.
|
| 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.
| qudat wrote:
| Everyone should try https://starfx.bower.sh which is a fresh
| take on state and more importantly, side effect management.
| wg0 wrote:
| Breaking news - full support for custom elements. Web components
| that is.
| EternalFury wrote:
| Nothing new to what I am going to say and not strictly related to
| React 19.
|
| 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_
| norswap wrote:
| Frontend frameworks really do make things simpler once you go
| beyond small applications though. Automatically re-rendering
| when the data/model changes is the right thing to do.
|
| 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.
| taeric wrote:
| I think there are assumptions here that are not shared?
|
| 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.
| bobthepanda wrote:
| tables with layout wasn't really an issue of purity, but
| they were another layer of the cruft you described where we
| were abusing things not built to actually do that.
|
| grid and flexbox are probably closer to actually being a
| one-stop easy-to-use paradigm with less nasty edge cases
| than tables, but all the table code stuff is still there if
| you _really_ want to do it.
|
| ---
|
| > 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.
|
| I actually think this is orthogonal. The power of
| frameworks like React is that nobody wants to write the
| same app five times (windows/mac/linux/ios/android) using
| sometimes wildly different native coding paradigms, and
| coordinating feature development across native platforms is
| like herding cats.
| EternalFury wrote:
| You must have found a way to add more components, actions,
| properties, etc. automatically when your data models change.
| Otherwise, you are changing your UI every time those change.
| Except that now you have to maintain DTOs, models, actions,
| APIs, schemas, etc. in many places and across many teams.
|
| Sorry, I have been around the block so many times, there's
| now a moat around the block.
| Muromec wrote:
| That's because VC funded software development is a welfare
| program for smart people that also want to have fun. It's okay.
| paulddraper wrote:
| > we managed to add complexity wherever possible
|
| 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.
| kobalsky wrote:
| > we managed to add complexity wherever possible
|
| 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.
| mrtksn wrote:
| React was my reason to distance myself from Web frontend. Huge
| complexity just to make the web browser render boxes in a way
| it's not intended to do. Huge loss of productivity and tooling
| in the name of changing a paradigm. Some cool ideas and
| implementations, sure but was it worth it? Maybe it was a job
| security stunt or something of that sort?
|
| 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.
| veidelis wrote:
| What is your alternative to the problems that React
| supposedly solves?
| mrtksn wrote:
| I no longer have an idea for the web, I do native mobile
| apps now. SwiftUI for example shares many ideas with react,
| like being declarative.
|
| The difference is, in SwiftUI you fire up Xcode and you are
| up and ready to build the thing you intend to. No tooling
| setup, no intermediate steps to transpile the code into
| something you can't recognize and the "backend" that deals
| with the logic is the same language with the same
| paradigms. Mind you, SwiftUI is considered a downgrade when
| it comes to tooling. Yet everything fits and you didn't
| spend mental energy to try to make the tools work as
| intended.
|
| My mantra now is to use the tool that is built to do the
| things I want to do and stop trying to make make it work in
| ways it's not intended to. That's why when I want to have a
| web interface I simply work with DOM directly. That's how
| the creators of the web browser intended:) No virtual DOM,
| no libraries doing magic and managing the DOM for me. I'm
| sure there's place for ReactJS too, it's just that its not
| for most use cases.
| ransom1538 wrote:
| I just rsynced my php files over. ci/cd done. php does html/css
| ui done. I am not sure what all the js trend is about.
| veidelis wrote:
| You just havent worked on an app that is heavy on client
| state.
| ken47 wrote:
| React and similar frameworks have made it easier to manage a
| given level of complexity. The complexity of app features have
| adjusted and will continue to adjust to the new frontier
| enabled by said frameworks.
| efortis wrote:
| I like React but since hooks (v16.8), React's changes are
| nothing but skill bragging.
|
| I stopped hoping for the reason behind changing the class
| components API to hooks.
| jmull wrote:
| Does react use semantic versioning?
|
| 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.
| acemarke wrote:
| Yes, React uses semver. React 19 has been in development for
| over 2+ years - React 18.2 (the last meaningful minor release)
| came out in June 2022, so the release pace has been slow enough
| people have complained that it's _too_ slow:
|
| - 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)
| alexanderchr wrote:
| The numbers are high because they jumped directly from 0.14 to
| 15.0, but the cadence is not particularly high: 18.0 was
| released early 2022, 17.0 late 2020 and 16.0 late 2017. That's
| three major releases in seven years.
|
| 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.
| nox101 wrote:
| upgrading is far from painless. If you're using any 3rd party
| solutions and they aren't compatible with the latest React
| you're going to have a bad time.
| alexanderchr wrote:
| Yeah, as I said above I don't disagree. The ecosystem has
| lots of issues but React gets all the hate, unfairly in my
| opinion. It's a pretty well maintained piece of software.
| veidelis wrote:
| I cant imagine saying upgrading is painless considering the
| way how React deprecated class components.
| acemarke wrote:
| What specifically are you referring to?
|
| The original `createClass` API was indeed deprecated and
| removed all the way back in 2017 [0]. You can still use
| them today with the separated `create-react-class` package.
|
| ES6 class components still work as-is even in React 19 -
| it's just the legacy context feature that's been removed.
| They're generally discouraged, in that function components
| are now the standard way to use React, but they're still
| not "deprecated" in the sense of a warning or removal.
|
| [0] https://legacy.reactjs.org/blog/2017/09/26/react-v16.0.
| html#...
| uhoh-itsmaciek wrote:
| Great to see this--there are some nice features that encourage
| using standard web technologies like forms, and some solid
| quality of life improvements.
|
| 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...
| acemarke wrote:
| Yeah, _we library maintainers_ are feeling the same way :)
|
| - 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.
| uhoh-itsmaciek wrote:
| Oh awesome, thank you! I'll have to investigate this and play
| with it, but that makes sense.
| ENGNR wrote:
| Really glad they delayed the release to (hopefully) solve the
| parallel suspense issue. Haven't tried it yet but high hopes, and
| great release overall.
| preommr wrote:
| Updates like this are exactly why React sucks.
|
| 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.
|
| [0]https://react.dev/blog/2024/12/05/react-19#actions
___________________________________________________________________
(page generated 2024-12-05 23:00 UTC)