Skip to main content
All posts
4 min read

Why I Keep Reaching for Laravel + Vue.js

LaravelVue.jsInertia

Ask five developers what stack to start a full-stack web app with and you'll get five answers. For most of my projects, mine is Laravel on the backend and Vue.js on the frontend — glued together with Inertia.js.

The Inertia sweet spot

Inertia lets me write a server-driven app with client-side rendering: controllers return JSON props alongside rendered pages, and Vue components consume them without a separate API layer or client-side router to maintain. For CRUD-heavy systems like my Lost & Found capstone, that removes an entire class of boilerplate:

// A controller "page" — props flow straight into the Vue component
return Inertia::render('Items/Index', [
    'items' => Item::query()->filter(request('q'))->paginate(15),
    'filters' => request()->only('q', 'category', 'status'),
]);

What Laravel gives me

  • Eloquent and migrations make data modeling fast and explicit — crucial when the schema is the product (like item states and roles).
  • First-party auth, validation, and middleware keep security concerns declarative and boring.
  • The ecosystem (Queues, Notifications, Mail) covers the "adult" features without stitching libraries together.

Where I still reach for React + Next.js

  • SEO-critical marketing sites: server-rendered React with the Next.js metadata API beats a client-rendered SPA.
  • Interactive dashboards and tools where a rich client state model matters more than server round-trips.
  • This portfolio, for example — Next.js is the right tool for a content-forward, performance-sensitive site.

The lesson is not "Laravel is better" — it is that a pragmatic default lets you start fast, and knowing when to break the default is what separates a framework fan from an engineer. Both stacks live in my day-to-day work.