Dulak vs. other frameworks
Most frameworks hand you primitives and say “good luck.” You spend your first week wiring auth, uploads, migrations, SSR, and tests before you write a single line of business logic. Dulak ships all of that wired, tested, and documented — then gets out of your way. You fork it, you own it, and you start from a working app instead of a blank canvas.
That distinction shapes every comparison below.
Dulak vs. Next.js
Section titled “Dulak vs. Next.js”Next.js is the most popular React meta-framework — file-based routing, server components, streaming RSC, and a large deployment ecosystem (Vercel, edge runtimes). What it does not ship: auth, uploads, a database, or tests. That is your week one.
| Dulak | Next.js | |
|---|---|---|
| Shape | Boilerplate you own | Framework you build on top of |
| Runtime | Bun only | Node, or Vercel/Cloudflare edge runtimes |
| Database | bun:sqlite, zero-ORM, in-process |
Bring your own (Postgres, PlanetScale, …) + ORM |
| Auth | Wired: argon2id, DB sessions, OAuth, reset | DIY or third-party (Auth.js, Clerk, …) |
| SSR | In-process renderToString, no SSR server |
Server components / streaming RSC |
| Opinion on structure | One obvious way, codified | Framework conventions + your choices |
Next.js gives you rendering primitives and a deploy platform. Dulak gives you a working app. Reach for Next.js if you need React server components or edge deployment — those are real capabilities Dulak does not offer. For everything else, Dulak has auth, uploads, migrations, and tests already wired, and you are writing business logic on day one instead of day seven.
Dulak vs. Nuxt
Section titled “Dulak vs. Nuxt”Nuxt is the most popular Vue meta-framework — file-based routing,
server routes, useFetch data loading, and Nitro as a universal server
engine deployable to Node, Vercel, Cloudflare, and more. Auth and
uploads? Bring your own.
| Dulak | Nuxt | |
|---|---|---|
| Shape | Boilerplate you own | Framework you build on top of |
| Client | React, Svelte 5, or Vue 3 (template choice) | Vue 3 only |
| Runtime | Bun only | Node, Vercel, Cloudflare, static (via Nitro) |
| Database | bun:sqlite, zero-ORM, in-process |
Bring your own + ORM (Prisma, Drizzle, …) |
| Auth | Wired: argon2id, DB sessions, OAuth, reset | DIY or nuxt-auth module |
| SSR | In-process renderToString, no SSR server |
Nitro SSR / hybrid rendering |
| Uploads | tus v1 resumable, demonstrated by avatar | DIY or community module |
Nuxt locks you into Vue. Dulak offers Vue 3 as a template — the server side (Hono, SQL, auth) is identical whether you pick React, Svelte, or Vue. Reach for Nuxt if Vue is your entire stack and you want Nitro’s multi-target deploy. Pick Dulak if you want the server decoupled from the client, or might swap client frameworks later — your auth, migrations, and uploads survive the swap.
Dulak vs. SvelteKit
Section titled “Dulak vs. SvelteKit”SvelteKit is the official Svelte meta-framework — file-based routing,
server load functions, and adapters for multiple runtimes. Same story
as the others: auth, uploads, and a database are left as an exercise.
| Dulak | SvelteKit | |
|---|---|---|
| Client | React, Svelte 5, or Vue 3 (template choice) | Svelte only |
| Database | bun:sqlite, in-process, zero-ORM |
Bring your own |
| Auth | Wired end to end | DIY or community adapters |
| Runtime | Bun | Node, Vercel, Cloudflare, static |
| Uploads | tus v1 resumable, demonstrated by avatar | DIY |
Same story as Nuxt: SvelteKit locks you into Svelte. Dulak offers Svelte 5 as a template with the server side identical across all three client frameworks. Reach for SvelteKit if Svelte is your whole stack. Pick Dulak if you want the freedom to swap, or if you want auth and uploads wired instead of DIY.
Dulak vs. Laravel
Section titled “Dulak vs. Laravel”Laravel is the most popular PHP MVC framework — Eloquent ORM, migrations, jobs, queues, Blade templates, and a massive package ecosystem. It is also still gluing together PHP, Composer, a web server, and a database driver in 2026.
| Dulak | Laravel | |
|---|---|---|
| Runtime | One: Bun | PHP runtime + Composer + web server + DB driver |
| Language | TypeScript end to end | PHP on the server, separate client build |
| Setup | bun create dulak → bun run dev |
Install PHP, Composer, web server, DB |
| Database | bun:sqlite, raw SQL, no ORM |
Eloquent ORM + migrations |
| Auth | Wired, argon2id, DB sessions | Breeze / Jetstream (scaffolded, then you maintain) |
| Philosophy | Boring, zero-dep where cheap | Convention over configuration, many dependencies |
| SSR | In-process, same Bun process | Needs a separate Node process for Inertia SSR |
| Performance | 52K reads/s, 95K writes/s (M4) | 6K reads/s, 6K writes/s (FrankenPHP, 8 workers) |
The core difference is one runtime vs. four. Dulak’s whole stack is Bun; Laravel glues together PHP, Composer, a web server, and a database driver — plus a separate Node process if you want Inertia SSR. On the same hardware, Dulak is 8× faster on reads and 5× faster on writes — not because of magic, but because there is no ORM, no model hydration, and no kernel bootstrap per request (see the benchmark page). Pick Dulak for TypeScript everywhere, one runtime, raw SQL, and a lighter dependency surface. Reach for Laravel if four toolchains sounds like a feature, not a tax.
Dulak vs. CodeIgniter
Section titled “Dulak vs. CodeIgniter”CodeIgniter is a lightweight PHP MVC framework — small footprint, minimal dependencies, and a reputation for speed and simplicity. It ships routing, controllers, models, and a query builder, but fewer batteries than Laravel. A LAMP-style stack in 2026, but a respectable one.
| Dulak | CodeIgniter | |
|---|---|---|
| Runtime | One: Bun | PHP runtime + Composer + web server + DB driver |
| Language | TypeScript end to end | PHP on the server, separate client build |
| Setup | bun create dulak → bun run dev |
Install PHP, Composer, web server, DB |
| Database | bun:sqlite, raw SQL, no ORM |
Query builder (no full ORM by default) |
| Auth | Wired, argon2id, DB sessions, OAuth, reset | DIY or shield (CodeIgniter Shield) |
| Philosophy | Boring, zero-dep where cheap | Lightweight, explicit, minimal magic |
CodeIgniter and Dulak share a taste for lightweight and explicit over magic-heavy — both favor a small dependency surface and code you can follow. The difference is runtime and language: CodeIgniter is PHP on a traditional LAMP-style stack, Dulak is TypeScript on a single Bun process with auth and uploads already wired. Reach for CodeIgniter if you are committed to PHP. Pick Dulak if you want TypeScript everywhere, one runtime, and the full stack wired from day one.
Dulak vs. Rails
Section titled “Dulak vs. Rails”Rails is the canonical Ruby full-stack framework — ActiveRecord, MVC convention, Hotwire/Turbo, and the original “convention over configuration” philosophy. Also four toolchains chained together: Ruby, Bundler, a web server, and a database driver.
| Dulak | Rails | |
|---|---|---|
| Runtime | One: Bun | Ruby runtime + Bundler + web server + DB driver |
| Language | TypeScript end to end | Ruby on the server, separate client build |
| Setup | bun create dulak → bun run dev |
Install Ruby, Bundler, web server, DB |
| Database | bun:sqlite, raw SQL, no ORM |
ActiveRecord ORM + migrations |
| Auth | Wired, argon2id, DB sessions | Devise (scaffolded, then you maintain) |
| Real-time | Bring your own | Hotwire/Turbo + Action Cable built in |
Rails and Dulak share a philosophy — convention over configuration, one obvious way to do things. But Rails runs on four tools chained together (Ruby + Bundler + web server + DB driver) and ships an ORM that adds a layer between you and the query plan. Dulak runs on one runtime and hands you raw SQL. Reach for Rails if you want Ruby, ActiveRecord, and Hotwire. Pick Dulak if you want TypeScript everywhere, a single Bun runtime, and zero abstraction between you and the database.
Dulak vs. Express
Section titled “Dulak vs. Express”Express is the most widely-used Node HTTP framework — a minimal router that ships with nothing but routing. Pairing it with a template engine (EJS, Pug) gives you server-rendered HTML, but everything else is yours to wire. A router and a prayer.
| Dulak | Express | |
|---|---|---|
| What you get | Auth, SSR, uploads, migrations, tests, Docker | A router |
| Rendering | Inertia v3 + React/Svelte/Vue with SSR | Server templates, no SPA transition |
| Database | bun:sqlite + migrations |
Bring your own |
| Validation | TypeBox schemas → 422 payloads | Manual or extra lib |
| Security | CSRF, rate limit, security headers, argon2id | DIY at every layer |
Express is the “build everything yourself” path. Dulak is the “it is already built, boringly” path. Reach for Express if you want total control and zero opinions — and are willing to wire, test, and maintain every layer yourself. Pick Dulak if you want those layers wired with consistent conventions and a 67-test suite that proves they work.
When Dulak is not the right pick
Section titled “When Dulak is not the right pick”Dulak is honest about its limits. It is the wrong choice when:
- You need a microservice — Dulak is a single-process monolith.
- You need Postgres / MySQL from day one — the database layer is
bun:sqlite(swap it out, but that is your migration to own). - You need edge rendering across global regions — Dulak runs in one Bun process.
- You want a framework that abstracts the server away — Dulak exposes it: you write Hono routes and raw SQL, and that is the point.
For everything else — which is most apps — Dulak gets you from zero to deployed faster than assembling a framework stack yourself.
Summary
Section titled “Summary”| Need | Reach for |
|---|---|
| Wired full-stack on Bun, own the code | Dulak |
| RSC, edge deploy, wire everything yourself | Next.js |
| Vue end to end, wire everything yourself | Nuxt |
| Svelte end to end, wire everything yourself | SvelteKit |
| PHP MVC + ORM, four toolchains | Laravel |
| Lightweight PHP MVC, LAMP in 2026 | CodeIgniter |
| Ruby full-stack, four toolchains | Rails |
| A router and a prayer | Express |
Dulak’s bet: for a large class of apps, a boring, pinned, single-runtime boilerplate with auth and uploads already wired is a faster and more maintainable starting point than assembling a framework stack yourself.