Rakkas: a React framework on Vite that still calls itself bleeding edge

What Rakkas is, and the honesty about its maturity

Rakkas is a bleeding-edge full-stack React framework powered by Vite, and the project positions it as an up-and-coming alternative to Next.js, Remix and Gatsby.

The feature list is the interesting part. A lightning fast development server, which is Vite's contribution. Streaming SSR with Suspense. Dynamic rendering, described as full static pages for bots and streaming for browsers, which is a deliberate split rather than a single rendering mode. An API-less data fetching system, so you do not write a route handler and then fetch from it. Support for serverless and worker environments. Static site generation. A flexible file system router. And API routes with middleware support.

Then there is the section titled Is Rakkas right for you?, and it is the most valuable paragraph in the README. Although many features have been implemented, Rakkas is still under heavy development, it uses experimental and/or beta features of React and Vite, minor releases will introduce breaking changes until 1.0, and as such it is not yet ready for production use. The recommendation is explicit: if you need a stable React framework, try Next.js, Remix or Gatsby.

The project is also fairly opinionated, and for that case it points at vite-ssr-plugin instead.

So the framework is presented as a laboratory for framework design rather than as a product, and the README says so before you install anything. That honesty is a credit to the author, and it is also the thing that decides the adoption question, because a framework that breaks on minor releases cannot be pinned the way a production dependency has to be.

Scaffolding a project, or setting one up by hand

The project initializer is the normal create-app flow, available through three package managers:

npx create-rakkas-app@latest my-rakkas-app
# or
pnpm create rakkas-app my-rakkas-app
# or
yarn create rakkas-app my-rakkas-app

The initializer comes with many features, all of which are optional, but the project strongly recommends enabling TypeScript and the generation of a demo project on the first try. The reason given is a good one: self-documenting type definitions allow for a smoother learning curve, and the demo project source code comes with plenty of comments.

That is an unusual recommendation for a scaffolder, and it reflects what this project is for. The value of a bleeding-edge framework is what you can learn from it, so the author optimises the first-run experience for reading rather than for shipping.

The manual setup is equally short:

npm install --save react react-dom
npm install --save-dev vite rakkasjs

And then a page is a file. The example given is a src/routes/index.page.jsx exporting a default function that returns a heading, which shows the file system router convention, the .page suffix marking a page rather than a layout, and the JSX default export style.

From there the three commands are:

# Start a development server with `npx rakkas`
# Build with `npx rakkas build`
# Launch with `node dist/server/index.js`

The build output is a server bundle you run with node, which is the shape that makes the serverless and worker deployment targets possible, since the same bundle can be adapted rather than only run behind a Node server.

The data fetching design, and the 0.6 rewrite

The 0.6.0 release is where the framework's shape was settled, and the changelog is the clearest account of the design decisions.

The headline is a brand new data fetching system, with react-query-inspired useQuery and useMutation, Remix-inspired action handlers, API-less data fetching with useServerSideQuery, waterfall-free preload functions, and Remix-inspired form action handlers.

The two ideas that matter are the last two. Preload functions that are waterfall-free mean the data for a route can be requested before the component renders rather than after it mounts and discovers it needs something, which is the difference between one round trip and a chain of them. And API-less data fetching means the loader and the component share one definition, so there is no separate endpoint to write, keep in sync and secure.

The same release brought React 18 with concurrent mode, streaming SSR and Suspense for data fetching, and Vite 3 with an ESM SSR build, which the changelog notes means the type field is set to module, and an improved cold start.

HTTP handling is based on web standards, and the adapters cover Vercel Edge, Netlify Edge and Deno/Deno Deploy, plus an Express integration. The routing work in the same release added route guards, catch-all routes and simpler 404 handling, and the miscellaneous section added response headers customization and a shared ESLint configuration.

The 0.7.0 entry, installable as rakkasjs@next, replaced react-helmet-async with a custom component, which the changelog says reduces bundle size by 17KB. Replacing a dependency to save 17KB is the kind of detail you only see in a project where bundle size is a stated concern.

The monorepo, and the examples that document the integrations

The repository is a pnpm workspace, and the root package.json shows a project organised for many packages and many environments.

The root scripts fan out with pnpm -r. The dev and build scripts run across ./packages/* in parallel, while the ci and ci-examples scripts run with --workspace-concurrency=1, one workspace at a time, which is the difference between fast local iteration and deterministic CI ordering. There is a separate test:format script that runs prettier in check mode over everything except the lockfile, and a matching format script that writes.

The dependency versions at the root tell you the era. Vite is at 5.4.3, TypeScript at 5.5.4, Vitest at 2.0.5 and Prettier at 3.3.3, with @vitejs/plugin-react at 4.3.1. The pnpm section has a peerDependencyRules block allowing react and react-dom version 18, and an overrides block that is commented out and says to uncomment the next option to test against a local Vite package, which is the mechanism for testing a framework against an unreleased bundler.

Then there are the examples, and they are the best documentation in the repository. The list covers auth, emotion, empty, express, fastify, graphql, guide-samples, localized-urls, mantine, mdx, react-query, server-sent-events, session, styled-components, tailwind, todo and urql.

Each of those is a framework integration, and the two that say the most about the data fetching design are react-query and graphql, since they show what happens when a component already owns its server state. The rest, express and fastify, show the HTTP adapters, and server-sent-events and session show the streaming and the request handling. There is also a testbed/ directory, a shared-assets/ directory and a website/ directory, which is where the documentation site lives.

What to weigh before picking this over Next.js

The first limitation is the one the project states, and it is disqualifying for most production work: minor releases will introduce breaking changes until 1.0, and it is not yet ready for production use. The release history confirms the shape of that. The tagged releases are v0.6.3 from 2022-11-02, v0.6.2 the same day and v0.6.1 from 2022-09-05, and the changelog's newest entry is 0.7.0, installable as rakkasjs@next rather than as a stable tag.

So the last stable npm release is from late 2022, while the repository itself was pushed to on 2026-10-15. Work is clearly happening, but the published surface has not moved in a long time, and a project that tells you it will break on minor versions is a project where depending on the tip of main is a deliberate choice with real consequences.

The second limitation is opinionation. The README offers vite-ssr-plugin for anyone who needs more flexibility, which is an honest pointer to the fact that Rakkas makes choices for you and that some of them, particularly around routing and data fetching, will not suit every project.

The third is the dependency on experimental React and Vite features. That is the source of the framework's appeal and also of its fragility, because an upstream experimental feature can change or vanish, and this framework is built on both.

On maintenance, the repository is not archived, the last push was on 2026-10-15, and there is a roadmap.md at the root which is the place to look for what is planned. The package is MIT licensed, with the author credited as Fatih Aygün and contributors, and parts of the CLI are based on the Vite CLI under the MIT licence. The published npm package also bundles @brillout/json-serializer, react-error-boundary and @microsoft/fetch-event-source, each with its own licence file in the repository.

Editorial conclusion

Rakkas fits a developer who wants to understand how a modern React framework is built, who is comfortable reading a framework's own source, and who wants to prototype on Vite rather than on a bundler-based toolchain. It is a poor fit for production work, because the project states it is not yet ready for production use and that minor releases will introduce breaking changes until 1.0, and it is a poor fit for a team that needs an escape hatch from opinionation, since the README recommends vite-ssr-plugin instead. Before adopting, read the roadmap.md in the repository, check whether the last published version matches what the documentation describes, and plan for the breaking changes the project promises.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. rakkasjs/rakkasjs on GitHub
4. README
5. Releases