31 ms·

Introducing react.dev

748 points by clessg 4y ago

deleted 4y ago
[deleted]
giraffe_lady 4y ago
I've been using I think the beta version of this recently, it's definitely an improvement and makes the react api seem a lot more coherent than the old version. I'm glad they fixed the janky scrolling though that has been cracking me up for a while. It's an example of a common complaint/pitfall with react and even the official docs were plagued by it. As a heavy react user and light react hater I love to see that shit lol.
- danabramov 4y ago
  Please don't hesitate to report things like janky scrolling to the issue tracker (https://github.com/reactjs/reactjs.org/issues https://github.com/reactjs/reactjs.org/issues). We were changing things a lot and I'm sure a bunch of regressions could've crept in, so all reports are super helpful.
  - matsemann 4y ago
    The page you linked here https://news.ycombinator.com/item?id=35187407 https://news.ycombinator.com/item?id=35187407 Is basically useless when scrolling. All I see is a gray background, and when I stop the content disappears. Makes it hard to quickly skim to the correct section.
    - pests 4y ago
      I have no trouble on my end scrolling that page.
      - matsemann 4y ago
        On desktop it works "fine", problem is that the scroll gets caught inside every code window on the way down. So scroll the page a bit, cursor above an example, scroll the example until end, then page keep on scrolling, then stuck on a new example etc. On mobile it just blanks when scrolling.
explodingcamera 4y ago
Looks really nice! Also, super happy that the interactive examples are not super sluggish code sandbox iframes, they're actually usable! A more typescript-first approach would have been nice, or at least typescript/JavaScript toggles, but the React team seems to be aware that that's an area they need to work on.
- johnny_canuck 4y ago
  That is something I really dislike about the react-query docs, the examples are code sandboxes. Glad to see they didn't go that path here. I find they add a lot of friction when I am looking for a quick reference.
- danabramov 4y ago
  Yeah we'd like to add TS throughout but it will require some technical and some content work. We didn't want to block the release on that.
  - johtso 4y ago
    The sexiest example I've seen is in the XState docs.. not sure what they're using to get the types into the tooltips.. https://stately.ai/docs/xstate/running-machines/react#usemachine-hook https://stately.ai/docs/xstate/running-machines/react#usemac...
    - nawgz 4y ago
      Looks like Shiki: https://github.com/shikijs/shiki https://github.com/shikijs/shiki If you "inspect" the elements with the mouseovers, you can see they statically compiled the TS definition into the HTML. I guess it probably uses the same APIs to read the types VSCode does, given what they state the purpose of Shiki is.
    - afidrya 4y ago
      It's Docusaurus 2 + TwoSlash: https://docusaurus.io/blog/2022/08/01/announcing-docusaurus-2.0 https://docusaurus.io/blog/2022/08/01/announcing-docusaurus-...
airstrike 4y ago
> Believe it or not, React will soon be ten years old. In JavaScript years, it’s like a whole century! Hilarious! As someone who was once a "full-stack" web dev in the age of jQuery, CSS resets and local fonts only, this definitely rings true. And having just started learning React (through Next.js), this is a timely and welcome refresh! Thank you!
- epolanski 4y ago
  React's first implementation (on top of Ocaml) is from 2011 I believe.
benrutter 4y ago
Looks like some good resources and a neat redesign. The domain move makes me realise how odd it was that before they had 'org', which is normally used by charities/non-profits. I'm guessing Typescript is the force behind dropping 'js' from out of the domain too.
- sophiebits 4y ago
  As the person who most often pushed for .org, I can say it was because I wanted to emphasize the community nature. React isn’t a commercial offering. (I had to talk the team out of react.com as the main brand for this launch; although that URL works, I think react.dev is more reflective than .com of what we’re trying to do.)
waboremo 4y ago
Finally! Although looks like Google still has to update so newcomers are likely still going to head to the legacy docs and not realize it (and the legacy page still links to beta.reactjs.org vs react.dev). A tremendous improvement though, and it must have been a lot of work coordinating, especially the easier to digest images sprinkled throughout. At last we can officially move past the era of class components.
- danabramov 4y ago
  We'll make the legacy site binner a bit more prominent and clear -- thanks for feedback. I planned to but got distracted with other things during deployment.
  - waboremo 4y ago
    Perfectly understandable, it's a huge change and these smaller things fly under the radar easily. Congrats to you and the team for pulling off the major transition smoothly!
explaininjs 4y ago
Are class components really on the down & out? I tried going all in on hooks with a complicated app using lots of web workers and generally heavy computation and complex logic (a game). It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear. Having a dedicated place to process changes in props and setup/teardown logic is just generally nicer than weird dependency arrays and returning destructors from effects.
- bottlepalm 4y ago
  I think generally you should start with functional components, try to keep things simple, and use class components as the exception and not the rule. My own app is mostly functional components, but I did fall back on a class component in a case where I needed the lifted state of a function reference to remain current across renders.
- phphphphp 4y ago
  Most React codebases benefit from the simplicity of functional components, because they fit into the model most people have of websites + web apps. If you’re doing anything complex, you’re in a very small group.
  - Klonoar 4y ago
    I would argue the inverse: if your project relatively simple enough that hooks don't feel messy, then it probably doesn't need to be a React app to begin with. Class components are just (IMO) cleaner, and I find myself saddened at the level of disarray most codebases with hooks are nowadays. Enough has been written elsewhere about how hooks require one to keep more in their head; class components have an agreed up layout/structure/etc that is important in large codebases.
    - dylan-m 4y ago
      The most frustrating part of this is when you run into some library that is all in on hooks and insists you use hooks, but your project has been using class-based components so far. I was having a great time making a game prototype with react-three-fiber until some model loading code was just like "fuck you, use hooks" and I ended up wrapping a bunch of functional components in special ways to basically isolate the hooks stuff so I don't have to deal with the headache of it all gradually encroaching on the rest of my perfectly functioning project. It's frustrating because every time I wonder how to make it not a mess, the answer is "haha, we lied, they're barely supported; class-based components are for losers and you should feel bad." It's just frustrating. Couldn't they have had the decency to fork / rename React for all this and leave the old branch to die instead of turning the entire space into some kind of pedantic war-zone for several years?
koito17 4y ago
One thing I find strange about the new documentation is how React.createElement is considered a "legacy API". Doesn't JSX transpile into calls to that function anyway? This worries me a bit because some React wrappers for ClojureScript expose macros that essentially compile to React.createElement() calls, which are now labelled as a legacy API. It also looks like Class Components are officially deprecated, given that the documentation explicitly states they are not recommended for use in new code.
- danabramov 4y ago
  JSX has not been compiling to createElement() for a while. (If you have the modern transform enabled.) We're not removing createElement but I'd recommend to change your wrappers to the same compile output that the new JSX transform (introduced in 2020) uses: https://legacy.reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n.... The new JSX compile target will allow us to do a bunch of optimizations in the future that createElement() can't. I'll make a note of adding this to the docs.
