Server and Client-Side React
The web development landscape keeps evolving. While React has introduced features like Server Components and Server Actions, it’s still possible to use React for a single-page application on the client-side without these features.
However, there seems to be a divide within the community between the traditional and the newer approaches to building web applications with React. Beginners are often uncertain whether they should learn React as a library or adopt the framework approach these days.
So I’d like to hear from you:
What do you think about the features that are being introduced to React? Do you think they are necessary for building web applications, or do you prefer the traditional approach?
In any case, for both client-side and server-side React, I keep my tutorials up to date. A selection of my recent articles comes next …
How to fetch data in modern React
Has everyone settled on React Query? In this article, I cover the various ways to fetch data in React applications. While I’ve been using React Query since its initial release, I’ve also had good experiences with some of the alternatives listed there. I also created a code summary of this post on LinkedIn, which many developers found useful.
Interestingly, developers have started using Server Actions for data fetching as well, even though they are primarily intended for mutations. In response, the React team introduced a umbrella term, Server Functions, under which we may be able to perform data fetching without the limitations of Server Actions.
If you were around when React Hooks were released, you might be quite familiar with data fetching by just using hooks. This was one of my most-read tutorials back in the day, when React Query wasn’t available. I've updated it because I think it’s still quite relevant for React beginners, and personally, I think it’s one of the most effective ways to learn about React hooks.
ICYMI: I’m about to release a course on modern React.
I hope you have a productive start to the week. Keep coding, everyone! :)
Best,
Robin (who likes files in kebab-case)
I guess as a software developer, I see it as another tool in the toolbox.
It all depends on the type and scale of application that is being built and what resources(devs and their skills) are there to build the application.
If its a big application with lot of a complexity in the backend requiring different skills/languages then perhaps use an architecture of proper defined contracts/interfaces in the backend that is leverged using API. Hence going with the 'traditional' approach in the frontend. This will ensure modularity, easier management of separate systems without any dependency, ability to use different languages and have different teams working on different things etc.
If its small application with dev skills mainly around JS language then perhaps use SC in this case.