What's going on with React?

00:00:00: React clearly has seen better days.

00:00:03: I mean, not from a usage point of view.

00:00:05: It's getting more usage than ever before.

00:00:08: Of course, also because it's the default JavaScript

00:00:12: AI. Build some project with AI and you'll get React and

00:00:16: Next.js. I've talked about this in another episode.

00:00:19: But it's seen easier days with less hate

00:00:23: and heat. I mean, over the last couple of weeks,

00:00:26: major vulnerabilities. One of them being so severe that

00:00:30: attackers could execute code on your server if you were affected.

00:00:33: By the way, make sure you patch your React

00:00:37: If you're using Next.js or some other framework

00:00:41: components, you're likely affected.

00:00:43: But the amount of hate is really a bit

00:00:46: staggering to me because there are things you can

00:00:49: criticize. But then there are also some things that are

00:00:53: really not that bad that some people make them seem.

00:00:57: But let's dive a bit deeper. What are we talking about?

00:01:00: It was actually in 2020, so yeah, five

00:01:04: years ago, uh, almost to the day, uh, five years ago,

00:01:07: that React server components were introduced.

00:01:10: What's the idea behind React server components?

00:01:12: Well, the idea back then and, and still today was and

00:01:15: is that you could render React components on a

00:01:19: server, but not in the sense of server-side

00:01:23: initially and then that's it. But instead that you would also render

00:01:27: them for page updates. If a user interacts with a page,

00:01:31: clicks a link, you would render the new page on the

00:01:35: well and send that to the client, and also react to a couple of other

00:01:39: things. And at the same time, of course, don't just have static

00:01:42: HTML, but a single page application kind of

00:01:46: the server, but then fully interactive on the client.

00:01:49: In order to make this work, they had to invent their own protocol

00:01:53: because the idea was not to render HTML and send that

00:01:56: HTML, but instead to exchange a payload from

00:02:00: to client and vice versa that does describe the current state of

00:02:04: application, the component tree, and that therefore is more complex

00:02:08: than just raw data sent through JSON or

00:02:11: raw HTML because you need both the page structure

00:02:15: and the state, the data. So that's React server

00:02:19: components. Due to this complexity, it took some time for them

00:02:23: to take off. Remember, they were initially announced in

00:02:26: 2020 and then the first time you could actually really use

00:02:30: them was in 2022, so two years

00:02:34: later with the release of Next.js 13,

00:02:38: which gave us a beta version of the app router, which, of course, nowadays is the

00:02:42: standard router if you're building a new Next.js application.

00:02:46: For a very long time, you could actually only use React server

00:02:49: components in Next.js and that brought its own

00:02:53: problems and some fair share of

00:02:56: criticism because it felt like React was kind of

00:03:00: Next.js. There was such a close connection

00:03:04: feel like you could reuse React without Next.js,

00:03:07: at least if you wanted cutting edge features like React server

00:03:11: components. It's also not just React server

00:03:14: We also have like the other side, server actions, which in the end

00:03:18: allow you to submit a form and behind the scenes an HTTP

00:03:21: request would be sent to your server, would be handled there, and you would get

00:03:25: back an updated payload that updates your React application.

00:03:29: So an updated React server component if you wanna call it like

00:03:32: this. That's in a nutshell how it works

00:03:36: blend backend and frontend code, server-side and

00:03:40: client-side code because you have React on both ends and there

00:03:44: is this magic going on where you have

00:03:47: components being rendered on the server, there's special kind of payloads being

00:03:51: sent back and forth, server actions.

00:03:53: And of course, the vulnerabilities I talked about,

00:03:57: these are related to React server components specifically to that

00:04:01: protocol, the React Flight Protocol as it's called,

00:04:05: for communicating between client and server.

00:04:08: However, what's really important is that it's not

00:04:12: per se that blending of client-side

00:04:16: and server-side code that's a problem here.

00:04:18: Only indirectly, if you will, because of course that protocol was

00:04:22: invented to be able to blend these two ends.

00:04:26: But when it comes to being able to fetch some

00:04:29: data on the server and then render a dynamic page

00:04:33: based on that, that's in the end how PHP always

00:04:37: worked, right? So back when we built very primitive,

00:04:41: simple PHP apps, you could reach out to a database

00:04:45: back some HTML code based on that. And now with React and React server

00:04:48: components, it's kind of the same.

00:04:50: You have that mixture of client-side and server-side, but of course it's a

00:04:54: bit more than that because unlike PHP, with React

00:04:58: the idea is that you have a fully interactive client-side application

00:05:02: powered by JavaScript and that's why this extra protocol

00:05:06: because it doesn't stop after this initial transfer from

00:05:09: server to client. But from time to time I see this image pop

00:05:13: up, which is from an early presentation of

00:05:17: and I believe its support in Next.js.

00:05:21: And this slide is often used by people to

00:05:24: criticize React and how insecure it is and I want to be very clear, and you

00:05:28: probably heard it before, nothing about this code on this slide

00:05:32: is insecure. This SQL statement runs on the server

00:05:36: there is no SQL injection going on here.

00:05:38: This SQL tagged literal here makes sure that all

