Frontend Frameworks in 2022 for eCommerce
The frontend frameworks ecosystem is booming so much that finding the right one for your online business/store has become challenging (at best). We’d love to help. This post is all about that.
With the abundance of available solutions advising on the best [insert anything here] nowadays is a double-edged sword. So, instead of ranking frontend frameworks on the best scale, we’d like to go through some of the most popular solutions we’ve worked with at the moment. Hopefully, our experience (and our free eCommerce starters) will help you make the best decision for your project at hand.
As a headless eCommerce platform, our primary goal is to design and engineer a service that front-end developers enjoy. This means we spend much time researching, experimenting, and building out front-end eCommerce starters. Here come our current opinionated views in the context of front-end frameworks for eCommerce.
Satisfaction, interest, usage, and awareness ratio rankings of the popular frontend solutions can be checked here in the State of Frontend 2022 report.
The list of frontend frameworks today seems almost endless. Some of the most popular include; React, Angular, and Vue, but also frameworks built on top of React like Next JS, GatsbyJS and Remix.run,; or on top of Vue like Nuxt JS; and others like Svelte, Astro, and 11ty with many of these exploded in popularity in the last year or so.
The list goes on, but this post is not about comparing all different frameworks. We will focus on two with which we have had great success - but not for the same use cases. For 2022 here are the two frameworks we are really bullish on:
Again, this post is totally biased and based on our own experience.
Getting started with NextJS is easy. NextJS started as a framework to solve the SSR + SPA topic to enable fast frontends that are also indexed well by Google. At least that was our introduction to NextJS back in 2017.
The main strategy of NextJS is to pre-generate static versions of all the pages on your site. This build process is a very similar approach to what GatsbyJS does (have a look at our Gatsby vs Next JS comparison post). The default behavior is that the pages are kept static for a while, then support for on-demand revalidation, which also enables event-driven HTTP cache control (more on that below).
NextJS has since grown and is tightly connected to Vercel (previously Zeit), which makes the developer experience great. It is super simple to deploy a project.
We believe NextJS is excellent for eCommerce scenarios where you do not have too many pages. Perhaps somewhere less than 5k pages in total is a max. But with that amount of pages, you are talking about some serious build times to deploy a new version of your site.
Regenerating a page takes, in our experience, about 1-2 seconds. This means that when requesting a fully dynamic page from a NextJS / Vercel setup, you can risk that the user has to wait 2 seconds. This is due to it actually being powered by lambda services that are not very fast (to keep the cost down). The same applies if you run NextJS on Netlify.
Use case for this: previewing a draft version of your product while creating updated content. You do not want to wait 2 seconds to see a preview. Yes, you can host NextJS on a more powerful hosting environment to boost the dynamic performance. But then your developer experience and costs change quite a lot.
NextJS has built-in cache control, which is excellent, and sometimes not so great. The great thing with the cache control is that it works great out of the box. You can somehow tune it with custom TTL (time to live) settings. Now you can also do on-demand regeneration of certain pages.
The default experience with NextJS makes for a really, really fast experience. You can try a live site running Crystallize + NextJS on Vercel at the Mercedes-Benz of Norway site.
But cache management at scale is challenging. NextJS does some magic of prefetching links you might click, often regenerating multiple URLs. Our default NextJS eCommerce boilerplate with NextJS does something like 8 pre-fetches, and with the default 1-second TTL, you have a very greedy setup.
Worst case scenario: 1-page load regenerates 8 pages. Now, Crystallize APIs are superfast and have no issue handling this. But it generates a number of API calls when you get real traffic on such a site.
✅ When NextJS is suitable for eCommerce:
- Not too many pages/products (less than 5k-ish)
- Your pages do change that often
- Built in internationalized routing for multilingual support
- Smoooth developer experience for deploys
❌ When NextJS is not so great for eCommerce:
- When you have 100s of thousands, or millions of products/pages
- Have frequent changing and dynamic pages
- Want to use HTTP cache (CDN) with full control over the headers
Last year the Remix.run framework was released in Open Source and has gotten much attention since then. We have created our Remix.run eCommerce starter, and liked what we saw.
Relying on web standards is great as developers do not have to learn too many framework-specific functionalities.
Nested layouts are quite simpler to implement in Remix. Data mutation is super convenient. Basically, Remix takes care of everything, whereas with NextJS you need to manage most things yourself - for example, form handling.
Beautifully managed error boundaries is a bonus with Remix. Super important in enterprise setups. Also Remix Run pushes the limit of speed with Optimistic UI concepts that help developers to build powerful and fast experiences while managing errors only when they happen.
Enterprise eCommerce cases are highly dynamic and have many pages that frequently change. This means that dynamic performance is really important. Remix.run is great in these cases.
Being hosting agnostic, Remix can run anywhere. It is not tightly connected to an opinionated hosting provider. Meaning you have more control over the hosting architecture. We have done some tests with hosting on Netlify, Azure, Fly.io, and Platform.sh. The last two provided the best results and developer experience when running a CDN on top like Fastly. But you can really use the hosting stack. Bring your own. We like it.
A big difference bonus of Remix is that you can manage cache headers and highly optimize soft purging of CDN cache. We did a blog post diving into this with event-driven cache HTTP cache control if you want to dig in.
With the dynamic performance of Remix, the first thing we notice is even before we start visiting the webshop. It is when previewing a product during creation. The live frontend preview in Crystallize just feels instant 🤩
✅ Pros for Remix in eCommerce:
- Great for dynamic sites: you have a server
- Embrace the platform on which it’s running
- More lightweight rehydration compared to NextJS
- Full control over HTTP headers for cache management using a CDN like Fastly
- Not tightly connected to a single hosting provider (like Vercel with NextJS)
❌ Cons for Remix in eCommerce:
- A bit more DevOps work if you, e.g., use Fly.io and Fastly to host the frontend
- A newer framework (but based on React JS) than NextJS, some clients might be skeptical
- Since it is fairly fresh the community is still growing
Deemed as one of the most popular React based frameworks, Gatsby is known to be an SEO-friendly static site generator framework delivering extremely fast websites.
However, one downside of SSG is the total amount of build time. As the pages on your website increase, so does the build time. To combat this, Gatsby supports incremental builds, meaning that after the initial build, only the parts of your website that have been changed are rebuilt but the initial build still takes a longer time, which might be an issue for more complex sites.
Gatsby also ensures that the developer experience is as smooth as possible, thanks in part to its vast ecosystem of plugins, integrations, and starters. This includes both official ones and the ones created by the wider Gatsby community.
Once done, deploying a Gatsby site is also very convenient. You can deploy it on services such as Netlify and Vercel or use Gatsby Cloud, built explicitly for deploying Gatsby websites.
Dubious about using Gatsby because of all the new alternatives available? With almost 400k downloads per week on NPM, it’s safe to assume that the framework is still well in demand and is widely used.
✅ Pros for Gatsby in eCommerce:
- Easy to get up and running because of all the themes, plugins, and starters available
- Great for sites with a predictable amount of pages
- Incredible performance scores right out of the box
- Ships with progressive web app (PWA) features
❌ Cons for Gatsby in eCommerce:
- Although Gatsby does support fetching data without using its GraphQL data layer, they still advise against it so if you would like to query data using something other than GraphQL, you are better off with another framework.
- The more content you have, the longer the build time
- Incremental builds are only available if the site is deployed on Gatsby Cloud
Depends on the use case, tech know-how of your team, time, and money you have. If we are to look only at frameworks our best advice would be to use NextJS when you have less than 5k pages in your online shop. Remix when you are bound to have a lot of dynamic functionalities. And Gatsby for anything in between.
In reality, it is not as simple as that. Any framework can be performant and applicable to most (if not all) use cases. The thing is, do you have enough knowledge and time to make it work the way you want it.
You Should Also Read👇
Next.js vs Gatsby, what to choose? This is an age-old question many developers have to ask whenever they start a new React application.
Server-Side Rendering. Client-Side Rendering. CSR with Prerendering, etc. The differences, trade-offs, and similarities between most common web rendering solutions and why you should care about them as a dev.
A lot has happened in two years (since we originally published this). However, React, and static site generators (SSGs) built on top of it are still gaining traction with frontend developers worldwide.