Slog
↑↓Navigate↵Go to PageescClose
Soumitra Saha

What I Learned Building Full-Stack Applications in 2025

Six honest lessons from 2025 — TypeScript as the new floor, the Vite tooling win, AI's productivity ceiling, and where meta-framework complexity actually lives.

What I Learned Building Full-Stack Applications in 2025

I expected 2025 to be the year AI tools fundamentally changed how I build software. They did — just not in the direction I was hoping. Usage numbers went up across the industry; frustration and distrust went up alongside them. The mental model I carried into the year — AI as a reliable productivity multiplier — needed a serious revision by mid-year.

That’s one of six things I actually took away from 2025. The others are about build tooling, TypeScript, the complexity hiding inside meta-frameworks, how the testing landscape shifted without much announcement, and how the definition of “full-stack” is stretching into territory that wasn’t part of the job description five years ago.

This isn’t a list of trendy things I tried. It’s a synthesis of what I noticed while building, backed where it helps by the major survey data from the year. What changed, what clarified, and what I’d tell a developer starting a project today.

On this page

TypeScript is the floor, not a preference anymore

The question changed in 2025. It’s no longer “should I add TypeScript to this project” — that debate is settled. The State of JavaScript 2024 survey put the TypeScript CLI at roughly 50% usage across the ecosystem, and in every serious project I’ve seen started in the past year, TypeScript was the default, not the upgrade path.

What that shift means in practice is that the baseline skill level for joining a TypeScript project rose. Knowing how to write a function signature or extend an interface isn’t enough anymore. You need to understand type narrowing, utility types, and how to keep generics readable when the problem actually calls for them — which is less often than new TypeScript developers tend to think.

The way I now think about TypeScript: it’s the grammar layer of a codebase. Get the grammar loose early — too many anys, strict: false, skipping explicit return types on shared utilities — and the type errors don’t appear until the codebase is large enough that fixing them is genuinely expensive. Starting strict is always cheaper than retrofitting it later.

// tsconfig.json — the strict baseline I use for every new project
{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true
  }
}

The two extra options beyond strict are worth the occasional friction. noUncheckedIndexedAccess makes array reads type T | undefined, which catches a whole class of “property of undefined” bugs before they hit runtime.

If you’re still working through what TypeScript actually changes about how you write JavaScript, the post on TypeScript for JavaScript developers covers the contract mindset and the practical starting points.

The Vite generation won the build tooling debate

According to the State of JavaScript 2024 survey, Vite grew +30% year-over-year in usage and was voted the most-loved tool in the JavaScript ecosystem with 56% positive opinions. Vitest — its testing companion — had a 98% retention rate, the highest of any tool surveyed. That’s not incremental improvement; that’s a generation of tooling winning decisively.

Webpack is still the most-used build tool in the survey at 85% usage, but its sentiment is in freefall — it now has the most negative trend of any major JavaScript tool. This is a familiar pattern: most developers are using tools they no longer love, because migration isn’t free and existing projects can’t flip a switch.

For new work, I moved to Vite this year without hesitation. The feedback loop is genuinely different. Cold starts that used to take 8 to 15 seconds now take under a second. Hot module replacement is near-instant. Vitest test runs complete in the time it takes to glance at the terminal. When the feedback loop shortens, you run more experiments. When you run more experiments, you find the right solution faster.

The practical conclusion: for any project starting today, Vite is the obvious choice. For existing webpack projects, the question is whether the migration pain is worth the feedback improvement — and for most teams the answer is yes, but it’s a real migration, not a config swap.

AI tools hit a productivity ceiling I didn’t anticipate

The Stack Overflow Developer Survey 2025 found that 84% of developers now use AI tools in their workflow — up from 76% the previous year. That looks like a success story. The follow-up data complicates it: positive sentiment toward AI tools fell from over 70% in 2023 and 2024 down to 60% in 2025. Usage rose and enthusiasm came down at the same time.

The specific frustrations are worth sitting with. 66% of developers cited “AI solutions that are almost right, but not quite” as their biggest problem. 46% actively distrust the accuracy of AI output, while only 33% trust it. Only 3% report “highly trusting” AI-generated code — and that 3% skews toward developers with less experience, not more. The most experienced developers are the most cautious.

This matches what I observed. AI tools are genuinely useful for specific things: generating the first draft of a unit test, explaining unfamiliar library code, writing boilerplate that follows an established pattern. Where they fail is in the judgement layer — knowing when a pattern doesn’t apply, when a dependency has a security issue, when the simpler approach is better than the clever one.

The recalibration that made AI more useful for me: I stopped treating AI output as a draft to skim and started treating it as a contribution from a capable but overconfident junior developer. You read every line. You verify the logic against the documentation. You don’t ship anything you haven’t understood yourself. That standard made the tools more valuable, not less — but it also meant the time savings were smaller than the initial demos suggested.

