A backend engineers view on the frontend 2023: Looking at Qwik & SolidJS

A lot has happened in 2022 in the frontend world. Typescript truly is taking over the world, with more and more frameworks embracing full end-to-end typed data.

No matter if you’re using tRPC or, what feels like a ORM with a big typescript vibe, Prisma, in more and more corners of the stack we get the convenience of well-typed goodness.

In the past few days I’ve played with Qwik and SolidJS - two very interesting, early frameworks with quite different approaches that you could choose instead of React.

Why another React?

Both of them try to address React’s performance issues. Solid is trying to provide fine-grained reactivity, dropping the virtual dom and changing elements when they do change rather than relying on rendering cycles like React does. In solid what looks like an equivalent to a react render method is more of a constructor, binding reactive data to elements of the DOM. Using Solid is pretty easy to pick up with React knowledge. ESLint rules make it easy to avoid unexpected traps when coming from the react, all concepts are easy to translate. The big advantage rendering no longer is a black box but pretty obvious during development.

Qwik meanwhile takes it all even further. While it brings the reactivity benefits that Solid has, it also addresses a big pain point of modern web apps: time to interactivity.

Claiming to be the first O(1) framework, Qwik always loads a constant amount of javascript on pageload - no matter how big your application. It achieves this with a clever trick: Javascript is often used for interactivity like Buttons, so it’s not really required until someone clicks around. So Qwik attaches itself as an event listener, and when triggered loads whatever javascript is needed that should be executed on the event and runs it straight away.

That way only a limited amount of javascript has to run, and the browser doesn’t need to parse and run javascript that only is needed later. In reality Qwik prefetches those smaller chunks when the main script has already run to keep fetches out of the hot path.

Metaframeworks

Now this is all nice and good, and there are lots of interesting ideas, but where it gets real interesting are the meta frameworks, Solid Start and and Qwik-City. While Qwik & Solid are dealing with the frontend, these frameworks deal with the backend part, dealing with routing, serving of frontend components but also providing hooks to provide endpoints.

Now, these endpoints aren’t your ordinary endpoints. They tie neatly into the frontend, and are awaited when server-side rendering. Needless to say that you get type safety all the way for these endpoints

But not just that. You can define whole API routes that don’t provide any UI, and can define arbitrary non-GET methods on any component.

Layouts are Hierarchy, but so are URLs

Both Qwik & Solid provide an interesting component called Slot/Outlet. Its value wasn’t immediately clear to me, but after a while it turned out to be one of the most useful innovations.

An Slot/Outlet is basically a placeholder where components rendered deeper in the URL are neatly slotted in, utilising the inherit correlation of URLs with UI components. One example are often top-level menus which rarely change, and the frameworks can avoid unnecessary renders of equivalent components.

Using both Solid & Qwik provides a native experience for these frameworks that I haven’t felt with any other. They aggregated loads of the best parts of other previous frameworks - starting from scratch seemingly helped a lot to keep complexity low, and embracing JSX as they do will make it easier for devs to switch.

Both frameworks are very opinionated on both frontend & backend, but that’s what makes it interesting: It’s not very clear which one will work the best when deployed on a larger scale. And they are not the only one out there, there are many others addressing similar things.

It’s still early

Both Qwik-City and Solid Start are still in beta. I’ve experienced bugs in both, and while the frontend parts already feel somewhat ready the backend frameworks still need time.

I’m sure this will change within the year. It’s still very early for lots of metaframeworks out there, and I can’t wait to see these ready and see how these ideas perform in reality.

No matter who’s gonna be the next React, we’ll gain a lot from seeing those new ideas perform.