Migrate from Next.js App Router to JSkelet — one page at a time
· 3 dk okuma
Moving a content site off the App Router does not require a big-bang rewrite. JSkelet is aimed at content sites: complete HTML, vanilla islands, and an HTML cache — with a documented migration path from Next.js.
The goal of a migration is not to re-implement React. The goal is to keep rankings and editorial workflows while cutting a client runtime you no longer need for brochure, docs, and blog surfaces.
What maps cleanly
| Next.js | JSkelet |
|---|---|
app/**/page | route() + .jsk page |
| Presentational Server Components | views/components/*.js HTML string helpers |
"use client" widgets | Island mount(element, props) |
next/image | Built-in Image / asset pipeline |
ISR / revalidate | HTML TTL + invalidateHtmlCache |
NEXT_PUBLIC_* | clientEnv (never secrets) |
generateMetadata | metadata on the page definition |
| File-based nested layouts | One root layout + explicit includes / shells |
Use jskelet migrate to scan and scaffold. Treat the report seriously: hooks-heavy modules become manual island work; nested layout trees flatten into clearer routes.
A safe order that protects SEO
- Freeze URLs. Canonical paths stay identical. Redirects are a last resort, not a migration strategy.
- Move static marketing pages first — home, compare, pricing-style surfaces with little interactivity.
- Port docs and blog read paths once templates and Markdown rendering feel solid.
- Replace client widgets with islands only where interaction is real (theme, search, demos).
- Enable the HTML cache on public GETs; mark dashboards
private: true. - Retire the React client bundle when no public page imports it.
At every step, compare HTML output and Core Web Vitals on staging. Migrations fail quietly when the URL still 200s but the first response is thinner than before.
What you deliberately leave behind
Streaming RSC as a framework feature, deeply nested layouts, and Server Actions do not map 1:1. For a brochure + blog + docs site that trade-off usually wins: less runtime, clearer caching, and HTML that search engines can read without executing a framework.
If your product is a highly interactive application, stay on the tool that matches that job. JSkelet is not a universal React replacement. It is the boring-fast choice for content.
Auth, forms, and “app-like” corners
Login and admin mutations become classic POST + CSRF + 303 flows. That feels old until you notice how much client state machine you delete. Prefer progressive enhancement for comments and contact forms; add islands only for UX sugar.
Shared secrets stay on the server. Anything that used to be NEXT_PUBLIC_ should be audited: if it was secret, it was already a bug; if it was public config, put it in clientEnv deliberately.
Team process notes
Give designers a Tailwind vocabulary that works in .jsk, not only in React Storybook. Give editors a CMS or Markdown path that does not require opening a PR for every typo — or accept that some teams still prefer PRs and document that choice.
Measure bundle graphs before and after. The win you want to show stakeholders is not “we rewrote it,” it is “the blog post no longer downloads an application runtime.”
Migrate by URL and responsibility, keep the rankings you already earned, and cut the client tax where the page was never an application to begin with.
Yorumlar
Henüz yorum yok.