Server-rendered Pages and Layouts

Server-rendered pages and layouts share a frame, then fill it with routed content

In Wappler Node.js projects, server-rendered pages and layouts work best when you see them as a shared shell plus a content contract. The layout owns the persistent frame, routed pages provide the changing content, and the server can prepare context before the page is sent to the browser.

Shared shell

Layouts hold the navbar, sidebar, and other persistent structure.

Routed content

Individual pages fill the content slot for the current route.

Server context

Data or user context can be prepared before rendering.

Use layouts for structure you want to reuse across multiple pages.

Let routed pages focus on the content specific to the current screen.

Treat server-rendered context as part of the route contract, not as scattered page magic.

A practical example is a dashboard shell with route-specific content inside it

Demo Projects HQ is a good mental model: the app uses a shared frame, then loads different routed pages into that frame while preserving navigation and other common UI. That pattern scales because the page shell and the route content are solving different jobs.

Keep shared navigation and frame concerns in the layout layer.

Let routed pages own the content and route-specific data decisions.

Use partials and server-rendered context where they simplify repetition or security-sensitive display.

Next Steps

Continue with a concrete pages or routing tour when you want to see the shell, route, and auth layout surfaces inside Wappler.

Open Layout pages and shared shells when you want the reusable frame and content slot in context.

Use Auth layouts and login pages when you want the split between public auth screens and the main app shell.

Jump back to the Pages hub when you want the broader map of routed page workflows.