Consider simplifying the architecture: Vite SPA or build-time RSC with Next.js

[kotarotaniguchi0523]

Thanks for building such a cool project! As a fellow developer from Japan, I really respect what you’ve built here.

I have one small architecture suggestion after reading the code.

The app currently seems to use Next.js mainly for static export, metadata, routing structure, and dynamic loading, while the main editor is effectively client-only ("use client" + ssr: false). Because of that, the project feels like it currently sits between two architectures:

• a traditional client-side React SPA
• a static Next.js app that could use RSC at build time

Would it make sense to choose one direction more explicitly?

Option 1: Vite + React SPA

If the editor is intentionally browser-only, Vite + React may better match the current architecture. It could simplify the build setup, remove RSC / Server-Client boundary concerns, and reduce framework-specific dependencies and maintenance surface.

A smaller dependency and framework surface can also be beneficial from a security perspective: fewer dependencies generally means fewer packages and framework-specific behaviors that need to be monitored, updated, and audited over time.

Option 2: Keep Next.js and lean into build-time RSC

Since the project already uses output: "export", RSC can still be rendered at build time and deployed as static files to GitHub Pages.

In that case, it might be worth moving static or render-only parts back to Server Components, while keeping only genuinely interactive parts on the client, such as:

• canvas interactions
• drag / pan / zoom
• selection and history
• dialogs and local browser state
• AI actions

Static parts such as the app shell, catalogs, presets, labels, and other render-only UI could potentially stay on the build-time RSC side.

My main thought is that either direction would make the architecture more intentional:

• if this is fundamentally a client-only editor, Vite + React could make the stack simpler;
• if Next.js is kept, build-time RSC could make better use of what Next.js already provides.

Curious what you think about this direction.

[lnkiai]

Thank you for reading through the code so carefully, and for the kind words.

The current shape is deliberate. The editor is a browser-only tool: the document lives in local storage and nearly everything on screen reacts to it, so very little would render once at build time and stay static. #429 made that explicit by keeping the page itself a small entry and loading the editor on the client. Next.js is used for what it already does well here: the static export to GitHub Pages, metadata, icons and the manifest.

Moving to Vite would mean rebuilding the build and deploy with no change for people using the app, and moving parts back to Server Components would add a server/client boundary to an app that has no server. So I am keeping the current setup for now. If Next.js starts getting in the way, for example in build time, bundle size or a dependency issue that actually affects us, I will revisit this, and this thread is a good place to pick it up again.