- mtone 4y ago
  I notice that ReactDOM.render is also deprecated. In our embedded/plugin component scenario where we are given a <div> to load in, it appears we should replace our current pattern ReactDOM.render(React.createElement(... with createRoot(_jsx(....
  - danabramov 4y ago
    ReactDOM.render has been deprecated since React 18. If you're running React 18 with ReactDOM.render, you should already see an error urging you to switch because essentially ReactDOM.render works in React 17 mode. Yeah you want const root = createRoot(domNode) root.render(<Stuff />) (or the JSX transform output equivalent)
    - mtone 4y ago
      We're not on 18 yet but things are clear, thanks!
ezekg 4y ago
Is there an explanation somewhere on react.dev covering how Hooks actually work under the hood? They're the most magical part of React, and everybody I know (including me) had a hard time actually grasping how they work and why, for example, you can't use a hook inside an if branch. Edit: there are a lot of good--and varied--explanations here. Which is why I think the docs should cover it in-depth. It's confusing.
- simonw 4y ago
  My high level understanding of how they work is that they remember the sequence in which they were called - so if you call the same hook three times, those three calls are held in a list - and future actions that should retrieve them get access to the correct data. If you were to call them in an "if" branch it would mess up that queue mechanism.
- spion 4y ago
  1. They work by setting a global variable to the value of the current component then calling the render function. Whenever you call a hook you're effectivelly dispatching it to the component in question, OOP style. 2. React counts the number of executions of (certain) hooks. This count is how it knows which state to get from the store as a return value from `useState`. useState is effectively `getStateAndSetter()` but it doesn't pass a key name of any kind, so the implicitly passed key is `hookCount++`. This is why you can't call hooks conditionally, or state would get all messed up - if a condition turns false and one hook doesn't run that render, all getStateAndSetter calls that run after it will be off by one.
  - paganel 4y ago
    I know almost nothing about React, let alone React hooks, but all this looks a little hack-etty, doesn't it? Also, I'm curious if there is any similarity between these React hooks and the infamous Drupal hooks.
    - spion 4y ago
      Its absolutely hacketty, yes. Not familiar with Drupal.
deleted 4y ago
[deleted]
benatkin 4y ago
Tell me, if React is so great, why isn't Draft.js blowing ProseMirror out of the water? And why aren't difficult parts of VSCode written with it? I think a good example of where React sits is Deno. The devs who are working on Deno don't seem to have much interest in React, but they are pushing a React framework, Fresh, to make it popular with regular devs. They see the popularity of React and not those who are frustrated with it. One thing is how much typical React code relies on a build step and a bunch of Provider objects. CSS Variables can help make components customizable without having to do CSS in JS. I think Web Components, maybe with Lit or Svelte, are making more sense for beginning devs. With those you don't have to worry that you might need to work on non-react code sometime.
- chatmasta 4y ago
  > I think Web Components, maybe with Lit or Svelte, are making more sense for beginning dev Beginner devs want to get a job, so they should probably spend their time learning the framework that dominates the ecosystem. Lit and Svelte are cool, but I don't think they're a great target for a first time web developer. Svelte maybe. But definitely not Lit - it's a relatively new library and a moving target without a lot of adoption, meaning there is a sparse ecosystem to fall back on, and you'll need to fill in a lot of gaps yourself (both in terms of libraries for common functionality, and docs/stackoverflow answers for telling you how to do things). Experienced devs can read the source and official docs to figure it out, but newbies need more hand holding.
  - benatkin 4y ago
    > Beginner devs want to get a job Yeah, that's the point I'm making about Deno. If Deno's own devs avoid anything similar to React hooks except when they're trying to appeal to the beginning devs, perhaps it would be smart for beginning devs to try to do as the senior devs do, not as they say? The ecosystem of Lit is the web, which has a lot of great stuff like MDN. It lets you simply use what you learn there. No redirection, like React's onChange translating into the input event.
    - chatmasta 4y ago
pupppet 4y ago
Another feather in Tailwind's cap.
- danabramov 4y ago
  Haha :) For what it's worth, the site has been developed by different people over time, so the choice to use Tailwind was made by someone else early on. The team working on the site now doesn't feel strongly about it either way — it's sometimes annoying but overall using it feels really nice! And I'd probably say the same about other CSS solutions too. I think we'll keep it for now. Where it really shines IMO is fast prototyping. But yeah, it's cool. Edit: Ok ok tbh I do like it.
- benatkin 4y ago
  Doesn't appear to be using Docusaurus. Interesting.
  - starkparker 4y ago
    Of course they don't. Docusaurus still doesn't support MDX v2, so they'd be stuck on React 17.
    - danabramov 4y ago
      Docusaurus is a fine project, but we thought it is important to use React very directly — so that we have a good sense of what it feels like to make an app with React.
      - starkparker 4y ago
        Awesome. So now that this has rolled out, can you all help the Docusaurus team figure out how to migrate from MDX v1 to MDX v2, and why it's been so difficult? It's been six months of work and it's to a point where we're considering moving off a React-powered docs solution altogether so we can unblock the rest of our app from getting off React 17.
sibeliuss 4y ago
I was praying for some kind of page dedicated to React Server Components. But alas.
- mattcarrollcode 4y ago
  What would you like to see from a React Server Component page?
  - rrishi 4y ago
    Whatever needs to be there for a new react dev to learn about them
  - sibeliuss 4y ago
    How a team who isn't Next.js or Shopify can implement in their own frameworks, without needing to dig into Next.js sourcecode. The example app released around the announcement is quite old and bare-bones, and I'm sure there have been learnings and other guidelines since then. In short, it would be great to have a little more than a spec and an undocumented webpack plugin to work from.
- rrishi 4y ago
  +1
- danabramov 4y ago
  Not yet, but as the blog post notes, it's going to be a bigger focus now that the first integrations are in progress. For now, we've added a tiny bit about them here: https://react.dev/learn/start-a-new-react-project#which-features-make-up-the-react-teams-full-stack-architecture-vision https://react.dev/learn/start-a-new-react-project#which-feat...
  - sibeliuss 4y ago
    That's exciting news. As mentioned below, it'd be great to have some implementation steps for companies and projects who aren't at the Next.js framework technical level. There must be some middle-ground!
romanhn 4y ago
Kudos to React maintainers for their focus on documentation. A year ago I decided to learn React and the official docs were instrumental in getting me up and running. For context, last time I'd done any serious coding was when I still had to care about IE6 compatibility, so all the modern SPA paradigms had to be picked up from scratch. I spent the afternoon reading the docs and was able to jump right into coding a basic proof-of-concept app that same day. The clarity of writing, the progression of topics, it all hang together very well. Looking forward to the latest iteration here!
- jve 4y ago
  Its like 2 weeks since I had to grasp react, fluentui, react hook forms, webpack and a little more when I started using modules and even more when I used typescript. React clicked really fast, documentation new and old, articles helped get on track really fast. Wiring that all together and taming CRA (Create-react-app) with react-app-rewired to add stuff to webpack, like adding libraries to behave like modules that are NOT modules, packing all with scripts into single html, understanding where are boundaries between fluentui and react (both new to me), setting up monorepo because I separate reusable components from app itself and libs, applying css which I am bad at and stuff like that took more time... complexity just explodes, but less "mental effort" overall achieved by having streamlined build, reusable stuff etc. Otherwise I feel that building app with react takes a lot of "mental effort" away, because you develop a component in isolation which feels simple and when you use that component you don't think about implementation details - it is nicely abstracted away and things just work. Ah, yes, and I'm lucky I got the signal that functional components are way to go and the only place I had to use a small class component when I want to have a component variant for existing class based component from FluentUi where generic types are important and used within `onRenderItem` and various methods: > class LookupBaseInternal extends BasePicker<ILookupResultProps, ILookupPropsInternal> {}
  - jve 4y ago
    Oh, here is another 1 I caught: > There is currently no way to write an error boundary as a function component. However, you don’t have to write the error boundary class yourself. For example, you can use react-error-boundary instead. https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary https://react.dev/reference/react/Component#catching-renderi...
iamsanteri 4y ago
After using Vue for a long time, React felt like an unforgiving piece of cr*p. As time went on and Vue was getting its Composition API while kind of moving in the overall direction of React, I decided to try class-based components and didn’t like them that much (this was a couple of years ago). Recently, I went through these new docs and read and applied the stuff I learned, and I can say it was a surprisingly nice experience. I just needed to get friendly with a composition-ish, functional-ish and JSX-ish way of thinking. Alone the thought of HTML-in-JS instead of JS-in-HTML made me crazy back then (it still kinda does). But when you get the hang of building actual user interfaces instead of just websites, it makes a lot of sense. If you’re comfortable with javascript while daring to take the less-opinionated route as opposed to an all-out framework, you'll simply feel the power! Anyhow… To this day, I still think it’s an unforgiving, crazy beast of a library for a weekend hobbyist developer like me. But I kinda like it now and in big part it’s thanks to hooks, functional components and these new docs. Good job team, and congratulations on finally getting this live!
- danabramov 4y ago
  Thank you! Glad to hear it made things click :)
- eoic 4y ago
  Interesting, I had an opposite experience. I started out using React when using class based components was a way to go then stopped for quite some time. Years ago I had to use React for something and decided to use the new approach with hooks and it was such a painful experience - it was harder to learn and use, also I introduced many ridiculous rendering bugs. I still feel that component based approach was somewhat easier and more straightforward to get into even if more verbose.
  - iamsanteri 4y ago
    Yes, it can be tricky, and sometimes I too catch myself asking, "why is it designed like it is" with regards to hooks, I won't lie. But, there is something there that makes it attractive to me where it was off-putting before. Alone as a complement to more extensive state management libraries, or other tools intended for larger scale apps, it serves as a nice middle-ground solution. You can build your own bits of logic in quite an accessible way now too. In other words, for me personally I feel that there is something distinct and interesting going on here. Finally, if you combine it with the fact that it seems to hold on as the industry standard for jobs, and being useful for native mobile development via React Native, it all comes together nicely in my mind. With its huge ecosystem and closeness to plain vanilla JS, I guess it just makes me simply a bit of a better developer and gives me a new perspective on things. That's that.
kayson 4y ago
Why did react (effectively) get rid of class components? Conceptually, a component seems better represented by an object/class than a procedure/function. And aren't classes just really functions under the hood anyways?
- pyrolistical 4y ago
  The quick answer is Hooks killed class
  - epolanski 4y ago
    We removed boilerplate for higher complexity. We made the 90% cases simpler but overly complicated critical paths. So many useMemo, useEffect, useCallback madness was trivial with basic class component lifecycle.
- yamtaddle 4y ago
  > Why did react (effectively) get rid of class components? Supporting some features for hooks and classes, both, probably would have meant having two implementations in some cases, that might not quite match up as equivalent. More API surface area, more code to test, more combinations and paths to worry about. > And aren't classes just really functions under the hood anyways? Other way around, actually: "functional" components end up represented by an object.
  - robertoandred 4y ago
    > Other way around, actually: "functional" components end up represented by an object. No, they're functions.
    - yamtaddle 4y ago
      Weren't as of a couple years ago—they're represented by an object in the React code. Not the case anymore? I'd be surprised if they'd messed with that, it seemed pretty fundamental to how it operated—hooks were implemented on top of that, for one thing.
nayroclade 4y ago
Unbelievable that they’ve gone ahead launching this, going all in on hooks, while the fundamental problem with them, which was raised in 2018 is still unsolved: https://github.com/facebook/react/issues/14099 https://github.com/facebook/react/issues/14099 And they just handwave it away in the docs with an imaginary future API. Embarrassing.
- aidos 4y ago
  I’ve not read through the thread but I wonder how much of it is effective replaced by the upcoming useEvent hook https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...
  - nayroclade 4y ago
    It might have, but that RFC has been withdrawn.
    - danabramov 4y ago
      The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.
      - 4y ago
gardenhedge 4y ago
React is awesome. When will there be something like it for CSS? I feel like CSS is still a mess.
- blowski 4y ago
  What would such a library do?
  - epolanski 4y ago
    I miss elm-ui https://github.com/mdgriffith/elm-ui https://github.com/mdgriffith/elm-ui
    - lloydatkinson 4y ago
      Did you look at CSS-in-JS/TS that is exactly this? https://styled-components.com/ https://styled-components.com/ https://vanilla-extract.style/ https://vanilla-extract.style/
      - epolanski 4y ago
        I used styled and currently vanilla, I'm not following the comparison with Elm UI.
- madeofpalk 4y ago
  Vanilla Extract is probably worth looking into. I feel like it's the best option out there for "CSS but better".
- christophilus 4y ago
  tailwindcss.com It’s been a game changer for me. I can’t see myself ever going back.
  - gardenhedge 4y ago
    I tried before and didn't love it. Based on how it has been adopted I will have to try again.
foxbee 4y ago
Credit to the React team. The docs prior to this were poor - I believe the team admitted this. From the style of writing, to the style of site, I can tell a lot of effort was put into this. Will check out react this weekend - it's been a couple of years (we've been using svelte)
anthonypz 4y ago
I recently went through the entire beta React docs (took me about 3 weeks) and was blown away by the quality of the tutorials. The live code playgrounds and challenges are amazing. With the recent debate about reactivity and which framework implements it best (solid vs. react vs. vue vs. svelte), I felt that what mattered most to me as a junior dev is the quality of the documentation. I gained a strong enough understanding of the complicated concepts (dependency arrays and the useEffect hook) because the docs were so good. There is always room for improvement in JS land and other frameworks are constantly innovating, but the thing I always fallback to is: how good is the documentation? Side note: I recently took an assessment test on React through Triplebyte and was given an expert level badge (for what it's worth). I think that speaks volumes about the new React docs because that is where I gained most of my React related knowledge.
vbezhenar 4y ago
IMO React is missing hooks to work with promises. I made that hook myself but I think that promises along with AbortSignals (to interrupt promise if React decided to cancel it) are basic JS API and React should just support them out of the box. I saw too much code which deals with async functions in useEffect in a buggy way. Things like ReactQuery are nice but they should not be required. Here's my implementation, for the record: https://pastebin.com/rjj0FDDd https://pastebin.com/rjj0FDDd
- subleq 4y ago
  react-query basically converts promises to hooks
- danabramov 4y ago
  We agree. https://github.com/reactjs/rfcs/pull/229 https://github.com/reactjs/rfcs/pull/229
  - selfmodruntime 4y ago
    You probably won‘t answer, but what do you think of the (imo uncalled for) wishful thinking that react should‘ve stayed in the direction of Class components?
    - sophiebits 4y ago
      Dan wrote an answer today about classes here: https://news.ycombinator.com/item?id=35188669 https://news.ycombinator.com/item?id=35188669
- idkwhoiam 4y ago
  > Here's my implementation, for the record: https://pastebin.com/rjj0FDDd https://pastebin.com/rjj0FDDd This implementation doesn't account for the fact that the promise may settle after the component has been unmounted.
- fireant 4y ago
  Missing standard downstream promise cancellation is arguably one of the bigger problems in the whole javascript ecosystem. In C# almost every async function has a CancellationToken parameter, same in Go with Context. Even after years of writing fullstack javascript this is my first time seeing AbortSignals, probably because nobody uses them. Some libraries, like Axios, handroll their own cancellation mechanisms, but that does not really cut it.
deleted 4y ago
[deleted]
andrewmcwatters 4y ago
Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation. I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me. I'm happy that other people seem to enjoy them without restraint, but obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality. I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years. I think having seen front-end software come and go so many times, I'd rather write some simple utility functions wrapping `Document.createElement()` and use native event handling. Too much fluff in front-end. I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.
- motoxpro 4y ago
  Picked up react in the last 5-6 years and looking at old class component examples confuse me to no end. I guess it’s just what you learned first.
  - andrewmcwatters 4y ago
    :) True. My first web development experiences were on AOL Hometown and reading people's 1337 scripts from dynamicdrive.com. DHTML! Updating PHP scripts over FTP! Shared hosting. Oh right, you meant React wise... yeah...
    - chess_buster 4y ago
      me too
  - Aeolun 4y ago
    I worked with class components first. Built a whole app in them. Now we’ve migrated to functional and I look back at the class based ones wondering how I ever dealt with that. I didn’t want to adopt functional, but let everyone make their own decisions on what to use, and now I’m very happy I did.
anonyfox 4y ago
I‘d love to have a simple way of calling ReactDOM.renderToString() on my express server that does block to actually wait for API calls so that SSR‘ed HTML is populated. I am very willing to trade performance against simplicity here. Besides some explorations for suspense and server components, there doesn’t seem to be any straightforward solution to that problem unfortunately
- alvarlagerlof 4y ago
  Maybe you can fetch the with an await and pass it down as a prop to the component in renderToString?
ddaletski 4y ago
I'm always wondering, why it took web devs so many years to create some meaningful reusable UI components (and I still don't see a wide adoption of something like that)? I just can't understand how reimplementing even such things as simple buttons every time from scratch is productive
- jve 4y ago
  Currently microsoft product line like SharePoint, Dynamics (Power Apps), Office, Teams, etc, etc is based on FluentUI https://developer.microsoft.com/en-us/fluentui#/ https://developer.microsoft.com/en-us/fluentui#/ components that gives also the developers a close enough solution to extend UI within said products.
  - lloydatkinson 4y ago
    Which itself is React, to be clear.
