Three Cool Rakkas Features that Next.js Lacks

💃 Rakkas, the lightning fast Next.js alternative powered by Vite, has just released version 0.5.0 (check out my previous post for an introduction). Although it replicates or offers alternatives for most Next.js features (like file-system router, server-side rendering, data fetching, and static site generation), Next.js still has many features that Rakkas doesn't support yet. This new release closes the gap, if by a little, by providing much improved SSR support (thanks to Vite 2.7), implementing rendering modes (static, server-side, or client-side) and support for deploying on serverless environments. But it's not all about playing catch-up: Rakkas does offer a few cool features of its own that Next.js lacks.

1. Deploy on Cloudflare Workers

The new Rakkas release brings first-class support for deploying on Vercel serverless functions, Netlify functions, and Cloudflare Workers. Vercel, the makers of Next.js, is of course the go-to option for Next.js apps. Netlify is also a popular deployment target. But Cloudflare Workers is an entirely different beast: It is a lighter-weight and cheaper solution compared to container-based serverless functions offerings. But the environment is much more similar to service workers in browsers than to Node. Next.js, being closely tied to Node, doesn't support Cloudflare Workers as of yet. Following Svelte Kit's lead, Rakkas was designed with this use case in mind from the get-go.

Note that we're not talking about Cloudflare Pages, which Next.js supports as a static deployment target, but actual server-rendered (well, technically speaking “edge-rendered”) React applications with support for API routes. This is a rare feature among React frameworks (I'm only aware of Flareact and Vitedge).

Check out the updated Rakkas RealWorld Demo to see how the same full-stack application is deployed on Vercel, Netlify, Cloudflare Workers, and Node; all connected to the same Postgres database hosted on Supabase. In serverless versions, authentication requests are proxied to the Node server because CPU time limit may be too low to allow secure password hashing. They also use the Prisma data proxy for accessing the database while the Node server uses Prisma directly.

2. Localize your URLs

This new Rakkas feature allows you to have localized URLs: Say you have a website with a “Home” page (/en), an “About us” page (/en/about-us) and a “Products” page (/en/products). In a multilingual site, you'd probably want your French language URLs to be something like /fr, /fr/qui-sommes-nous and /fr/produits. Don't get hung up on the exact URL structure, you have complete control: You can omit the prefixes in English pages, put different versions on a different subdomain (fr.example.com) or domain (example.fr), or opt out of URL translation (/fr/about-us) for instance. All you need to provide is a function that parses the language from the URL and translates the localized URL into a default form that Rakkas will use to determine what to render.

If you need an international landing pages (say / redirects to /en or /fr based on the visitor's language preference), Rakkas also offers optional Accept-Language and navigator.languages based language detection and redirection that can be overridden by a cookie. It even works on static sites where JavaScript redirection is used. Rakkas will render a list of links to the localized URLs when JavaScript is disabled.

Next.js does have a feature to detect the language from the URL but the URLs cannot be rewritten: You will have /fr/about and /fr/products (or example.fr/about etc.) which is, frankly, of limited use.

3. Nest your layouts

Not many websites consist of completely independent pages. Most sites have shared elements like a header, a footer, and a navigation menu that are common to many pages. Rakkas provides a nested layout system to handle this use case and more. You can have a layout.jsx (or tsx) and all pages in the same directory and pages or nested layouts in its subdirectories will be wrapped in your layout component.

Next.js has a similar feature but Rakkas layouts can nest arbitrarily by following the same filesystem-based organization as pages, they can have their own blocking data fetchers for static/server-side rendering, and they can provide shared data for lower level layouts and pages via the layout context feature. They can also abort the rendering of the current page by returning an error or redirecting to another page, useful for implementing login protected pages for instance.

Pages don't even need to share a common URL path prefix to share a layout: You can put pages that should share a layout under a directory with a name that starts with an underscore (_). For example you could have a directory structure like this:

• pages/
  • layout.jsx (the main layout, common to all pages)
  • _app/ (layout group for most pages)
  • layout.jsx (common layout for most pages)
  • page.jsx (path: /)
  • about.page.jsx (path: /about)
  • blog.page.jsx (path: /blog)
  • _admin/ (layout group for admin pages)
  • layout.jsx (common layout for admin pages)
  • settings.page.jsx (path: /settings)
  • users.page.jsx (path: /users)

Final thoughts

We all know Next.js is awesome. But Rakkas does put a few unique features on the table. It's still young and not yet ready for production use but go ahead and give it a try and share your thoughts. Star us on Github and talk about Rakkas if you like what you see. If you have any questions, problems, or suggestions open a Github issue. If you want to contribute, fork and send a pull request. Check out the open issues to see how you can help. All feedback is welcome, positive or negative.