AI agents specifically remain niche. In the same survey, 52% of developers either don’t use agents at all or stick exclusively to copilot and autocomplete. Autonomous task execution is still being figured out, and I think that’s the correct level of caution.

React is solid; the meta-framework layer is where the complexity lives

React’s usage held at 81% in the State of JavaScript 2024 survey — still the most-used frontend library, a position it’s held for years. Sentiment has declined over time, but adoption hasn’t. React itself is not the problem.

The complexity moved up a layer. The positive-sentiment trend for major meta-frameworks narrowed significantly through 2024. The server/client rendering boundary — deciding what runs where, managing hydration correctly, understanding when a server component can and can’t call a certain API — added cognitive load that wasn’t there in a straightforward single-page app.

I don’t think this is purely the meta-framework’s fault. Server-side rendering and edge deployment solve real problems: faster initial page loads, better SEO, reduced JavaScript sent to the client. These are worth having. But the complexity budget is real, and it’s easy to add architectural overhead that your actual users never benefit from.

The question I now ask before adding a meta-framework: “Does the rendering architecture I’m choosing solve a problem I actually have, or am I carrying complexity speculatively?” For a public-facing content site with real SEO requirements, server rendering earns its keep. For an internal dashboard seen by 30 people, it usually doesn’t.

Understanding how Node.js executes server-side code helps reason through these decisions. The React fundamentals — components, props, state — remain the most important thing to have solid before the meta-framework layer makes sense.

Testing shifted: Playwright became the obvious E2E default

Playwright’s trajectory in the State of JavaScript 2024 survey is one of the clearest trend lines in the data: near-zero usage in 2020, strong retention and rapid adoption growth by 2024. Cypress’s positive-sentiment line moved in the opposite direction over the same period, declining sharply year over year.

I made the switch during 2025 and found the experience cleaner across the board — parallel execution without configuration work, better tracing tools, simpler cross-browser coverage, and a more consistent API. The decision wasn’t that Playwright is perfect; it’s that the community energy and active maintenance are clearly there, and Cypress became harder to maintain as the two projects diverged.

On the unit testing side, Vitest continued absorbing Jest’s space. The 98% retention figure is real — the Vite-ecosystem’s speed advantage applies to test runs too, and the Jest-compatible API means migration is mostly mechanical. Jest is still widely used, but the direction of travel is clear.

The more important testing lesson from 2025: testing architecture is a first-class project decision that needs to happen at the start, not get retrofitted later. The cost of adding tests to a codebase that wasn’t designed with testability in mind is disproportionate to the cost of starting with it. I paid that retrofit cost twice in 2025 and won’t do it again.

Full-stack is getting wider, not just taller

The data point from Stack Overflow Developer Survey 2025 that stood out to me most: Python grew by 7 percentage points from 2024 to 2025, reaching 57.9% usage. JavaScript is still first at 66%, but the gap is narrowing, and the reason is directly tied to AI and data science work becoming expected in more full-stack projects.

This is quietly changing what “full-stack” means. A few years ago, full-stack development meant handling both a client and a server within the same language ecosystem — typically JavaScript or TypeScript end-to-end. More projects in 2025 expected the full-stack developer to reason about the AI integration layer too: calling language model APIs, shaping prompts, handling streaming responses, managing rate limits and token costs.

That’s not the same as becoming a machine learning engineer. But it is a new layer of the stack that wasn’t standard before. If your backend needs to call an LLM endpoint, parse the structured output, and write the result to a database, that’s backend work now, not a specialist’s domain.

The architectural thinking that goes with this is worth developing deliberately. As projects gain more interconnected pieces, the decision about where to scale, what to cache, and how to partition your data starts mattering earlier in a project’s life. I spent more time thinking through system-level tradeoffs in 2025 than any previous year, and the post on scaling basics from one user to one million covers the mental model I kept returning to.

What this arc actually teaches

Looking at 2025 as a whole, it wasn’t a year of dramatic invention. It was a year of consolidation and honest reckoning. Old debates got resolved — TypeScript, Vite, Playwright. New complexity moved in from unexpected directions — AI integration, the architecture overhead in meta-frameworks, the widening scope of what full-stack actually means.

The most valuable skill I developed wasn’t picking the right tool. It was building clearer judgment about why a tool exists, which problem it solves well, and whether that problem is actually the one in front of me. AI tools taught me this more sharply than anything else in 2025: the gap between “it works in the demo” and “it works reliably under real conditions” is consistently wider than the marketing suggests.

The technologies available to a full-stack developer today are genuinely good. The build tools are fast, the type system is mature, the testing frameworks are capable. The limiting factor is mostly architectural judgment — knowing when to add complexity and when to push back on it, knowing which part of the stack deserves careful attention and which part can be solved with a sensible default.

That’s not a new lesson. But 2025 made it concrete for me in a way the previous years hadn’t managed.

Sources