- deleted 4y ago
  [deleted]
- qudat 4y ago
  Because there is a lot of creativity involved when you are placing pixels on a screen. You’d be surprised by how many different ways you can render a button. There is no single abstraction that satisfies all business requirements.
- JCharante 4y ago
  To be fair the designers keep changing the designs of buttons.
patientplatypus 4y ago
[flagged]
- sophiebits 4y ago
  No.
s-xyz 4y ago
Amazing! Love it
chrismsimpson 4y ago
VanillaJS/web standards all the way. I love being able ship something knowing exactly what’s going to end up in the browser. I really don’t get the react cargo cult fad, and when it finally dies it won’t be too soon.
- selfmodruntime 4y ago
  React will never die. It‘s as pervasive than jQuery and has been for a while now.
  - recursive 4y ago
    I'd settle for the hype levels to reach parity with jQuery.
  - chrismsimpson 4y ago
    “React will never die, just like jQuery”. Lol.
    - solumunus 4y ago
      Plenty to be made contracting legacy jQuery projects.
- klysm 4y ago
  Sounds nice for a solo project.
  - chrismsimpson 4y ago
    You know react itself is written in something
    - klysm 4y ago
      Yes that is true, but I'm not sure what you are insinuating.
- 4y ago
jmull 4y ago
I can't figure out why anyone chose to use react... I understand the "it's dominant and has a large ecosystem" argument, but I just can't wrap my head around how enough people chose it for it to reach this position. I've evaluated it a couple times and it just looks poorly conceived. Fixes and "improvements" have rolled in, but they are also poorly conceived and themselves need fixes. Of course I know it might just be me... I didn't get the point of tailwind either, until I used it. But I've also used react for a reasonable sized project and I still don't get it.
- christophilus 4y ago
  What don’t you like, and what do you prefer? I like having view be a function of state (like in traditional web apps, except richly interactive).
  - jmull 4y ago
    It’s more of an idea than a library. The idea’s good but the implementation is awkward and incomplete. You’re endlessly writing boilerplate and incorporating libraries for even basic and typical cases that a more thoughtful design would make unnecessary. Even with multiple evolutions the problems are only somewhat resolved. The virtual DOM was a bad idea from day 1 and remains so. React wants components to be the unit of rendering, but an app wants a component to be a unit of app UI. These concerns end of conflicting and competing, which the dev has to do the heavy lifting to resolve, with things like useMemo/Callback. It uses javascript to represent HTML (HTML is already the ideal way to represent HTML declaratively). > what do you prefer Svelte, for the case you mention.
    - spion 4y ago
      > HTML is already the ideal way to represent HTML declaratively I'm curious what you mean by "declaratively", and I wonder why everyone puts so much value into that particular idea. What is declarative? Is it different/better than using pure functions? Why? If not, why doesn't HTML have (pure) functions?
