Why Your Build Times Exploded After That Framework Update
I spent last Thursday debugging why a React app that used to compile in under 30 seconds was now taking four minutes. The culprit wasn't anything dramatic — it was Vite misconfigured with an unnecessary pre-bundle step for a library nobody actually imports directly. This happens constantly when people chase "modern web development" without understanding what the stack is actually doing at runtime. Here's what I've learned after rebuilding the same project five different ways over the last eighteen months: modern web development isn't about using the newest framework. It's about understanding bundlers, asset pipelines, and browser capabilities well enough to make decisions when things break. The people who know this don't have fancy workflows. They have fewer things to configure. I moved our team from Webpack 4 to Vite two years ago and saw build times drop from roughly three minutes to twelve seconds on cold starts. The real win came when I stopped treating the config file as something to copy-paste and actually read what each option was doing. A single misconfigured resolve.alias entry caused a duplicate module warning that nobody noticed for three weeks.
The Stack Most People Get Wrong
Let's talk about TypeScript. Every tutorial says "just enable strict mode and you're fine." That's not true. I found a production bug last month where a nullable type on a prop caused a runtime crash in the browser because the bundler tree-shook the null check away during minification. The TypeScript compiler was happy. The browser was not. The fix was adding an explicit type assertion in the component body, not changing the interface definition. This is the kind of edge case documentation doesn't cover. React Server Components sound like a solution. They are, if you're building content-heavy sites. They're absolutely not if you're shipping a dashboard with thirty interactive components that need client-side state. I tried converting our admin panel to RSC last quarter. We spent two weeks fighting hydration mismatches only to realize the whole app needed interactivity on first paint anyway. We rolled it back. Not every modern technique fits every project.
A Practical Walkthrough That Doesn't Waste Your Time
Start with a framework that gives you sensible defaults. I use Vite with React and TypeScript. Here's the actual config I ship, not the tutorial version: Create the project by running npx create-vite@latest and selecting the React TypeScript template. Don't skip the template. I've wasted hours trying to manually wire up Vite with React after starting from blank, and it never works as cleanly as the scaffolder does. In your vite.config.ts, add these three settings:
Get the Full Details
Build optimization with manifest mode enabled so you get proper cache-busting hashes on your output files. Set the outDir to dist with a custom assets folder. Most people leave this alone and then wonder why their CDN cache is a mess. For CSS, I prefer postcss with the preset-env plugin instead of relying on the framework's built-in styles. The framework approach works until you need to override a vendor prefix or add a custom plugin, then you're rewriting things the hard way. Your tsconfig.json should have strict mode on and noEmit set to false if you're debugging type issues in your IDE. There's a common misconception that strict mode alone catches everything. It catches most things. It won't catch the runtime-null issue I described above. That's why you need actual test coverage, not just type coverage.
What Breaks When You Deploy This
I'll be blunt about the failures I've seen: Dynamic imports with string concatenation break statically. If your code does import("./pages/" + routeName), Vite can't tree-shake it and will bundle every possible page into your main chunk. I hit this when building a multilingual app where route names came from a config file. The workaround was switching to explicit import statements mapped through a dictionary object. It's more code but the bundle size dropped by forty percent. CORS errors appear after deployment even when they never happened locally. This isn't a code problem. It's an environment problem. Your local dev server runs on the same origin as your API. Production doesn't. Configure your backend to return the proper Access-Control-Allow-Origin header with the exact production domain, not a wildcard. Wildcards work in development and create security issues in production.
Image optimization doesn't happen automatically unless you tell the bundler to do it. Vite doesn't resize images. I set up the vite-plugin-imagemin package for our image-heavy project and cut our initial load by six seconds on mobile connections. That's not a minor improvement. That's the difference between a user staying and a user leaving.
When to Walk Away From "Modern"
Some projects don't need SSR, streaming, or edge functions. A simple marketing site with static content benefits more from a good CDN and aggressive caching than from any server-side rendering setup. I've seen teams spend two weeks implementing Next.js SSG for a ten-page brochure site that got three thousand monthly visitors. The hosting bill for the static build would have been zero dollars. Instead they paid for serverless function invocations and cache invalidation overhead that solved problems none of their users had. If your application has less than fifty unique routes and the content changes weekly at most, static generation or even plain HTML served from a CDN is faster to build, cheaper to run, and easier to debug than any React framework you could choose. I recommend the static approach for anything that isn't an actual application with user state or real-time data. The modern approach to web development means choosing the simplest tool that handles your requirements, not the one with the most features. Everything else is just engineering debt waiting to show up on a Tuesday afternoon.
