Jeston supports both the established pages/ convention and an App Router-style app/ convention. That gives teams a gradual path: keep existing pages while adopting layouts and route handlers where they provide value.
A clear file-to-behavior mapping
An App Router application can use page.tsx for a page, route.ts for an HTTP handler, and layout.tsx for a persistent layout. Rendering boundaries are explicit as well: loading.tsx handles loading UI, error.tsx defines a segment error boundary, and not-found.tsx provides a custom 404 experience.
Authorization errors can have typed UI boundaries through forbidden.tsx and unauthorized.tsx. Route groups such as (marketing) help organize code without changing the public URL.
Composition without a migration dependency
Layouts compose from the application root toward the leaf route. Existing pages/ applications do not need to migrate before using the rest of the framework. This matters for large products: routing strategy can evolve by slice instead of becoming a single migration project.
Server mutations
Server mutations can live in actions/ modules with the use server directive. Jeston assigns stable action IDs during the build and exposes a bounded, origin-checked POST transport. Inputs and outputs must be JSON-serializable, which keeps the boundary inspectable and testable.
Client navigation
For same-origin navigation, the client package provides Link, createRouter, and prefetch. These primitives support cancellable navigation and let applications control how route transitions behave.
The result is a routing model that makes file placement, rendering boundaries, authorization states, and server actions visible in the codebase. Read more at github.com/kvantjs/jeston.
Top comments (0)