Is full stack even real anymore?

“Full stack” has become a misleading catch-all because modern frameworks differ at a fundamental level: some mainly connect front end to back end with minimal built-in assumptions, while others bundle a much wider set of application concerns—database access, middleware patterns, API generation, authentication, payments, and more—into a single “batteries included” framework. That gap matters because it changes how much decision-making developers must do, how predictable the request/response flow feels, and how painful it becomes when the framework’s “happy path” doesn’t match real-world needs.

The discussion starts by challenging the idea that “full stack” is a single, stable category. React-adjacent comparisons don’t apply: Next.js, Laravel, Rails, Phoenix, Flask, and Django aren’t just different flavors of the same job. They sit on multiple axes—how much they prioritize front end versus back end, and how many built-in pieces they provide. The speaker argues that “full stack” should at least mean back end plus front end working together, but “fuller stack” is a more accurate label for frameworks that also include database layers, middleware conventions, API generation, and other app-level machinery.

Python’s Flask and Django are used as an early example of the split. Flask’s “getting started” is minimal—import Flask, define routes, return HTML—while Django’s setup scaffolds a larger project with database and server components baked in. That difference becomes a proxy for two philosophies: one framework emphasizes building a relationship between code and browser behavior with fewer primitives, while the other pushes a more prescriptive structure that supplies more of the system upfront.

Next.js is positioned as the minimal end of the spectrum: it prioritizes front-end primitives and keeps the core toolkit small, forcing developers to assemble authentication, payments, and other capabilities from external libraries. The upside is flexibility and innovation—new patterns and tools (including TRPC-style approaches and GraphQL) can emerge because the framework doesn’t lock teams into one set of solutions. The downside is that beginners can struggle to choose the right pieces, and the “wiring” between them becomes the developer’s responsibility.

Laravel sits closer to the “batteries included” side. It aims for a smooth default experience and invests heavily in front-end synchronization through tools like Livewire and inertia-based approaches, while also providing first-party or well-integrated options for common back-end needs. Rails is treated as more painful when the happy path breaks, while Django is described as heavily batteries-included compared with Flask.

The framework comparison expands into a second dimension: the “size of the circle” a tool covers. Minimal stacks cover less (often just front end + back end), while fuller stacks cover more concerns—authentication, queuing, payments, database management—reducing decisions but increasing the cost of mismatch. The trade-off is control versus convenience: swapping components is easier in minimal setups, but fuller stacks can make it harder to replace parts when requirements evolve.

Finally, the transcript argues that “full stack” fails because it tries to describe both axes at once—front/back integration and minimal/batteries-included coverage—plus it ignores other layers like design systems and component libraries. The speaker proposes retiring “full stack” as a term and invites better alternatives, suggesting that the community needs clearer language to separate “BFF-style” back end + front end integration from truly bundled application frameworks.