标签：#NeXT

Over the weekend, I participated in the OpenAI Build Week Hackathon with a simple goal: Build something I would actually use as a developer. By Friday evening, I had an idea. By Sunday, that idea became an open source project called Arcovia . It wasn't just another AI coding experiment. I wanted to solve a problem I've faced while working on large React applications for years. The Problem We have excellent tools for code quality. ESLint catches code smells. Prettier formats code. SonarQube reports issues. AI reviews code and suggests improvements. But none of them answer questions like: Is my architecture healthy? Which modules are becoming bottlenecks? Where is technical debt accumulating? Which files should I refactor first? Why did my project receive this score? Architecture is often something we discuss during code reviews or realize too late when the codebase becomes difficult to maintain. I wanted a tool that could measure architecture health before it became a problem. Introducing Arcovia Arcovia is an Architecture Intelligence tool for React and Next.js projects. Instead of generating hundreds of isolated warnings, it analyzes the project as a whole and produces an interactive HTML report. It includes: 📊 Architecture Health Score 🕸️ Dependency Graph 🎯 Architecture Hotspots 📈 Explainable Score Breakdown 🛠️ Rule-based Findings 📉 Maintenance Burden ✅ Actionable Recommendations The goal isn't to replace linting. The goal is to help developers understand the bigger picture. How It Works Internally, Arcovia follows a deterministic analysis pipeline. Project │ ▼ Scanner │ ▼ AST Parser │ ▼ Project Model │ ▼ Dependency Graph │ ▼ Rule Engine │ ▼ Score Engine │ ▼ Interactive HTML Report The analyzer currently detects things like: God Modules High Fan-In High Fan-Out Orphan Modules Large Components Deep JSX Nesting Oversized Modules Duplicate Imports Unused Exports Instead of simply reporting findings, Arcovia combines them into an explainable architecture score. Determ

The Great Migration: Moving Beyond the SPA If you have been building in the React ecosystem recently, you've likely started with Vite. It’s fast, the Developer Experience (DX) is unparalleled, and it just works. However, as projects scale, the requirements often evolve. You suddenly need better SEO, faster First Contentful Paint (FCP), or sophisticated server-side logic without managing a separate backend. This is usually when the conversation turns to Next.js. While the migration seems straightforward on paper—it's all just React, right?—the reality involves a fundamental shift in how you think about routing, data fetching, and the browser lifecycle. Here is everything I wish I knew before I made the jump from Vite to Next.js. 1. Routing: From Configuration to Convention In a Vite project, you probably used react-router-dom . You defined a <Routes> component, listed your paths, and mapped them to components. It was explicit and centralized. Next.js (specifically the App Router) uses file-system routing. Every folder in your app directory represents a route segment. The Shift in Thinking Vite: You decide where files live; the router links them. Next.js: The folder structure is the URL structure. You will spend your first few hours moving About.tsx to about/page.tsx . It feels tedious at first, but it eliminates a massive category of "broken link" bugs and makes code-splitting automatic. 2. The "use client" Directive This is perhaps the biggest stumbling block for Vite developers. In Vite, every component is a client component—it runs in the browser. In Next.js, components are Server Components by default. If you try to use useState , useEffect , or browser APIs like window or localStorage in a default Next.js component, your build will crash. You must add the 'use client' directive at the top of the file. Pro-Tip: Don't just add 'use client' to everything. The goal is to keep as much logic as possible on the server to reduce the JavaScript bundle sent to the client.