sroussey 4y ago
Using react server components these days and don’t see much about it.
codeptualize 4y ago
Why are so many comments about class components, I thought we ended that debate 3 years ago? Hooks are better because they allow you to reuse component logic, impossible with class components. They solve all the issues and gotcha's of HOC's. Don't compare class components with hooks, compare HOC's with hooks. The best way to grow appreciation for hooks is to try wrapping many HOC's and deal with conflicting props and "innerRefs". People seem to very easily forget the horrors of the old. Also lets be real, hooks aren't that bad. Yes dependencies arrays and useEffect take some getting used to, but I rarely get into situations where I actually get into questionable territory. Use react-query/swr for fetching, use Zustand (or whatever) for state, and you cut out 95% of the problems. Anyway, the new docs are great, well done, nice work!
- robertoandred 4y ago
  [flagged]
- spankalee 4y ago
  Hooks are much worse because they poorly emulate classes. What you need for components is a stateful container, with an initialization phase, a render function that can be called for each update, and lifecycle methods that are called at lifecycle events. Classes give you exactly this: - Constructor for initialization - Class fields for state - A method for rendering that can be called multiple times, which can reference state - Lifecycle methods Classes are simple, standard, and give you everything you need for UI components. They were practically invented alongside the concept of UI components. Hooks try to cram all of this into the repeatedly called render method and it's just a failure. - You have to put initialization into callbacks because the whole component is called multiple times - It's difficult to manage object and callback identity across renders requiring useCallback() and useState() to fix - Lifecycle callbacks are put into hook arguments, but they're just trying to be methods and end up recreating the lifecycle closure every render. - Hooks have restrictive rules on their usage - Hooks make a function no longer just a function. It needs to be invoked inside a hook context, making it much less portable than a constructor - Hooks hide their state within the hooks system, making them much harder to introspect and debug. Hooks supposedly solve this composition problem and allow reusing logic, but that is entirely possible with classes. It's just a huge amount of FUD and misinformation to say that you can't do composition with objects. All you need is an object interface that is similar to the component interface that the component delegates to from its lifecycle methods. This is a simple and standard pattern to use and implement: it's just a single line of code per lifecycle method. And it's easily introspectable with a debugger: just follow object references to the helper objects. lit.dev does with with reactive controllers: https://lit.dev/docs/composition/controllers/ https://lit.dev/docs/composition/controllers/ It's a very simple alternative to custom hooks, and eliminates the need for all the builtin hooks.