00:05:42: the input is sanitized. So this is secure even though it

00:05:46: might look a bit weird and it might look like we're reaching out

00:05:50: SQL database in our React component, we're not actually doing

00:05:54: that. This is a server action step which is triggered on the server,

00:05:58: the magic is that this function, this server action is invoked

00:06:02: on your behalf invisibly behind the scenes

00:06:05: because there is an HTTP request sent to the

00:06:09: server to then, well invoke the code there.

00:06:12: And that again is using that special payload, the React Flight

00:06:15: Protocol. With all that out of the way what I will say though

00:06:19: with all these features, with React server components and

00:06:23: server actions and with that client and server-side

00:06:27: mixture that's going on here, React has gotten

00:06:31: more complex. And especially for less experienced

00:06:34: developers it can definitely be harder to tell which

00:06:38: code runs where. Now I will say you will get errors if you

00:06:42: put code that can only run on the server into your client-side

00:06:46: code or vice versa. You can't

00:06:50: really mess this up, at least not that easily I'd

00:06:54: say. But of course I understand that this can be

00:06:57: confusing. It's definitely an easier mental model

00:07:01: have an API, a REST API, a GraphQL API, whatever,

00:07:05: which is a standalone application and then you have your

00:07:09: detached client-side single page application and they

00:07:12: communicate through HTTP requests which you explicitly

00:07:16: send with help of the Fetch API or with help of a library like

00:07:20: React Query. This is definitely the easier mental

00:07:24: model.But there is a reason why React server components

00:07:28: were invented, if you wanna call it like this.

00:07:31: They were invented because, of course, with that other

00:07:35: mental model, with that other approach, you always had two

00:07:39: applications. You had your backend server, you had your client side

00:07:43: server or application. That, I would say, gets a bit

00:07:46: easier with React server components because we have just

00:07:50: one full stack application here. Kind of the idea behind

00:07:54: Next.js even before React server components.

00:07:58: Next.js kind of made sure that this API, plus

00:08:02: single page application, that this thing was wired up

00:08:05: properly and you could deploy it as one application even before

00:08:09: React server components. But that shows us that there was this

00:08:13: need, this demand for having full stack

00:08:17: applications that kind of blend both because that is what Next.js

00:08:21: did even before React server components.

00:08:23: Because even before that, you had special functions where you would

00:08:27: put your codes that would be fetched to prepopulate your

00:08:31: server side rendered, uh, components on the server.

00:08:34: We had that before React server components.

00:08:37: React server components came because there was a

00:08:41: need for this kind of application.

00:08:43: If you don't like them, if you don't want them, and there

00:08:47: that, if you don't like that mental model of blending

00:08:51: server and client-side code somehow, you don't have to.

00:08:55: You can still build your standalone

00:08:59: single page applications with React, with any

00:09:02: router or any libraries of your choice.

00:09:05: Could be React Router, could be TanStack Router,

00:09:09: but that doesn't really make sense because Next.js is really more of a full stack

00:09:13: framework. And then you can have your detached API,

00:09:16: API, your GraphQL API, whatever it is.

00:09:20: You can still do that if that makes more sense for

00:09:24: you, if you prefer this approach. And I will agree

00:09:28: that React got more complex over all these

00:09:31: years with Suspense, React server components, Server

00:09:35: Actions, all the optimization hooks that

00:09:39: exist in there, the React compiler, which is there to make

00:09:42: optimizing simpler again. That can all feel very

00:09:46: overwhelming. I mean, I remember a time where React was

00:09:50: pretty straightforward. You had your class-based components for

00:09:53: components, your function components for stateless,

00:09:57: It was relatively easy and simple.

00:10:01: You had other problems back then, uh, for example, that you had to

00:10:04: switch between class-based and functional components,

00:10:08: refactor your components if you suddenly needed state, so that

00:10:12: great. But yeah, it was probably a simpler mental model.

00:10:16: I totally get this point, and it is fair to criticize this.

00:10:20: It's also important to point out though there are alternatives.

00:10:24: Of course you might not have them if you're in a company that uses React,

00:10:28: like many companies probably do, but if you're not, you've got

00:10:31: alternatives. If you are somewhere where you're forced to use

00:10:35: React, it's probably worth noting that

00:10:39: despite all this complexity, and again, there are good

00:10:42: reasons why things got more complex, React

00:10:46: typically does still save you lots of headaches

00:10:50: because it is built to do many

00:10:53: optimizations for you. Some complexity comes out of

00:10:56: that urge to, to optimize stuff for you

00:11:00: or to load and render parts of the page efficiently, and

00:11:04: these are ultimately benefits you get out of React or

00:11:08: out of using React, at least potentially.

00:11:11: Nonetheless, there definitely are things to criticize about React, and

00:11:15: I too hope that we won't see more and more and

00:11:19: more complexity being layered on top of React.

00:11:23: But at the same time, all these discussions about how

00:11:26: insecure it is because it blends client server side code like

00:11:30: this, I really can't hear them anymore.

00:11:33: Because, in my opinion, that is not really the main problem

00:11:37: here and definitely not the root of these

00:11:40: vulnerabilities.