Philosophy & Inspiration

Why Grit Exists

Building a modern full-stack application in 2025/2026 requires stitching together 15+ tools: Next.js, Prisma, NextAuth, tRPC, Zod, React Query, Tailwind, S3 SDK, Resend, Redis client, Bull queues, an admin panel library... Every new project starts with 2-3 days of boilerplate. Every developer makes different choices, creating inconsistent codebases that are hard to maintain.

Meanwhile, Go has incredible performance, simplicity, and deployment story. But the Go web ecosystem is fragmented -- Gin, Echo, Fiber, Chi for routing; GORM, sqlc, sqlx for databases; dozens of auth libraries. There is no equivalent to Laravel or Rails that gives you everything wired together. Go developers spend more time plumbing than building.

And then there is the admin panel problem. Laravel has Filament -- a tool that lets you generate beautiful admin dashboards, data tables, forms, and widgets from simple PHP definitions. The Go + React world has nothing comparable. Every team builds their admin panel from scratch, wasting weeks on repetitive CRUD interfaces.

Grit bridges this gap. It takes the best ideas from Laravel, Rails, and Django -- convention over configuration, batteries included, code generation -- and applies them to the most performant and modern stack available: Go for the backend, React for the frontend.

Inspiration

Grit draws inspiration from frameworks that have defined developer experience in their respective ecosystems:

• Laravel + Filament (PHP) -- The gold standard for developer experience. Artisan CLI, Eloquent ORM, and Filament's resource-based admin panel are the direct inspiration for Grit's CLI and admin panel generator.
• Ruby on Rails -- Convention over configuration, code generation with scaffolding, and the idea that frameworks should have opinions. Rails proved that opinionated frameworks make teams more productive.
• Django (Python) -- The "batteries included" philosophy. Auth, admin, ORM, and email all ship with the framework. Grit applies this same idea to Go + React.
• Next.js -- File-based routing, server-side rendering, and the best React developer experience. Grit uses Next.js as its frontend runtime.
• GORM Studio -- Our own visual database browser that evolved into a key feature of the framework. Seeing your data without leaving the browser changes how you develop.

The key insight is that no single existing framework combines Go's backend performance with React's frontend ecosystem AND a Filament-class admin panel in one coherent monorepo. Grit exists to fill that gap.

Design Principles

1. Convention Over Configuration

There is one way to do things in Grit. One auth system. One state management approach. One folder structure. One naming convention. Opinions are features, not limitations.

This means any developer can jump into any Grit project and immediately understand where things live, how data flows, and how to add new features. No more spending the first day on a project just figuring out the folder structure.

2. Code Generation Over Runtime Magic

Instead of complex runtime coupling between Go and React, Grit uses a CLI code generator. When you run grit generate resource Post, it creates all the files -- Go model, handler, React hook, Zod schema, admin page. The generated code is readable, editable, and debuggable.

There are no hidden proxies, no auto-wiring at runtime, no reflection magic. You can open any generated file, read it, understand it, and modify it. If you want to change how a handler works, just edit the file. The framework gets out of your way.

3. Own Your Code

Every piece of code Grit generates belongs to you. It is installed directly into your project, not hidden in a node_modules folder or compiled into a binary you cannot inspect. No lock-in, no black boxes.

If you ever decide to stop using Grit's CLI, your project still works. It is just a Go API, a Next.js app, and some TypeScript schemas. Standard tools, standard deployment.

4. Batteries Included, Optionally Removable

Auth, file storage, email, queues, cron, AI, and the admin panel ship with every project. But they are modular -- you can remove what you do not need. The framework should be great for a freelancer building a simple app AND for a team building a complex SaaS.

Every battery is a separate Go package and can be deleted without breaking the rest of the application. Nothing is deeply coupled.

5. Beautiful by Default

Every UI component -- the admin panel, data tables, forms, login pages -- ships with a polished dark theme. First impressions matter. When a developer runs grit new and sees the result, they should think "this looks like a real product," not "this looks like a tutorial."

The design language is inspired by tools like Linear, Vercel Dashboard, and Raycast -- dark, polished, fast. Not generic Bootstrap. Not Material Design.

6. AI-Friendly (Vibe Coding Ready)

Grit's strict conventions and predictable structure make it ideal for AI-assisted development. An AI assistant like Claude Code, Cursor, or GitHub Copilot can understand the entire project structure, generate resources, and modify code confidently because Grit follows the same patterns everywhere.

This is not an afterthought. Every naming convention, every folder structure decision, every code pattern in Grit was designed with the question: "Can an AI reliably generate this?" If the answer was no, the convention was simplified until the answer became yes.

The "Vibe Coding" Philosophy

We believe the future of software development is a collaboration between human developers and AI assistants. Grit is designed from the ground up for this paradigm.

When you describe a feature to an AI assistant -- "add a blog with posts, categories, and tags" -- the AI should be able to:

1. Run grit generate resource Post, grit generate resource Category, and grit generate resource Tag
2. Add relationships between the generated models
3. Customize the admin panel columns and form fields
4. Add frontend pages that display the blog

This works because Grit's patterns are predictable. The AI knows exactly where models live, how handlers are structured, where hooks go, and how the admin panel is configured. There is no ambiguity.

Frameworks that let developers "choose your own adventure" at every step make AI assistance unreliable. Grit's opinionated nature is what makes vibe coding work.

Why Go + React?

We considered every major backend/frontend pairing. Here is why Go + React won:

Why Go (and not Node.js, Python, Ruby, or PHP)?

• Performance: Go is 10-50x faster than Node.js/PHP for CPU-bound work. A single Go binary can handle 100k+ concurrent connections with minimal memory usage.
• Simplicity: Go has 25 keywords. The language is small, explicit, and readable. There is no magic, no metaprogramming, no inheritance hierarchies.
• Deployment: Go compiles to a single static binary. No runtime dependencies, no version managers, no interpreters. Copy the binary to a server and run it.
• Type Safety: Go's static type system catches bugs at compile time. Combined with GORM's struct tags and Zod on the frontend, you get end-to-end type safety from database to UI.
• Growing Ecosystem: Go is the fastest-growing backend language. Companies like Google, Uber, Twitch, Cloudflare, and Docker use it in production.

Why React (and not Vue, Svelte, or HTMX)?

• Ecosystem: React has the largest component ecosystem of any frontend framework. shadcn/ui, Radix, React Query, Recharts -- the best tools are built for React first.
• Hiring: More developers know React than any other frontend framework. If you are building a team or hiring freelancers, React is the safest bet.
• Next.js: The App Router provides file-based routing, server-side rendering, static generation, and streaming -- all built on React.
• React Native: With Grit's --full flag, you can add an Expo mobile app that shares types and validation with the web frontend. Same language, same patterns, mobile and web.

Why Not Full-Stack JavaScript?

Serverless is not always the answer. For many applications -- CRMs, SaaS tools, internal dashboards, apps with WebSockets, background jobs, or heavy processing -- a real backend server is superior. Go gives you a single binary that handles massive concurrency, deploys anywhere, and costs a fraction of serverless.

And while TypeScript is excellent on the frontend, Go's simplicity and performance make it a better choice for backend services that need to handle real load.