Every developer has a "starter project." Some keep a GitHub template. Some duplicate their previous SaaS project. Some run create-next-app and spend the next two hours installing the same dependencies, configuring the same tools, and recreating the same folder structure. I was in the second group. Every new project started the same way. bun create next-app Then came the checklist. Install Tailwind CSS. Configure Biome. Add shadcn/ui. Organize folders. Set up a UI library. Configure TypeScript. Add environment files. Set up a monorepo. Copy utility functions. Configure path aliases. Install development tools. None of these tasks were difficult. They were just repetitive. After starting enough projects, I realized something: I wasn't building products. I was rebuilding the same foundation over and over again. The Starter Kit Trap Like many developers, I created a "starter repository." Whenever I wanted to build something new, I'd clone it. It worked... until it didn't. Eventually I had multiple starter repositories. One for a monorepo. One for a standalone project. One with authentication. One without authentication. One for experiments. One that was already outdated. Keeping them synchronized became its own maintenance project. Fix a bug in one. Forget to fix it in another. Upgrade Next.js in one repository. Forget the rest. The more starters I created, the less useful they became. Why Existing Starters Didn't Quite Fit There are already fantastic starter kits in the ecosystem. Some focus on minimalism. Others include every feature imaginable. The problem wasn't that they were bad. The problem was that they optimized for someone else's workflow. Every project I build starts with almost the same stack. Next.js TypeScript Bun/pnpm Tailwind CSS v4 shadcn/ui Biome Production-ready project structure I didn't want to answer twenty configuration questions every time I scaffolded a project. I wanted one command. npx create-notils my-app …and be ready to start building. Opini

The Architectural Shift: Client-Side vs Server-Side For years, the standard for building modern React applications was the Single Page Application (SPA). Vite revolutionized this space by providing an incredibly fast developer experience (DX) and an optimized build process. However, as applications grow, many teams find themselves hitting the performance ceiling of client-side rendering. When we talk about migrating from a Vite-based SPA to Next.js, we aren't just changing build tools; we are moving from a model where the browser does all the work to a model where the server shares the load. In this article, we'll look at the benchmarks of a mid-sized e-commerce dashboard before and after migration. Understanding the Core Metrics To measure the impact truly, we focus on three Core Web Vitals: LCP (Largest Contentful Paint): How quickly the main content is visible. FID (First Input Delay): How responsive the page is to the first interaction. CLS (Cumulative Layout Shift): How stable the visual elements are during loading. Vite SPA Performance (The Baseline) In a Vite SPA, the initial HTML request returns a nearly empty <body> tag with a <script> bundle. The browser must: Download the HTML. Download the JavaScript bundle. Parse and execute the React code. Fetch data from an API. Finally, render the UI. Benchmark Results: LCP: 2.4s (on 4G connection) FID: 45ms TBT (Total Blocking Time): 320ms While the DX is lightning fast, the user experience suffers from the "white screen of death" during the initial bundle download. Next.js SSR/ISR Performance (The Post-Migration Result) Next.js changes this via Server-Side Rendering (SSR) or Incremental Static Regeneration (ISR). The server fetches data and pre-renders the HTML. The browser receives a fully formed UI immediately. Benchmark Results: LCP: 0.8s (on 4G connection) FID: 55ms TBT: 180ms There is a slight increase in FID because the browser's main thread is busy "hydrating" the static HTML into an interactive React app, b

🇮🇩 Originally written in Indonesian. This English version was AI-assisted and adapted for a more natural reading experience. It is not a literal translation. _open Introduction Lately, I've been having quite a few discussions with frontend developers about the frameworks they use. My question is actually pretty simple. "When you're building a web frontend, what framework do you usually use?" Almost everyone gave more or less the same answer. "It depends on the project." And honestly, I agree. There's no framework that's always the best choice for every situation. However, as the conversation went on, they started sharing their own experiences and preferences. Well... That's when I started noticing an interesting pattern. Among the developers I talked to, quite a few of them mentioned that they usually use Next.js / React for work, while Vue.js is what they often choose for personal projects. The interesting part is... I never actually asked, "What do you use at work?" or "What do you use for personal projects?" That explanation came up naturally as they explained why they preferred certain frameworks. At first, I thought it was just a coincidence. But after hearing the same pattern from several different people... I got curious. Why do so many developers who are comfortable with both frameworks end up separating how they use them? (・_・;) Disclaimer This isn't based on an official survey or research. It's simply an interesting pattern I noticed after talking with several frontend developers. Discussion Vue.js Looking at today's frontend ecosystem, Vue.js is clearly not a small framework. Its community is large. Its documentation is great. Its ecosystem is also quite mature. That said, compared to React and Next.js, its community is still smaller. Then another question comes to mind. If that's the case... Why do so many developers still choose Vue.js for personal projects? From the answers I heard, the main reason wasn't performance. And it wasn't because other framew

