I have been using React 18 on my personal website since the alpha stage. And I have to say, it is a big improvement in terms of performance, mostly on TBT.

Just one thing to note though, although many frameworks claim to support React 18, you will still see various minor issues (e.g. Gatsby is still using the legacy render in DEV build in certain cases instead of createRoot). Yet overall, the RC version of React 18 feels stable enough to be used in PROD.

I’ve been loving it as well, especially Suspense with Recoil/urql for state/ data fetching. Makes the code a lot cleaner and more predictable

Total Blocking Time. One of the vital measurements of webpage performance benchmarking.

Waiting for react-query and some other libraries to support it, been wanting to try it out for a long time already

react-query works solid - not perfect as expected for a RC still - but feels really good to use and I didn't even get started on the performance

I'm really not a fan of Suspense tbh, I've worked with it a bit on an enterprise codebase and it's caused nothing but confusion. Using throwing/swallowing exceptions as a way to achieve behavior is super implicit and arguably a code smell. You can't identify that a component might be using that behavior without looking at its internals. Even Context (the other arguably implicit dependency injected thing) still has to pass a default value if a parent context isn't found. And there's been a bunch of edge cases which it doesn't handle particularly well, e.g. pagination based loading, or needing to show multiple loading indicators. It just adds more coupling for (IMO) something that wasn't that big of a problem in the first place.

Throwing exceptions was so counterintuitive one guy just gave up and wrote his own framework

This is what drives me a little crazy about Facebook - a constant disregards to "standards" in almost every form and never contributing to existing open source projects.

Using throwing to manage suspense? Ugh. There are way better functional approaches over using an anti-pattern to the core language. But Facebook drops a turd and it is worshiped by so many.

Don't get me wrong. I appreciate what React brought everyone when web components were a stalled standard. There are parts of React that are totally great. It isn't the fastest, it isn't the easiest, it isn't the best by any means - but React is a solid lib. Of course, it is the only largely used lib that doesn't properly support the finalized web component standard.

I would really like to see the greater community adopting web components. Even with a lightweight wrapper like Lit, Stencil, etc... that can then be used in React, Vue, Angular, and everywhere else. It is far past time that we have UI component libs like Material-UI and Vuetify that aren't just pure components that can run in either space. Of course, Google does have their own material components that can do this - only Google has been really shit at maintaining and promoting their own web components.

Ahh well. One day...

 

 

 

React JS 18 what's new ? 

• Performance improvement by more efficient (batched) state updates. This is mostly internal and should not impact your development process much.

• More control over delayed state updates with the startTransition API. I would compare it to using a debounced function (e.g. typing in a search input and only send a search query after the user has stopped typing for some time), but the difference is that it is handled internally by the React scheduler, instead of a synchronous call that forces React to wait for the next render cycle.

• Improved server side rendering (SSR), so you can send server rendered component in batches (streaming), instead of having to wait for the whole thing. This makes loading more gradual (instead of an all-or-nothing experience), which can make the app feel faster and can improve the loading experience for the user.

 

The React team is excited to share a few updates:

1. We’ve started work on the React 18 release, which will be our next major version.
2. We’ve created a Working Group to prepare the community for gradual adoption of new features in React 18.
3. We’ve published a React 18 Alpha so that library authors can try it and provide feedback.

These updates are primarily aimed at maintainers of third-party libraries. If you’re learning, teaching, or using React to build user-facing applications, you can safely ignore this post. But you are welcome to follow the discussions in the React 18 Working Group if you’re curious!

When it’s released, React 18 will include out-of-the-box improvements (like automatic batching), new APIs (like startTransition), and a new streaming server renderer with built-in support for React.lazy.

These features are possible thanks to a new opt-in mechanism we’re adding in React 18. It’s called “concurrent rendering” and it lets React prepare multiple versions of the UI at the same time. This change is mostly behind-the-scenes, but it unlocks new possibilities to improve both real and perceived performance of your app.

If you’ve been following our research into the future of React (we don’t expect you to!), you might have heard of something called “concurrent mode” or that it might break your app. In response to this feedback from the community, we’ve redesigned the upgrade strategy for gradual adoption. Instead of an all-or-nothing “mode”, concurrent rendering will only be enabled for updates triggered by one of the new features. In practice, this means you will be able to adopt React 18 without rewrites and try the new features at your own pace.

 

A gradual adoption strategy

Since concurrency in React 18 is opt-in, there are no significant out-of-the-box breaking changes to component behavior. You can upgrade to React 18 with minimal or no changes to your application code, with a level of effort comparable to a typical major React release. Based on our experience converting several apps to React 18, we expect that many users will be able to upgrade within a single afternoon.

 

We successfully shipped concurrent features to tens of thousands of components at Facebook, and in our experience, we’ve found that most React components “just work” without additional changes. We’re committed to making sure this is a smooth upgrade for the entire community, so today we’re announcing the React 18 Working Group.

Accessing the React 18 Working Group

Everyone can read the discussions in the React 18 Working Group repo.

Because we expect an initial surge of interest in the Working Group, only invited members will be allowed to create or comment on threads. However, the threads are fully visible to the public, so everyone has access to the same information. We believe this is a good compromise between creating a productive environment for working group members, while maintaining transparency with the wider community.

As always, you can submit bug reports, questions, and general feedback to our issue tracker.