Is Server-Side Rendering React’s Holy Grail?

With React and React Native now under a new foundation, perhaps React will make progress on server-side rendering (SSR).

SSR is an existential problem that React needs to confront, according to Platformatic founders, Luca Maraschi, CEO, and Matteo Collina, CTO. On Wednesday, Maraschi and Collina hosted a streaming conversation about React and React Native called React’s New Era: Compiler Magic, Native Architecture, and Foundation Shift.

Both men are active in open source. Collina is known as an open source author in the JavaScript ecosystem; modules he maintains have been downloaded more than 12 billion times. He’s a member of the Node.js Technical Steering Committee, focusing on streams, diagnostics and HTTP. Maraschi sits on the board for the OpenAPI Initiative.

They discussed the big advantages of the recent version of React and the new React compiler.

“To be honest, the biggest one is, as I said, the optimization that they shipped removed the need to implement usememo and do memoization of components,” Collina said. “These make it extremely useful to avoid re-render and massively optimized performance on the frontend at scale.”

React Compiler’s Potential

What the community needs from React is “a much better, faster, bigger React with new features, new optimizations, a new direction,” Collina argued.

The React compiler has massive potential for SSR, Collina noted during the livestream. While React compiler makes memoization in components “go away,” Collina said React compiler could become “massively more.”

“It could improve significantly more, because if we start optimizing for servers and doing a lot of server-driven optimization, it has massive potential,” Collina said. On components, it could pre-render a chunk of HTML, he added.

“It’s funny that … there is an immense amount of effort in optimizing for the frontend or the micro architecture, but we haven’t really focused on solving the existential problem that is more than 10 years [old], that is server-side rendering,” Maraschi added.

That’s because Facebook doesn’t use JavaScript on the server, he said.

“They don’t do much server-side rendering,” Collina said. “That stuff was never planned to be optimized in any form or fashion.”

Still, they complimented Facebook for making the decision to create a new React Foundation under the Linux Foundation umbrella, which Maraschi noted “was not their duty” but was “great news.”

Frameworks and Server-Side Rendering

Maraschi noted that everyone is chasing the holy grail of SSR. So far, the only framework to achieve it is Solid.js, he added.

“It’s not React-based, but it’s still JSX-based and they use a different compiler for JSX, which makes it significantly faster,” Collina said of Solid.js.

Maraschi theorized that perhaps companies are keeping secret how they optimize on the server, but Collina rejected this theory.

“It’s just not possible right now with React to optimize it to a level that would be drastically faster than what is there right now,” Collina said. “I don’t think there’s a secret sauce somebody’s keeping in the closet, to be honest. … It’s just not there.”

Maraschi pondered whether frontend cloud provider Vercel, which oversees Next.js, could contribute to SSR optimization.

“I don’t think so,” Collina said. “They are under significant enough pressure to optimize their system, and they [are] finally swinging around and starting to do the work. Also, they are accepting Cloudflare contributions for optimizing Next.js.”

At the same time, Cloudflare and Vercel are fighting for the edge market, so it will be interesting to see how Cloudflare will “play the game in the React space,” Maraschi said. As for next steps, Collina hopes the next step for React will be fixing React SSR.

“I think what will happen is that more vendors will start driving new optimizations and new use cases for React and make lives even simpler for developers,” Collina said.

He doesn’t see React going away, however, since so many enterprises choose React or Next.js for their projects. In part, that’s because they can find competent React developers relatively cheaply. Maraschi added that Next.js is basically React on steroids.

“I would say that React is more of a library and Next.js is the full package,” Collina added.

Despite that fact, when people leave Next.js, they tend not to go to React but Remix (now called React Router), which is a full-stack web framework built on top of React, Maraschi pointed out.

“Because typically they want to self-host,” Collina said. “And it’s much simpler to self-host other frameworks than Next. But React is not a choice. Just using plain React is not a choice because the amount of boilerplate and frame you need to essentially reinvent. I don’t know at least 80% of what Next is doing, and you might as well just use Remix essentially.”

Could Framework Features Be Absorbed by React?

Maraschi also pondered whether all these satellite frameworks might now be absorbed in the evolution of React.

“Now that the contributions are open, now that there is not a single benevolent dictator in the project, what sounds to me more logical is that everyone will try to take bits and pieces from any other project and convert them into React,” he said.

“It’s actually the only good choice, because if they didn’t do this, they will strain, keep straining, the relationships between the various frameworks,” Collina added. “That’s going to be the natural evolution of what’s going to happen, the consolidation of the ecosystem, or else it is going to be too fragmented. Enterprises are seeking a Switzerland of technology.”