Artikel ini juga tersedia dalam bahasa Inggris Pendahuluan Beberapa waktu terakhir saya sering berdiskusi dengan beberapa frontend developer mengenai framework yang mereka gunakan. Pertanyaan saya sebenarnya sederhana. "Kalau membuat frontend web, biasanya pakai framework apa?" Hampir semuanya memberikan jawaban yang kurang lebih sama. "Tergantung kebutuhan." Dan saya setuju. Tidak ada framework yang selalu menjadi pilihan terbaik untuk semua kondisi. Namun, setelah pembahasannya berlanjut, mereka mulai menceritakan pengalaman dan preferensinya masing-masing. Nah... Di sinilah saya mulai menemukan pola yang menarik. Dari beberapa developer yang saya ajak berdiskusi, cukup banyak yang mengatakan bahwa mereka lebih sering menggunakan Next.js / React untuk pekerjaan, sedangkan Vue.js lebih sering digunakan untuk personal project. Padahal saya tidak pernah bertanya, "Kalau kerja pakai apa?" atau "Kalau project pribadi pakai apa?" Penjelasan itu muncul begitu saja ketika mereka mulai menjelaskan alasan di balik framework yang mereka pilih. Awalnya saya mengira itu hanya kebetulan. Tapi setelah mendengar pola yang sama dari beberapa orang... Saya jadi penasaran. Kenapa banyak developer yang sudah menguasai keduanya justru memilih memisahkan penggunaannya? (・_・;) Disclaimer Tulisan ini bukan hasil survei atau penelitian resmi. Ini hanyalah pola yang saya temui dari beberapa frontend developer yang sempat saya ajak berdiskusi. Pembahasan Vue.js Kalau melihat ekosistem frontend saat ini, Vue.js jelas bukan framework yang kecil. Komunitasnya besar. Dokumentasinya bagus. Ekosistemnya juga sudah cukup matang. Namun memang harus diakui, jika dibandingkan dengan React dan Next.js, komunitasnya memang masih lebih kecil. Lalu muncul pertanyaan. Kalau begitu... Kenapa masih banyak yang memilih Vue.js untuk personal project? Dari beberapa jawaban yang saya dengar, ternyata alasan utamanya bukan karena performa. Bukan juga karena framework lain kurang bagus. Melainkan karena pengalama

When building scalable systems, we often need a collection of classes to expose a fixed, read-only configuration value. Whether it is a unique API_ENDPOINT, a DATABASE_TABLE name, or a specific PERMISSIONS_MASK, handling constants across a series of classes looks simple on day one but can quickly turn into an architectural nightmare. Setting the Foundation: How to Make It In modern object-oriented programming, the standard way to declare a constant on a class is by leveraging the static readonly modifiers. This ensures the attribute belongs to the class itself, rather than an instance, and cannot be mutated at runtime. TypeScript class BillingService { static readonly SERVICE_TYPE = "BILLING"; } class InventoryService { static readonly SERVICE_TYPE = "INVENTORY"; } This works perfectly when you know exactly which class you are dealing with at compile time. You simply call BillingService.SERVICE_TYPE and move on. The Architectural Breakdown: What Will Be the Problems The clean code facade breaks the moment you attempt to handle these classes dynamically. In production environments, you rarely hardcode class names; instead, you process them as an array or a series of registry keys. Loss of Type Safety: If you pass a series of these classes into a processing function, standard type systems will treat them as generic constructor functions, wiping out access to the static property unless you resort to unsafe type casting. Polymorphism Failure: Subclasses do not inherently enforce or override static properties cleanly through standard interfaces. You cannot enforce a static readonly property on an interface, meaning a developer could easily forget to define the constant on a new service class, causing silent runtime failures. Instance vs. Class Metadata Confusion: If your architecture receives an instance of the class rather than the class definition itself, accessing the static attribute requires jumping through hoops like instance.constructor.SERVICE_TYPE, which breaks