interstice 4y ago
Is there a hook for an error boundary component yet or is a class component still the easiest way?
- sophiebits 4y ago
  Not yet! Other improvements have been higher priority so far. Many people also use the react-error-boundary npm package, and some frameworks have their own error boundary APIs (eg: https://beta.nextjs.org/docs/routing/error-handling https://beta.nextjs.org/docs/routing/error-handling).
  - klysm 4y ago
    I encourage people to copy what they need out of react-error-boundary and tightly integrate it with their stack. It’s really not bad
Vinnl 4y ago
Hmm, I can't find the "Edit this page" link that many Docusarus (which I assume this is?) sites often have, and I can't find the repo either, so I can't submit a PR, but... There's no RSS feed for the blog :(
- sophiebits 4y ago
  Not Docusaurus, but the source is here: https://github.com/reactjs/reactjs.org https://github.com/reactjs/reactjs.org (currently in the "beta" directory)
  - Vinnl 4y ago
    Thank you! Makes it a bit more work, but maybe I'll look at submitting a PR later.
Diggsey 4y ago
All of the new documentation is horribly laggy in Firefox and all of the code sections are broken (eg. the visible cursor position does not match the actual cursor position...) This is latest stable Firefox on a high spec Windows 10 laptop. Not a great look given what React is supposed to do!
debacle 4y ago
I like classes because they're easier to code review and easier to read/reason about. The artifical limitations are good. At a large org that's way more important than initial write.
rglover 4y ago
Oh, weary traveler, if yer tired of your APIs a changin' join us o'er at the Joystick [1] and enjoy a stable sea like y've never seen bafore. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
funstuff007 4y ago
> We’ve included diagrams, illustrations, challenges, and over 600 new interactive examples. 600! It's hard for the competition to keep up with that.
adamzerner 4y ago
I've never understood why React components are considered to be pure. The output is not just a function of the props, it's also a function of the state (as in `useState`) and context (as in `useContext`).
- klysm 4y ago
  Agree, but it should be a pure function of its arguments and the state
isntbilly 4y ago
F
jerrygoyal 4y ago
People tend to overuse Effect, this article explains it well https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
megous 4y ago
Nice demo of sluggishness of React: https://react.dev/learn/updating-objects-in-state https://react.dev/learn/updating-objects-in-state https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm (Top of the line desktop AMD chip.) The code has no transition, no setTimeout, no nothing that would indicate any delay. The dot should always be right under the cursor. This will happen with every similar UI pattern (want to resize something, move a slider, etc. etc.) I guess this is a result of tradeoffs React has to do by insulating people from DOM. There's probably some way to force immediate DOM update, but then you're pulling in a lot of useless diffing and checking for each frame, instead of just updating the single el.style.something property you'd do when directly using DOM API and leaving the browser to do the rest.
- senttoschool 4y ago
  >(Top of the line desktop AMD chip.) Slightly off topic but my M1 Pro Apple Silicon Mac does not lag like your top of the line AMD chip. I know most consumers run React code with CPUs slower than Apple Silicon chips but this post is more of an endorsement for the M1 lineup.
  - megous 4y ago
    You're comparing different software rather than different CPUs.
  - geodel 4y ago
    This is relief. I was afraid that M1 Max would be minimum requirement for smooth experience.
    - senttoschool 4y ago
      I know your post is sarcasm but a base M1 would perform the same as M1 Pro, Max, Ultra in this case. It's the single thread speed that matters the most in web performance. So you just need an M1. The M1 Air is frequently on sale for $800 nowadays. Or if you're really on a budget, you can buy a used M1 Mini on eBay for $400. Very affordable for those who want high browser performance.
njsubedi 4y ago
It’s funny how react.com redirects to reactjs.org and that redirects to react.dev domain because most companies only use newer tlds because dotcoms are unavailable
intellix 4y ago
You can pretty much skip React and go straight to Qwik as it solves N+1 and it fixes the ability for low quality devs ruining perf with useEffect since you have signals ala Solid
tomgp 4y ago
Lovely site but it got my hackles up right off the bat ... > "The library for web and native user interfaces" _A_ library, it's _a_ library not _the_ library.
liendolucas 4y ago
I was relatively happy with the React class model, for me it was very clear just to override any required methods in a class. To this day if I need to do something in React I can pick it up quickly because is a very simple model: it follows the template design pattern, which is one of the most powerful and dumb design patterns (I'm talking obviously about the class model). What's my current issue with React? Well in the same way that they have decided to go with hooks and all that, nothing is preventing those folks tomorrow to wake up to say: "You know what? What we really really need is not functional components but a hybrid approach, not fully functional not fully object oriented" and then the game starts again. I worked for a very limited time in one company not long ago, and a guy there came and said something like: "We really should start using hooks" and I replied: "Really? Why? Can you show me a true or concrete advantage using the functional style over the OO approach?" then he said: "Well, I don't really need to do that just watch this video" and sent me a link of a video (if I recall correctly) of the creators explaining all the hooks stuff. I didn't even bothered to continue discussing (how can you discuss when someone is 100% biased?). My point is that many people out there just take for granted whatever ideas these people are pushing out and not questioning things anymore. I'm not saying that hooks are good or bad a thing (I really don't know and if I need to learn hooks because that's the style used in a codebase, sure I'll do it and probably learn something), but blindly embracing things just for nothing is harmful.
- ruicaridade 4y ago
  To me, the main benefit of react hooks is it eliminates higher-order component hell. It's so much easier to extract common behaviour from different components to a re-useable hook, rather than wrapping a class with a million different higher-order components: `withRouter(withFoo(withBar(MyComponent)))`.
- codingdave 4y ago
  When hooks came out, myself and the other senior devs on our team had that same inertia-driven reaction. We knew classes, we were comfortable with classes, and they worked. So we asked the same question - "Why hooks?" So we sat down and actually used hooks for a few days - refactored small and large components to be sure we understood them and saw the difference in the code. We found it to be a perspective change -- once we made that change and got used to the new syntax, we loved it. Our code was simpler and easier to maintain. Once we really learned when to use useEffect so as to not abuse it for everything under the sun... the code got better still. So while you are correct that blindly embracing hooks would be harmful... Blindly rejecting them is equally harmful.
deleted 4y ago
[deleted]
DyingAdonis 4y ago
React is a leaky abstraction. https://twitter.com/clark_gunn/status/1636565797412773888 https://twitter.com/clark_gunn/status/1636565797412773888
- FractalHQ 4y ago
  As someone who learned web dev with Svelte, it seems so obvious to me that React is full of convoluted apis born from tech debt, and such a bad DX compared to what is possible today. I imagine if I learned React first, it wouldn’t be nearly as obvious to me how mush worse it is than it should be.

748 points by clessg 4y ago

deleted 4y ago

[deleted]

I've been using I think the beta version of this recently, it's definitely an improvement and makes the react api seem a lot more coherent than the old version. I'm glad they fixed the janky scrolling though that has been cracking me up for a while. It's an example of a common complaint/pitfall with react and even the official docs were plagued by it. As a heavy react user and light react hater I love to see that shit lol.

danabramov 4y ago
Please don't hesitate to report things like janky scrolling to the issue tracker (https://github.com/reactjs/reactjs.org/issues https://github.com/reactjs/reactjs.org/issues). We were changing things a lot and I'm sure a bunch of regressions could've crept in, so all reports are super helpful.
- matsemann 4y ago
  The page you linked here https://news.ycombinator.com/item?id=35187407 https://news.ycombinator.com/item?id=35187407 Is basically useless when scrolling. All I see is a gray background, and when I stop the content disappears. Makes it hard to quickly skim to the correct section.
  - pests 4y ago
    I have no trouble on my end scrolling that page.
    - matsemann 4y ago
      On desktop it works "fine", problem is that the scroll gets caught inside every code window on the way down. So scroll the page a bit, cursor above an example, scroll the example until end, then page keep on scrolling, then stuck on a new example etc. On mobile it just blanks when scrolling.

explodingcamera 4y ago

Looks really nice! Also, super happy that the interactive examples are not super sluggish code sandbox iframes, they're actually usable! A more typescript-first approach would have been nice, or at least typescript/JavaScript toggles, but the React team seems to be aware that that's an area they need to work on.

johnny_canuck 4y ago
That is something I really dislike about the react-query docs, the examples are code sandboxes. Glad to see they didn't go that path here. I find they add a lot of friction when I am looking for a quick reference.
danabramov 4y ago
Yeah we'd like to add TS throughout but it will require some technical and some content work. We didn't want to block the release on that.
- johtso 4y ago
  The sexiest example I've seen is in the XState docs.. not sure what they're using to get the types into the tooltips.. https://stately.ai/docs/xstate/running-machines/react#usemachine-hook https://stately.ai/docs/xstate/running-machines/react#usemac...
  - nawgz 4y ago
    Looks like Shiki: https://github.com/shikijs/shiki https://github.com/shikijs/shiki If you "inspect" the elements with the mouseovers, you can see they statically compiled the TS definition into the HTML. I guess it probably uses the same APIs to read the types VSCode does, given what they state the purpose of Shiki is.
  - afidrya 4y ago
    It's Docusaurus 2 + TwoSlash: https://docusaurus.io/blog/2022/08/01/announcing-docusaurus-2.0 https://docusaurus.io/blog/2022/08/01/announcing-docusaurus-...

airstrike 4y ago

> Believe it or not, React will soon be ten years old. In JavaScript years, it’s like a whole century! Hilarious! As someone who was once a "full-stack" web dev in the age of jQuery, CSS resets and local fonts only, this definitely rings true. And having just started learning React (through Next.js), this is a timely and welcome refresh! Thank you!

epolanski 4y ago
React's first implementation (on top of Ocaml) is from 2011 I believe.

benrutter 4y ago

Looks like some good resources and a neat redesign. The domain move makes me realise how odd it was that before they had 'org', which is normally used by charities/non-profits. I'm guessing Typescript is the force behind dropping 'js' from out of the domain too.

sophiebits 4y ago
As the person who most often pushed for .org, I can say it was because I wanted to emphasize the community nature. React isn’t a commercial offering. (I had to talk the team out of react.com as the main brand for this launch; although that URL works, I think react.dev is more reflective than .com of what we’re trying to do.)

waboremo 4y ago

Finally! Although looks like Google still has to update so newcomers are likely still going to head to the legacy docs and not realize it (and the legacy page still links to beta.reactjs.org vs react.dev). A tremendous improvement though, and it must have been a lot of work coordinating, especially the easier to digest images sprinkled throughout. At last we can officially move past the era of class components.

danabramov 4y ago
We'll make the legacy site binner a bit more prominent and clear -- thanks for feedback. I planned to but got distracted with other things during deployment.
- waboremo 4y ago
  Perfectly understandable, it's a huge change and these smaller things fly under the radar easily. Congrats to you and the team for pulling off the major transition smoothly!

explaininjs 4y ago

Are class components really on the down & out? I tried going all in on hooks with a complicated app using lots of web workers and generally heavy computation and complex logic (a game). It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear. Having a dedicated place to process changes in props and setup/teardown logic is just generally nicer than weird dependency arrays and returning destructors from effects.

bottlepalm 4y ago
I think generally you should start with functional components, try to keep things simple, and use class components as the exception and not the rule. My own app is mostly functional components, but I did fall back on a class component in a case where I needed the lifted state of a function reference to remain current across renders.
phphphphp 4y ago
Most React codebases benefit from the simplicity of functional components, because they fit into the model most people have of websites + web apps. If you’re doing anything complex, you’re in a very small group.
- Klonoar 4y ago
  I would argue the inverse: if your project relatively simple enough that hooks don't feel messy, then it probably doesn't need to be a React app to begin with. Class components are just (IMO) cleaner, and I find myself saddened at the level of disarray most codebases with hooks are nowadays. Enough has been written elsewhere about how hooks require one to keep more in their head; class components have an agreed up layout/structure/etc that is important in large codebases.
  - dylan-m 4y ago
    The most frustrating part of this is when you run into some library that is all in on hooks and insists you use hooks, but your project has been using class-based components so far. I was having a great time making a game prototype with react-three-fiber until some model loading code was just like "fuck you, use hooks" and I ended up wrapping a bunch of functional components in special ways to basically isolate the hooks stuff so I don't have to deal with the headache of it all gradually encroaching on the rest of my perfectly functioning project. It's frustrating because every time I wonder how to make it not a mess, the answer is "haha, we lied, they're barely supported; class-based components are for losers and you should feel bad." It's just frustrating. Couldn't they have had the decency to fork / rename React for all this and leave the old branch to die instead of turning the entire space into some kind of pedantic war-zone for several years?

koito17 4y ago

One thing I find strange about the new documentation is how React.createElement is considered a "legacy API". Doesn't JSX transpile into calls to that function anyway? This worries me a bit because some React wrappers for ClojureScript expose macros that essentially compile to React.createElement() calls, which are now labelled as a legacy API. It also looks like Class Components are officially deprecated, given that the documentation explicitly states they are not recommended for use in new code.

danabramov 4y ago
JSX has not been compiling to createElement() for a while. (If you have the modern transform enabled.) We're not removing createElement but I'd recommend to change your wrappers to the same compile output that the new JSX transform (introduced in 2020) uses: https://legacy.reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n.... The new JSX compile target will allow us to do a bunch of optimizations in the future that createElement() can't. I'll make a note of adding this to the docs.
mtone 4y ago
I notice that ReactDOM.render is also deprecated. In our embedded/plugin component scenario where we are given a <div> to load in, it appears we should replace our current pattern ReactDOM.render(React.createElement(... with createRoot(_jsx(....
- danabramov 4y ago
  ReactDOM.render has been deprecated since React 18. If you're running React 18 with ReactDOM.render, you should already see an error urging you to switch because essentially ReactDOM.render works in React 17 mode. Yeah you want const root = createRoot(domNode) root.render(<Stuff />) (or the JSX transform output equivalent)
  - mtone 4y ago
    We're not on 18 yet but things are clear, thanks!

ezekg 4y ago

Is there an explanation somewhere on react.dev covering how Hooks actually work under the hood? They're the most magical part of React, and everybody I know (including me) had a hard time actually grasping how they work and why, for example, you can't use a hook inside an if branch. Edit: there are a lot of good--and varied--explanations here. Which is why I think the docs should cover it in-depth. It's confusing.

simonw 4y ago
My high level understanding of how they work is that they remember the sequence in which they were called - so if you call the same hook three times, those three calls are held in a list - and future actions that should retrieve them get access to the correct data. If you were to call them in an "if" branch it would mess up that queue mechanism.
spion 4y ago
1. They work by setting a global variable to the value of the current component then calling the render function. Whenever you call a hook you're effectivelly dispatching it to the component in question, OOP style. 2. React counts the number of executions of (certain) hooks. This count is how it knows which state to get from the store as a return value from `useState`. useState is effectively `getStateAndSetter()` but it doesn't pass a key name of any kind, so the implicitly passed key is `hookCount++`. This is why you can't call hooks conditionally, or state would get all messed up - if a condition turns false and one hook doesn't run that render, all getStateAndSetter calls that run after it will be off by one.
- paganel 4y ago
  I know almost nothing about React, let alone React hooks, but all this looks a little hack-etty, doesn't it? Also, I'm curious if there is any similarity between these React hooks and the infamous Drupal hooks.
  - spion 4y ago
    Its absolutely hacketty, yes. Not familiar with Drupal.

deleted 4y ago

[deleted]

benatkin 4y ago

Tell me, if React is so great, why isn't Draft.js blowing ProseMirror out of the water? And why aren't difficult parts of VSCode written with it? I think a good example of where React sits is Deno. The devs who are working on Deno don't seem to have much interest in React, but they are pushing a React framework, Fresh, to make it popular with regular devs. They see the popularity of React and not those who are frustrated with it. One thing is how much typical React code relies on a build step and a bunch of Provider objects. CSS Variables can help make components customizable without having to do CSS in JS. I think Web Components, maybe with Lit or Svelte, are making more sense for beginning devs. With those you don't have to worry that you might need to work on non-react code sometime.

chatmasta 4y ago
> I think Web Components, maybe with Lit or Svelte, are making more sense for beginning dev Beginner devs want to get a job, so they should probably spend their time learning the framework that dominates the ecosystem. Lit and Svelte are cool, but I don't think they're a great target for a first time web developer. Svelte maybe. But definitely not Lit - it's a relatively new library and a moving target without a lot of adoption, meaning there is a sparse ecosystem to fall back on, and you'll need to fill in a lot of gaps yourself (both in terms of libraries for common functionality, and docs/stackoverflow answers for telling you how to do things). Experienced devs can read the source and official docs to figure it out, but newbies need more hand holding.
- benatkin 4y ago
  > Beginner devs want to get a job Yeah, that's the point I'm making about Deno. If Deno's own devs avoid anything similar to React hooks except when they're trying to appeal to the beginning devs, perhaps it would be smart for beginning devs to try to do as the senior devs do, not as they say? The ecosystem of Lit is the web, which has a lot of great stuff like MDN. It lets you simply use what you learn there. No redirection, like React's onChange translating into the input event.
  - chatmasta 4y ago

pupppet 4y ago

Another feather in Tailwind's cap.

danabramov 4y ago
Haha :) For what it's worth, the site has been developed by different people over time, so the choice to use Tailwind was made by someone else early on. The team working on the site now doesn't feel strongly about it either way — it's sometimes annoying but overall using it feels really nice! And I'd probably say the same about other CSS solutions too. I think we'll keep it for now. Where it really shines IMO is fast prototyping. But yeah, it's cool. Edit: Ok ok tbh I do like it.
benatkin 4y ago
Doesn't appear to be using Docusaurus. Interesting.
- starkparker 4y ago
  Of course they don't. Docusaurus still doesn't support MDX v2, so they'd be stuck on React 17.
  - danabramov 4y ago
    Docusaurus is a fine project, but we thought it is important to use React very directly — so that we have a good sense of what it feels like to make an app with React.
    - starkparker 4y ago
      Awesome. So now that this has rolled out, can you all help the Docusaurus team figure out how to migrate from MDX v1 to MDX v2, and why it's been so difficult? It's been six months of work and it's to a point where we're considering moving off a React-powered docs solution altogether so we can unblock the rest of our app from getting off React 17.

sibeliuss 4y ago

I was praying for some kind of page dedicated to React Server Components. But alas.

mattcarrollcode 4y ago
What would you like to see from a React Server Component page?
- rrishi 4y ago
  Whatever needs to be there for a new react dev to learn about them
- sibeliuss 4y ago
  How a team who isn't Next.js or Shopify can implement in their own frameworks, without needing to dig into Next.js sourcecode. The example app released around the announcement is quite old and bare-bones, and I'm sure there have been learnings and other guidelines since then. In short, it would be great to have a little more than a spec and an undocumented webpack plugin to work from.
rrishi 4y ago
+1
danabramov 4y ago
Not yet, but as the blog post notes, it's going to be a bigger focus now that the first integrations are in progress. For now, we've added a tiny bit about them here: https://react.dev/learn/start-a-new-react-project#which-features-make-up-the-react-teams-full-stack-architecture-vision https://react.dev/learn/start-a-new-react-project#which-feat...
- sibeliuss 4y ago
  That's exciting news. As mentioned below, it'd be great to have some implementation steps for companies and projects who aren't at the Next.js framework technical level. There must be some middle-ground!

romanhn 4y ago

Kudos to React maintainers for their focus on documentation. A year ago I decided to learn React and the official docs were instrumental in getting me up and running. For context, last time I'd done any serious coding was when I still had to care about IE6 compatibility, so all the modern SPA paradigms had to be picked up from scratch. I spent the afternoon reading the docs and was able to jump right into coding a basic proof-of-concept app that same day. The clarity of writing, the progression of topics, it all hang together very well. Looking forward to the latest iteration here!

jve 4y ago
Its like 2 weeks since I had to grasp react, fluentui, react hook forms, webpack and a little more when I started using modules and even more when I used typescript. React clicked really fast, documentation new and old, articles helped get on track really fast. Wiring that all together and taming CRA (Create-react-app) with react-app-rewired to add stuff to webpack, like adding libraries to behave like modules that are NOT modules, packing all with scripts into single html, understanding where are boundaries between fluentui and react (both new to me), setting up monorepo because I separate reusable components from app itself and libs, applying css which I am bad at and stuff like that took more time... complexity just explodes, but less "mental effort" overall achieved by having streamlined build, reusable stuff etc. Otherwise I feel that building app with react takes a lot of "mental effort" away, because you develop a component in isolation which feels simple and when you use that component you don't think about implementation details - it is nicely abstracted away and things just work. Ah, yes, and I'm lucky I got the signal that functional components are way to go and the only place I had to use a small class component when I want to have a component variant for existing class based component from FluentUi where generic types are important and used within `onRenderItem` and various methods: > class LookupBaseInternal extends BasePicker<ILookupResultProps, ILookupPropsInternal> {}
- jve 4y ago
  Oh, here is another 1 I caught: > There is currently no way to write an error boundary as a function component. However, you don’t have to write the error boundary class yourself. For example, you can use react-error-boundary instead. https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary https://react.dev/reference/react/Component#catching-renderi...

iamsanteri 4y ago

After using Vue for a long time, React felt like an unforgiving piece of cr*p. As time went on and Vue was getting its Composition API while kind of moving in the overall direction of React, I decided to try class-based components and didn’t like them that much (this was a couple of years ago). Recently, I went through these new docs and read and applied the stuff I learned, and I can say it was a surprisingly nice experience. I just needed to get friendly with a composition-ish, functional-ish and JSX-ish way of thinking. Alone the thought of HTML-in-JS instead of JS-in-HTML made me crazy back then (it still kinda does). But when you get the hang of building actual user interfaces instead of just websites, it makes a lot of sense. If you’re comfortable with javascript while daring to take the less-opinionated route as opposed to an all-out framework, you'll simply feel the power! Anyhow… To this day, I still think it’s an unforgiving, crazy beast of a library for a weekend hobbyist developer like me. But I kinda like it now and in big part it’s thanks to hooks, functional components and these new docs. Good job team, and congratulations on finally getting this live!

danabramov 4y ago
Thank you! Glad to hear it made things click :)
eoic 4y ago
Interesting, I had an opposite experience. I started out using React when using class based components was a way to go then stopped for quite some time. Years ago I had to use React for something and decided to use the new approach with hooks and it was such a painful experience - it was harder to learn and use, also I introduced many ridiculous rendering bugs. I still feel that component based approach was somewhat easier and more straightforward to get into even if more verbose.
- iamsanteri 4y ago
  Yes, it can be tricky, and sometimes I too catch myself asking, "why is it designed like it is" with regards to hooks, I won't lie. But, there is something there that makes it attractive to me where it was off-putting before. Alone as a complement to more extensive state management libraries, or other tools intended for larger scale apps, it serves as a nice middle-ground solution. You can build your own bits of logic in quite an accessible way now too. In other words, for me personally I feel that there is something distinct and interesting going on here. Finally, if you combine it with the fact that it seems to hold on as the industry standard for jobs, and being useful for native mobile development via React Native, it all comes together nicely in my mind. With its huge ecosystem and closeness to plain vanilla JS, I guess it just makes me simply a bit of a better developer and gives me a new perspective on things. That's that.

kayson 4y ago

Why did react (effectively) get rid of class components? Conceptually, a component seems better represented by an object/class than a procedure/function. And aren't classes just really functions under the hood anyways?

pyrolistical 4y ago
The quick answer is Hooks killed class
- epolanski 4y ago
  We removed boilerplate for higher complexity. We made the 90% cases simpler but overly complicated critical paths. So many useMemo, useEffect, useCallback madness was trivial with basic class component lifecycle.
yamtaddle 4y ago
> Why did react (effectively) get rid of class components? Supporting some features for hooks and classes, both, probably would have meant having two implementations in some cases, that might not quite match up as equivalent. More API surface area, more code to test, more combinations and paths to worry about. > And aren't classes just really functions under the hood anyways? Other way around, actually: "functional" components end up represented by an object.
- robertoandred 4y ago
  > Other way around, actually: "functional" components end up represented by an object. No, they're functions.
  - yamtaddle 4y ago
    Weren't as of a couple years ago—they're represented by an object in the React code. Not the case anymore? I'd be surprised if they'd messed with that, it seemed pretty fundamental to how it operated—hooks were implemented on top of that, for one thing.

nayroclade 4y ago

Unbelievable that they’ve gone ahead launching this, going all in on hooks, while the fundamental problem with them, which was raised in 2018 is still unsolved: https://github.com/facebook/react/issues/14099 https://github.com/facebook/react/issues/14099 And they just handwave it away in the docs with an imaginary future API. Embarrassing.

aidos 4y ago
I’ve not read through the thread but I wonder how much of it is effective replaced by the upcoming useEvent hook https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...
- nayroclade 4y ago
  It might have, but that RFC has been withdrawn.
  - danabramov 4y ago
    The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.
    - 4y ago

gardenhedge 4y ago

React is awesome. When will there be something like it for CSS? I feel like CSS is still a mess.

blowski 4y ago
What would such a library do?
- epolanski 4y ago
  I miss elm-ui https://github.com/mdgriffith/elm-ui https://github.com/mdgriffith/elm-ui
  - lloydatkinson 4y ago
    Did you look at CSS-in-JS/TS that is exactly this? https://styled-components.com/ https://styled-components.com/ https://vanilla-extract.style/ https://vanilla-extract.style/
    - epolanski 4y ago
      I used styled and currently vanilla, I'm not following the comparison with Elm UI.
madeofpalk 4y ago
Vanilla Extract is probably worth looking into. I feel like it's the best option out there for "CSS but better".
christophilus 4y ago
tailwindcss.com It’s been a game changer for me. I can’t see myself ever going back.
- gardenhedge 4y ago
  I tried before and didn't love it. Based on how it has been adopted I will have to try again.

foxbee 4y ago

Credit to the React team. The docs prior to this were poor - I believe the team admitted this. From the style of writing, to the style of site, I can tell a lot of effort was put into this. Will check out react this weekend - it's been a couple of years (we've been using svelte)

anthonypz 4y ago

I recently went through the entire beta React docs (took me about 3 weeks) and was blown away by the quality of the tutorials. The live code playgrounds and challenges are amazing. With the recent debate about reactivity and which framework implements it best (solid vs. react vs. vue vs. svelte), I felt that what mattered most to me as a junior dev is the quality of the documentation. I gained a strong enough understanding of the complicated concepts (dependency arrays and the useEffect hook) because the docs were so good. There is always room for improvement in JS land and other frameworks are constantly innovating, but the thing I always fallback to is: how good is the documentation? Side note: I recently took an assessment test on React through Triplebyte and was given an expert level badge (for what it's worth). I think that speaks volumes about the new React docs because that is where I gained most of my React related knowledge.

vbezhenar 4y ago

IMO React is missing hooks to work with promises. I made that hook myself but I think that promises along with AbortSignals (to interrupt promise if React decided to cancel it) are basic JS API and React should just support them out of the box. I saw too much code which deals with async functions in useEffect in a buggy way. Things like ReactQuery are nice but they should not be required. Here's my implementation, for the record: https://pastebin.com/rjj0FDDd https://pastebin.com/rjj0FDDd

subleq 4y ago
react-query basically converts promises to hooks
danabramov 4y ago
We agree. https://github.com/reactjs/rfcs/pull/229 https://github.com/reactjs/rfcs/pull/229
- selfmodruntime 4y ago
  You probably won‘t answer, but what do you think of the (imo uncalled for) wishful thinking that react should‘ve stayed in the direction of Class components?
  - sophiebits 4y ago
    Dan wrote an answer today about classes here: https://news.ycombinator.com/item?id=35188669 https://news.ycombinator.com/item?id=35188669
idkwhoiam 4y ago
> Here's my implementation, for the record: https://pastebin.com/rjj0FDDd https://pastebin.com/rjj0FDDd This implementation doesn't account for the fact that the promise may settle after the component has been unmounted.
fireant 4y ago
Missing standard downstream promise cancellation is arguably one of the bigger problems in the whole javascript ecosystem. In C# almost every async function has a CancellationToken parameter, same in Go with Context. Even after years of writing fullstack javascript this is my first time seeing AbortSignals, probably because nobody uses them. Some libraries, like Axios, handroll their own cancellation mechanisms, but that does not really cut it.

deleted 4y ago

[deleted]

andrewmcwatters 4y ago

Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation. I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me. I'm happy that other people seem to enjoy them without restraint, but obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality. I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years. I think having seen front-end software come and go so many times, I'd rather write some simple utility functions wrapping `Document.createElement()` and use native event handling. Too much fluff in front-end. I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

motoxpro 4y ago
Picked up react in the last 5-6 years and looking at old class component examples confuse me to no end. I guess it’s just what you learned first.
- andrewmcwatters 4y ago
  :) True. My first web development experiences were on AOL Hometown and reading people's 1337 scripts from dynamicdrive.com. DHTML! Updating PHP scripts over FTP! Shared hosting. Oh right, you meant React wise... yeah...
  - chess_buster 4y ago
    me too
- Aeolun 4y ago
  I worked with class components first. Built a whole app in them. Now we’ve migrated to functional and I look back at the class based ones wondering how I ever dealt with that. I didn’t want to adopt functional, but let everyone make their own decisions on what to use, and now I’m very happy I did.

anonyfox 4y ago

I‘d love to have a simple way of calling ReactDOM.renderToString() on my express server that does block to actually wait for API calls so that SSR‘ed HTML is populated. I am very willing to trade performance against simplicity here. Besides some explorations for suspense and server components, there doesn’t seem to be any straightforward solution to that problem unfortunately

alvarlagerlof 4y ago
Maybe you can fetch the with an await and pass it down as a prop to the component in renderToString?

ddaletski 4y ago

I'm always wondering, why it took web devs so many years to create some meaningful reusable UI components (and I still don't see a wide adoption of something like that)? I just can't understand how reimplementing even such things as simple buttons every time from scratch is productive

jve 4y ago
Currently microsoft product line like SharePoint, Dynamics (Power Apps), Office, Teams, etc, etc is based on FluentUI https://developer.microsoft.com/en-us/fluentui#/ https://developer.microsoft.com/en-us/fluentui#/ components that gives also the developers a close enough solution to extend UI within said products.
- lloydatkinson 4y ago
  Which itself is React, to be clear.
deleted 4y ago
[deleted]
qudat 4y ago
Because there is a lot of creativity involved when you are placing pixels on a screen. You’d be surprised by how many different ways you can render a button. There is no single abstraction that satisfies all business requirements.
JCharante 4y ago
To be fair the designers keep changing the designs of buttons.

patientplatypus 4y ago

[flagged]

sophiebits 4y ago
No.

s-xyz 4y ago

Amazing! Love it

chrismsimpson 4y ago

VanillaJS/web standards all the way. I love being able ship something knowing exactly what’s going to end up in the browser. I really don’t get the react cargo cult fad, and when it finally dies it won’t be too soon.

selfmodruntime 4y ago
React will never die. It‘s as pervasive than jQuery and has been for a while now.
- recursive 4y ago
  I'd settle for the hype levels to reach parity with jQuery.
- chrismsimpson 4y ago
  “React will never die, just like jQuery”. Lol.
  - solumunus 4y ago
    Plenty to be made contracting legacy jQuery projects.
klysm 4y ago
Sounds nice for a solo project.
- chrismsimpson 4y ago
  You know react itself is written in something
  - klysm 4y ago
    Yes that is true, but I'm not sure what you are insinuating.
4y ago

jmull 4y ago

I can't figure out why anyone chose to use react... I understand the "it's dominant and has a large ecosystem" argument, but I just can't wrap my head around how enough people chose it for it to reach this position. I've evaluated it a couple times and it just looks poorly conceived. Fixes and "improvements" have rolled in, but they are also poorly conceived and themselves need fixes. Of course I know it might just be me... I didn't get the point of tailwind either, until I used it. But I've also used react for a reasonable sized project and I still don't get it.

christophilus 4y ago
What don’t you like, and what do you prefer? I like having view be a function of state (like in traditional web apps, except richly interactive).
- jmull 4y ago
  It’s more of an idea than a library. The idea’s good but the implementation is awkward and incomplete. You’re endlessly writing boilerplate and incorporating libraries for even basic and typical cases that a more thoughtful design would make unnecessary. Even with multiple evolutions the problems are only somewhat resolved. The virtual DOM was a bad idea from day 1 and remains so. React wants components to be the unit of rendering, but an app wants a component to be a unit of app UI. These concerns end of conflicting and competing, which the dev has to do the heavy lifting to resolve, with things like useMemo/Callback. It uses javascript to represent HTML (HTML is already the ideal way to represent HTML declaratively). > what do you prefer Svelte, for the case you mention.
  - spion 4y ago
    > HTML is already the ideal way to represent HTML declaratively I'm curious what you mean by "declaratively", and I wonder why everyone puts so much value into that particular idea. What is declarative? Is it different/better than using pure functions? Why? If not, why doesn't HTML have (pure) functions?

sroussey 4y ago

Using react server components these days and don’t see much about it.

codeptualize 4y ago

Why are so many comments about class components, I thought we ended that debate 3 years ago? Hooks are better because they allow you to reuse component logic, impossible with class components. They solve all the issues and gotcha's of HOC's. Don't compare class components with hooks, compare HOC's with hooks. The best way to grow appreciation for hooks is to try wrapping many HOC's and deal with conflicting props and "innerRefs". People seem to very easily forget the horrors of the old. Also lets be real, hooks aren't that bad. Yes dependencies arrays and useEffect take some getting used to, but I rarely get into situations where I actually get into questionable territory. Use react-query/swr for fetching, use Zustand (or whatever) for state, and you cut out 95% of the problems. Anyway, the new docs are great, well done, nice work!

robertoandred 4y ago
[flagged]
spankalee 4y ago
Hooks are much worse because they poorly emulate classes. What you need for components is a stateful container, with an initialization phase, a render function that can be called for each update, and lifecycle methods that are called at lifecycle events. Classes give you exactly this: - Constructor for initialization - Class fields for state - A method for rendering that can be called multiple times, which can reference state - Lifecycle methods Classes are simple, standard, and give you everything you need for UI components. They were practically invented alongside the concept of UI components. Hooks try to cram all of this into the repeatedly called render method and it's just a failure. - You have to put initialization into callbacks because the whole component is called multiple times - It's difficult to manage object and callback identity across renders requiring useCallback() and useState() to fix - Lifecycle callbacks are put into hook arguments, but they're just trying to be methods and end up recreating the lifecycle closure every render. - Hooks have restrictive rules on their usage - Hooks make a function no longer just a function. It needs to be invoked inside a hook context, making it much less portable than a constructor - Hooks hide their state within the hooks system, making them much harder to introspect and debug. Hooks supposedly solve this composition problem and allow reusing logic, but that is entirely possible with classes. It's just a huge amount of FUD and misinformation to say that you can't do composition with objects. All you need is an object interface that is similar to the component interface that the component delegates to from its lifecycle methods. This is a simple and standard pattern to use and implement: it's just a single line of code per lifecycle method. And it's easily introspectable with a debugger: just follow object references to the helper objects. lit.dev does with with reactive controllers: https://lit.dev/docs/composition/controllers/ https://lit.dev/docs/composition/controllers/ It's a very simple alternative to custom hooks, and eliminates the need for all the builtin hooks.

interstice 4y ago

Is there a hook for an error boundary component yet or is a class component still the easiest way?

sophiebits 4y ago
Not yet! Other improvements have been higher priority so far. Many people also use the react-error-boundary npm package, and some frameworks have their own error boundary APIs (eg: https://beta.nextjs.org/docs/routing/error-handling https://beta.nextjs.org/docs/routing/error-handling).
- klysm 4y ago
  I encourage people to copy what they need out of react-error-boundary and tightly integrate it with their stack. It’s really not bad

Vinnl 4y ago

Hmm, I can't find the "Edit this page" link that many Docusarus (which I assume this is?) sites often have, and I can't find the repo either, so I can't submit a PR, but... There's no RSS feed for the blog :(

sophiebits 4y ago
Not Docusaurus, but the source is here: https://github.com/reactjs/reactjs.org https://github.com/reactjs/reactjs.org (currently in the "beta" directory)
- Vinnl 4y ago
  Thank you! Makes it a bit more work, but maybe I'll look at submitting a PR later.

Diggsey 4y ago

All of the new documentation is horribly laggy in Firefox and all of the code sections are broken (eg. the visible cursor position does not match the actual cursor position...) This is latest stable Firefox on a high spec Windows 10 laptop. Not a great look given what React is supposed to do!

debacle 4y ago

I like classes because they're easier to code review and easier to read/reason about. The artifical limitations are good. At a large org that's way more important than initial write.

rglover 4y ago

Oh, weary traveler, if yer tired of your APIs a changin' join us o'er at the Joystick [1] and enjoy a stable sea like y've never seen bafore. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

funstuff007 4y ago

> We’ve included diagrams, illustrations, challenges, and over 600 new interactive examples. 600! It's hard for the competition to keep up with that.

adamzerner 4y ago

I've never understood why React components are considered to be pure. The output is not just a function of the props, it's also a function of the state (as in `useState`) and context (as in `useContext`).

klysm 4y ago
Agree, but it should be a pure function of its arguments and the state

isntbilly 4y ago

jerrygoyal 4y ago

People tend to overuse Effect, this article explains it well https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect

megous 4y ago

Nice demo of sluggishness of React: https://react.dev/learn/updating-objects-in-state https://react.dev/learn/updating-objects-in-state https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm (Top of the line desktop AMD chip.) The code has no transition, no setTimeout, no nothing that would indicate any delay. The dot should always be right under the cursor. This will happen with every similar UI pattern (want to resize something, move a slider, etc. etc.) I guess this is a result of tradeoffs React has to do by insulating people from DOM. There's probably some way to force immediate DOM update, but then you're pulling in a lot of useless diffing and checking for each frame, instead of just updating the single el.style.something property you'd do when directly using DOM API and leaving the browser to do the rest.

senttoschool 4y ago
>(Top of the line desktop AMD chip.) Slightly off topic but my M1 Pro Apple Silicon Mac does not lag like your top of the line AMD chip. I know most consumers run React code with CPUs slower than Apple Silicon chips but this post is more of an endorsement for the M1 lineup.
- megous 4y ago
  You're comparing different software rather than different CPUs.
- geodel 4y ago
  This is relief. I was afraid that M1 Max would be minimum requirement for smooth experience.
  - senttoschool 4y ago
    I know your post is sarcasm but a base M1 would perform the same as M1 Pro, Max, Ultra in this case. It's the single thread speed that matters the most in web performance. So you just need an M1. The M1 Air is frequently on sale for $800 nowadays. Or if you're really on a budget, you can buy a used M1 Mini on eBay for $400. Very affordable for those who want high browser performance.

njsubedi 4y ago

It’s funny how react.com redirects to reactjs.org and that redirects to react.dev domain because most companies only use newer tlds because dotcoms are unavailable

intellix 4y ago

You can pretty much skip React and go straight to Qwik as it solves N+1 and it fixes the ability for low quality devs ruining perf with useEffect since you have signals ala Solid

tomgp 4y ago

Lovely site but it got my hackles up right off the bat ... > "The library for web and native user interfaces" _A_ library, it's _a_ library not _the_ library.

liendolucas 4y ago

I was relatively happy with the React class model, for me it was very clear just to override any required methods in a class. To this day if I need to do something in React I can pick it up quickly because is a very simple model: it follows the template design pattern, which is one of the most powerful and dumb design patterns (I'm talking obviously about the class model). What's my current issue with React? Well in the same way that they have decided to go with hooks and all that, nothing is preventing those folks tomorrow to wake up to say: "You know what? What we really really need is not functional components but a hybrid approach, not fully functional not fully object oriented" and then the game starts again. I worked for a very limited time in one company not long ago, and a guy there came and said something like: "We really should start using hooks" and I replied: "Really? Why? Can you show me a true or concrete advantage using the functional style over the OO approach?" then he said: "Well, I don't really need to do that just watch this video" and sent me a link of a video (if I recall correctly) of the creators explaining all the hooks stuff. I didn't even bothered to continue discussing (how can you discuss when someone is 100% biased?). My point is that many people out there just take for granted whatever ideas these people are pushing out and not questioning things anymore. I'm not saying that hooks are good or bad a thing (I really don't know and if I need to learn hooks because that's the style used in a codebase, sure I'll do it and probably learn something), but blindly embracing things just for nothing is harmful.

ruicaridade 4y ago
To me, the main benefit of react hooks is it eliminates higher-order component hell. It's so much easier to extract common behaviour from different components to a re-useable hook, rather than wrapping a class with a million different higher-order components: `withRouter(withFoo(withBar(MyComponent)))`.
codingdave 4y ago
When hooks came out, myself and the other senior devs on our team had that same inertia-driven reaction. We knew classes, we were comfortable with classes, and they worked. So we asked the same question - "Why hooks?" So we sat down and actually used hooks for a few days - refactored small and large components to be sure we understood them and saw the difference in the code. We found it to be a perspective change -- once we made that change and got used to the new syntax, we loved it. Our code was simpler and easier to maintain. Once we really learned when to use useEffect so as to not abuse it for everything under the sun... the code got better still. So while you are correct that blindly embracing hooks would be harmful... Blindly rejecting them is equally harmful.

deleted 4y ago

[deleted]

DyingAdonis 4y ago

React is a leaky abstraction. https://twitter.com/clark_gunn/status/1636565797412773888 https://twitter.com/clark_gunn/status/1636565797412773888

FractalHQ 4y ago
As someone who learned web dev with Svelte, it seems so obvious to me that React is full of convoluted apis born from tech debt, and such a bad DX compared to what is possible today. I imagine if I learned React first, it wouldn’t be nearly as obvious to me how mush worse it is than it should be.