Three Cool Rakkas Features that Next.js Lacks
Tags: react, javascript, vite, nextjs
Published: 2021-12-20 13:02:13

![Rakkas](https://github.com/rakkasjs/rakkasjs/raw/main/logo.png)

💃 [Rakkas](https://github.com/rakkasjs/rakkasjs), the lightning fast [Next.js](https://nextjs.org) alternative powered by [Vite](https://vitejs.dev), has just released version 0.5.0 (check out [my previous post](https://www.reddit.com/r/reactjs/comments/q7xtcg/rakkas_nextjs_alternative_powered_by_vite/) 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](https://rakkasjs.org/guide/feature-comparison). 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](https://vercel.com/docs/concepts/functions/introduction#serverless-functions)**, **[Netlify functions](https://www.netlify.com/products/functions/)**, and **[Cloudflare Workers](https://workers.cloudflare.com/)**. 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](https://kit.svelte.dev/)'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](https://flareact.com/) and [Vitedge](https://github.com/frandiox/vitedge)).

Check out the updated [Rakkas RealWorld Demo](https://github.com/rakkasjs/rakkas-realworld) to see how the same full-stack application is deployed on [Vercel](https://rakkas-realworld.vercel.app/), [Netlify](https://rakkas-realworld.netlify.app/), [Cloudflare Workers](https://rakkas-realworld.rakkasjs.workers.dev/), and [Node](https://realworld.rakkasjs.org/); all connected to the same Postgres database hosted on [Supabase](https://supabase.com/). 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](https://www.prisma.io/docs/concepts/components/prisma-data-platform#prisma-data-proxy) for accessing the database while the Node server uses Prisma directly.

## 2. Localize your URLs

[This new Rakkas feature](https://rakkasjs.org/guide/localized-routes) 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](https://nextjs.org/docs/advanced-features/i18n-routing) 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](https://nextjs.org/docs/basic-features/layouts) 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](https://rakkasjs.org/guide/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](https://stackblitz.com/edit/rakkas-demo-ts?file=src%2Fpages%2Fpage.tsx) and share your thoughts. [Star us on Github](https://github.com/rakkasjs/rakkasjs/stargazers) and [talk about Rakkas](https://twitter.com/intent/tweet?text=I%20gave%20%23RakkasJS%20a%20try!&url=https%3A%2F%2Fgithub.com%2Frakkasjs%2Frakkasjs) if you like what you see. If you have any questions, problems, or suggestions [open a Github issue](https://github.com/rakkasjs/rakkasjs/issues/new). If you want to [contribute](https://github.com/rakkasjs/rakkasjs/blob/main/CONTRIBUTING.md), fork and send a pull request. Check out the [open issues](https://github.com/rakkasjs/rakkasjs/issues) to see how you can help. **All feedback is welcome**, positive or negative.