Parallel Routes let you render multiple pages simultaneously within the same layout. Instead of navigating away from a page to show another one, you can display both at the same time — a dashboard with independently navigable sections, a main content area alongside a sidebar that changes with its own navigation, or a feed with an openable detail panel that doesn't replace the feed. This is one of the more powerful App Router features and one of the more confusing to set up initially. Here's the complete pattern, including the design approach used for complex multi-panel interfaces like the generation tool at Pixova . The Core Concept — Named Slots Parallel routes use named slots: special folders prefixed with @ that define independent rendering areas within a layout. app/ ├── layout.tsx ← Receives slot props ├── page.tsx ← Default slot content ├── @sidebar/ │ ├── page.tsx ← Sidebar default │ └── settings/ │ └── page.tsx ← Sidebar settings view └── @modal/ ├── page.tsx ← Modal default (null) └── photo/[id]/ └── page.tsx ← Photo modal The layout receives each slot as a prop: // app/layout.tsx export default function Layout ({ children , sidebar , modal , }: { children : React . ReactNode ; sidebar : React . ReactNode ; modal : React . ReactNode ; }) { return ( < div className = "flex h-screen" > < aside className = "w-64 border-r" > { sidebar } </ aside > < main className = "flex-1" > { children } </ main > { modal } </ div > ); } Now children , sidebar , and modal can each navigate independently. Independent Navigation — The Key Behavior Each parallel route slot navigates independently. When a user navigates from / to /settings , the children slot updates. The sidebar slot stays exactly where it was — its navigation state is independent. This is the key difference from nested layouts. Nested layouts rerender from the changed segment outward. Parallel routes don't affect each other. User is at / (children shows home, sidebar shows default nav) User navigates to /setti

Sanity's hotspot and crop system works well when all the pieces line up — but if your rendered image is ignoring the focal point you set in Studio, one of four things is almost certainly wrong. None of them are subtle bugs; they're all configuration mistakes that are easy to miss and easy to fix. The four causes (and their fixes) 1. fit is still set to clip instead of crop This is the most common cause. The @sanity/image-url builder defaults to fit('clip') , which scales the image to fit inside the requested dimensions without cropping anything. Hotspot data is only applied when the builder is told to crop — that is, when it cuts the image down to the requested dimensions, centering the cut on the focal point. Fix: always chain .fit('crop') when you pass .width() and .height() . // src/lib/sanity-image.ts import imageUrlBuilder from ' @sanity/image-url ' import { client } from ' ./sanity-client ' const builder = imageUrlBuilder ( client ) export function urlFor ( source : SanityImageSource ) { return builder . image ( source ) } // Usage — hotspot will only apply if fit is 'crop' const url = urlFor ( image ) . width ( 800 ) . height ( 600 ) . fit ( ' crop ' ) // <-- required for hotspot to do anything . auto ( ' format ' ) . url () Without .fit('crop') , Sanity's CDN receives no crop instruction and the hotspot coordinates are silently ignored. 2. Missing options: { hotspot: true } on the schema field If the image field in your Sanity schema is not configured with hotspot support, Studio never renders the focal point UI, and the hotspot and crop keys are never written to the document in the first place. The URL builder can't use data that isn't there. Fix: add options: { hotspot: true } to every image field where editors need focal control. // schemas/post.ts export default { name : ' post ' , type : ' document ' , fields : [ { name : ' coverImage ' , type : ' image ' , options : { hotspot : true , // <-- enables the focal point UI in Studio }, }, ], } After adding

Sanity vs Directus is a comparison that comes up more than you'd expect on technical forums in 2026, usually from teams who already have a Postgres database running and are wondering why they'd pay for a separate content lake when Directus can wrap what they have. It's a fair question. These two tools solve adjacent problems but from genuinely different starting points, and the right choice depends heavily on whether your content is primarily relational data or editorial content. What each tool actually is Sanity is a hosted content platform. Your content lives in Sanity's managed "content lake" — a document store with real-time collaboration, a CDN-backed asset pipeline, and GROQ as the query language. You define schemas in code, deploy a customisable Studio, and talk to Sanity's API from your Next.js app. You do not manage infrastructure. Directus is an open-source data platform that wraps any existing SQL database — Postgres, MySQL, SQLite, MS SQL — and exposes it through a REST API, a GraphQL endpoint, and a web-based admin UI. Schema changes happen in the admin UI (or via migrations), and your data stays in your own database. You can self-host entirely or use Directus Cloud. That distinction — hosted content lake vs database-wrapper — drives nearly every practical difference between them. Data ownership and where your content lives With Sanity, your content lives in Sanity's infrastructure. You can export it via the export API, but you are operationally dependent on Sanity's uptime and their CDN. For most product teams that's fine — Sanity has been reliable and their SLA on Growth/Enterprise tiers is solid. But if you're in a regulated industry, have strict data residency requirements, or your client contract requires them to own the database, it's a real constraint. With Directus, the database is yours from day one. You point Directus at a Postgres instance on your own infrastructure (or a managed one like Supabase, Neon, or Railway), and Directus adds the API

While building with OpenAI, Anthropic, and other AI providers, I realized something surprising. I monitored my servers, databases, and application performance—but I had almost no visibility into my AI API spending until I checked the provider dashboard or received the monthly invoice. That led me to build AICostPass . It helps developers, indie hackers, startups, and agencies: ⚡ Track AI API costs in near real time 📊 Monitor spending by project or client 🚨 Get budget threshold email alerts 📧 Receive weekly spending summaries 💰 Export billable CSVs for client invoicing The goal is simple: help developers understand and control AI costs before the invoice arrives. 👉 https://aicostpass.com I'd love to hear how you're currently tracking AI API costs. Are you using provider dashboards, spreadsheets, or another tool?

The Architecture Shift: SPA vs. Framework Internationalization (i18n) is one of those features that feels straightforward in a Single Page Application (SPA). You install react-i18next , wrap your app in a provider, and you're good to go. However, when you decide to migrate that Vite-based React app to Next.js for better SEO and performance, the strategy for i18n changes fundamentally. In a Vite SPA, i18n is typically client-side. In Next.js, i18n happens at the routing and server level. If you don't plan the migration carefully, you'll end up with hydration mismatches, flashing text, or broken search engine indexing. Here is how to navigate the transition. 1. Defining the Routing Strategy In Vite, your translations often live in the same bundle, and you swap them out using a state hook. Next.js, particularly with the App Router, prefers sub-path routing (e.g., /en/about or /es/about ). This is crucial for SEO because it allows search engines to crawl localized versions of your pages individually. Instead of relying on localStorage to remember a user's language, you should now rely on the URL. Most teams moving from Vite use a middleware approach to detect the user's preferred locale and redirect them to the correct sub-path. 2. Choosing the Right Library If you were using react-i18next in your Vite project, you have two main paths in Next.js: next-i18next (Pages Router): The traditional choice for the Pages Router. next-intl or i18next + i18next-resources-to-backend (App Router): These are modern solutions that leverage Server Components. When handling complex migrations involving many components, using a specialized tool like ViteToNext.AI can help automate the transformation of your Vite project structure into a Next.js-ready architecture, saving you hours of manual refactoring. 3. Handling Server Components vs. Client Components one of the biggest hurdles is that useTranslation() hooks from standard i18n libraries are "Client hooks." In the App Router, you'll wan

Every business wants more leads. But the real challenge isn't generating them—it's identifying which leads deserve your team's attention first. Instead of manually reviewing every inquiry, we can build a simple AI-powered API that analyzes incoming leads and assigns a priority score automatically. In this article, I'll show a lightweight production-ready approach using Next.js 15 and Gemini 3.5 Flash. Project Structure app/ ├── api/ │ └── qualify/ │ └── route.ts ├── lib/ │ └── gemini.ts └── page.tsx API Route import { NextResponse } from "next/server"; export async function POST(req: Request) { const { company, message } = await req.json(); const prompt = ` Company: ${company} Message: ${message} Give: - Score (1-100) - Priority - Reason `; // Call Gemini API here return NextResponse.json({ success: true, score: 92, priority: "High" }); } Example Response { " score " : 92 , " priority " : " High " , " reason " : " Large company with a clear automation requirement. " } Now your CRM, chatbot, or automation workflow can instantly decide which leads should be contacted first. Why This Matters A simple AI scoring layer can help teams: Reduce manual lead review Respond faster to high-value prospects Prioritize enterprise customers Improve sales efficiency Save hours every week The best part is that this API can be connected to forms, chatbots, CRMs, or n8n workflows without changing your existing process. Production Tips Before deploying this to production, make sure you: Validate incoming requests Store API keys securely Add rate limiting Log AI responses for monitoring Cache repeated requests where appropriate Small improvements like these make a huge difference once traffic starts growing. Final Thoughts AI shouldn't replace your sales team—it should remove repetitive work so they can focus on conversations that actually matter. A lightweight lead qualification API is one of the fastest AI features you can add to an existing product, and it scales well as your business

The problem with most web UIs is the gap between user action and visible feedback. A user clicks "like" and waits 200-400ms for the server to respond before the button changes. That delay reads as slowness even when the server is fast. The network round-trip is the ceiling. Optimistic UI inverts this: assume the operation will succeed, update the UI immediately, then reconcile with the server response when it arrives. If the server fails, roll back. React 19's useOptimistic hook gives you this pattern with minimal boilerplate and automatic rollback built in. The API const [ optimisticState , addOptimistic ] = useOptimistic ( state , // the current "real" state — synced from server updateFn , // (currentState, optimisticValue) => newOptimisticState ) optimisticState — during a pending transition, reflects the optimistic update. Once the transition completes, it reverts to state addOptimistic(value) — triggers an optimistic update, must be called inside startTransition Pattern 1: Like Button ' use client ' import { useOptimistic , useTransition } from ' react ' import { toggleLike } from ' @/actions/likes ' type LikeState = { liked : boolean ; count : number } export function LikeButton ({ postId , initialLiked , initialCount }: { postId : string initialLiked : boolean initialCount : number }) { const [ isPending , startTransition ] = useTransition () const [ optimisticState , addOptimistic ] = useOptimistic < LikeState > ( { liked : initialLiked , count : initialCount }, ( current ) => ({ liked : ! current . liked , count : current . liked ? current . count - 1 : current . count + 1 , }) ) function handleToggle () { startTransition ( async () => { addOptimistic ( ' toggle ' ) // updates UI immediately await toggleLike ({ postId }) // syncs with server }) } return ( < button onClick = { handleToggle } disabled = { isPending } > < Heart className = { cn ( ' h-4 w-4 ' , optimisticState . liked && ' fill-red-500 text-red-500 ' ) } /> < span > { optimisticState . count }

Try the demo: K-Saju Crew For fun only. K-Saju is an entertainment project. The K-Pop roles below are a playful interpretation of saju-inspired signals, not personality assessment or advice. A two-person compatibility page can stay stateless with almost no effort. Put both birth dates in a URL, render the result on the server, and the link is the record. No account, no database, no cleanup job. That was already a product rule in K-Saju. We do not retain personal inputs. A result is reproducible from its GET parameters. Then we built /crew : “What if your friend group debuted as a K-Pop group?” A creator makes a link, sends it to a group chat, and each friend enters their own birth date. At three to seven members, the app assigns distinct positions, shows pairwise chemistry, and creates a shareable poster. The fun part is the casting. The engineering problem is that the social flow needs a temporary shared state. A link cannot accumulate submissions by itself. This post is about the decisions behind that feature: where we allowed state, how we made the result durable without retaining a lobby forever, and how we kept the casting explainable instead of treating it as a black-box score. The conflict: a self-service group flow needs somewhere to collect data There were two clean but incomplete options. The first was to keep everything stateless. The creator would enter all members' dates at once, then receive a result URL. It matched our existing architecture, but it defeated the point of sharing a link. The person who starts the group often does not know everyone else's date, and asking them to collect it in a chat creates friction before the feature has started. The second was a conventional persistent group object. It would make joining easy, but it would turn a deliberately stateless service into one that keeps user-provided dates indefinitely unless we built retention and deletion policies around it. We chose a hybrid instead: The lobby is temporary state. It store

Earlier this month I shipped two premium templates — a SaaS landing page and a developer portfolio. Not a startup, not a SaaS, just templates. This post is about the two constraints I built them under, why they made the code better, and a few things I learned launching as a solo dev with zero audience. Constraint 1: zero dependencies beyond next, react, and tailwind Open the package.json of most templates and you'll find 20+ packages: icon libraries, animation libraries, carousel plugins, UI kits, utility libraries. Every one of them is a version conflict waiting to happen for the buyer, and most are replaceable with a few lines of code in 2026. What I used instead: Icons → inline SVG components. An icon component is ~10 lines. You need maybe 15 icons for a landing page. Animations → plain CSS. Scroll-blur navbars, gradient glows, an animated "typing" terminal — all doable with keyframes and transitions. No framer-motion. The dashboard mockup in the hero → pure CSS. Divs, borders, gradients. It looks like a product screenshot but it's ~80 lines of JSX and weighs nothing. Result: both templates land at ~100KB first-load JS, npm install takes seconds, and there is nothing to break when Next.js 16 arrives. Constraint 2: every piece of content in ONE typed config file The thing I hated most about templates I've used: content is smeared across 30 components. Changing a headline means hunting through JSX. So both templates keep all content in a single file — lib/content.ts for the landing page, site.config.ts for the portfolio. Headlines, nav, pricing tiers, testimonials, project lists, even the lines that animate in the fake terminal. Components are pure renderers of that config's TypeScript type. Two things surprised me here: TypeScript becomes your content linter. Forget an alt text, malform a link, give a pricing tier three features when the type expects a non-empty array — the build fails. Content mistakes surface at compile time. It forces better component design. W

Everyone can type "use client" . Almost nobody can say what survives the trip across it — and then something breaks: next build dies at prerender, the error names no file and no import chain, and the prop that killed it was an arrow one level down inside an object called options . Here's the uncomfortable secret: the boundary is one serializer . React walks every prop you hand a client component, encodes each value it has a branch for, and throws on the first one it doesn't. This post reads those branches out of React 19's Flight source — one file, no framework — and shows the two traps that pass code review and fail the build anyway. What crosses A prop is legal if the serializer has a branch for it. Everything else falls into one prototype check and throws. The whole contract fits on a screen: // app/page.tsx — a Server Component. Every comment is the serializer's verdict. export default function Page () { return ( < Chart title = "Q3" data = { { rows : [ 1 , 2 , 3 ] } } when = { new Date () } seen = { new Set ([ 1 ]) } index = { new Map () } rows = { fetchRows () } // an un-awaited Promise; the client calls use(rows) bytes = { new Uint8Array ( 8 ) } // ArrayBuffer, DataView, every typed array upload = { new File ([], ' a.csv ' ) } // there is no File branch — a File is a Blob form = { new FormData () } stream = { new ReadableStream () } kind = { Symbol . for ( ' chart ' ) } // global symbols cross; Symbol('chart') throws Slot = { Legend } // a client component: a function, and a client reference save = { saveRow } // a "use server" function: a server reference err = { new Error ( ' boom ' ) } // crosses — and arrives empty in production // no branch — every one of these throws at render match = { /q3/ } href = { new URL ( ' https://x.dev ' ) } cache = { new WeakMap () } user = { new User ( ' ada ' ) } bare = { Object . create ( null ) } onPick = { ( id ) => select ( id ) } /> ); } Four of those lines are the ones people get wrong: new Error() crosses, and product

Headline: React Compiler — formerly React Forget — shipped stable with React 19 and automatically memoizes components, hooks, and callbacks by analyzing data flow at build time. No dependency arrays to write; the compiler infers them. Here is what it handles, when it opts out, and whether you should delete your useMemo calls. Key takeaways React Compiler inserts useMemo , useCallback , and React.memo automatically at build time — no dependency arrays to maintain. Enable it in Next.js 15/16 with experimental.reactCompiler: true in next.config.ts . The compiler is conservative: if it cannot prove memoization is safe, it emits the component unchanged. "use no memo" is the escape hatch for functions the compiler should not touch. Run npx react-compiler-healthcheck@latest before enabling to see coverage and violations. What does React Compiler actually do? React Compiler transforms component and hook code at build time to insert memoization automatically. Instead of useMemo(() => expensiveCalc(a, b), [a, b]) , the compiler analyzes data flow, determines which values are stable across renders, and emits equivalent memoized code. The compiled output uses React's memo infrastructure at runtime. The compiler is babel-plugin-react-compiler — it works with any Babel-based build pipeline. How do I enable it in Next.js? // next.config.ts const nextConfig = { experimental : { reactCompiler : true , }, }; export default nextConfig ; Before enabling, run the healthcheck: npx react-compiler-healthcheck@latest The healthcheck reports optimizable component count, files with violations, and blocking patterns. Fix violations first for more coverage on day one. What does the compiler memoize? Components — equivalent to React.memo ; re-renders only when props change. Values — equivalent to useMemo ; computed results, derived arrays, objects. Callbacks — equivalent to useCallback : event handlers, functions passed as props. Dependencies are inferred from escape analysis — n

Headline: Partial Prerendering (PPR) in Next.js serves a static HTML shell from the CDN edge instantly, then streams Suspense-wrapped dynamic children from the origin in the same HTTP response. No full-page ISR staleness, no full-page origin latency. I shipped it on two production routes — here is the model. Key takeaways PPR serves a static HTML shell from the CDN edge , then streams dynamic Suspense children from the origin in the same response. The static shell is built at build time — outside <Suspense> renders statically; inside renders dynamically per request. PPR replaces the ISR vs. dynamic tradeoff for pages that are mostly static with isolated personalized sections. No changes to Server Components or Suspense — just experimental.ppr: 'incremental' in config and export const experimental_ppr = true per route. PPR and use cache are complementary : CDN delivery for the shell, origin memoization for dynamic islands. What does PPR actually do? PPR splits a page into two rendering phases within the same HTTP response. At build time, Next.js freezes everything that does not read dynamic request data into a static HTML shell on the CDN edge. At request time, the CDN delivers the shell at edge latency while the origin streams each <Suspense> boundary's content into the same response. On a product page: navigation, title, and description arrive at CDN speed. The in-stock badge and personalized recommendations stream from the origin a fraction of a second later. The user sees a nearly-complete page immediately. How is PPR different from ISR and streaming Suspense? Strategy First byte Dynamic freshness Staleness ISR (revalidate: N) CDN edge Whole page up to N seconds stale Full page Dynamic rendering Origin 100% fresh; waits for slowest query None Streaming Suspense (no PPR) Origin Fresh; TTFB includes origin latency None PPR CDN edge Dynamic islands 100% fresh Static shell only How do I enable PPR? // next.config.ts export default { experimental : { ppr : ' inc

Introduction If you have been building applications using Vite, you are likely used to a specific workflow: write React components, bundle them with esbuild/Rollup, and serve a single HTML file that fetches a large JavaScript bundle. In this world, everything is a "Client Component." However, as the React ecosystem shifts toward the App Router and React Server Components (RSC), the architecture is fundamentally changing. For developers moving from a Vite-centric mindset to a Next.js framework, the biggest hurdle isn't the syntax—it's the mental model. In this guide, we will break down the core differences between Server and Client components and how to adapt your Vite-based habits to this new reality. The Vite World: Single-Page Application (SPA) Default In a standard Vite + React project, your entire application lifecycle happens in the browser. The browser requests the page. The server sends a nearly empty index.html . The browser downloads the JS bundle. React hydrates the app, fetches data from an API via useEffect , and renders the UI. While this is excellent for developer experience (DX) and highly interactive dashboards, it often leads to "Layout Shift" and slower "Time to Interactive" for content-heavy pages because the client has to do all the heavy lifting. The Shift: Thinking in "Environment Splits" With React Server Components, the paradigm shifts from "Everything happens on the client" to "Compute where it makes sense." 1. What are Server Components? By default, in the Next.js App Router, every component is a Server Component. These components execute only on the server . They never send their code to the client-side bundle. This allows you to: Access backend resources directly: You can query your database or file system inside the component. Keep secrets safe: API keys and sensitive logic stay on the server. Reduce bundle size: Large dependencies (like a markdown parser or date library) stay on the server and only the resulting HTML is sent to the user