DEV Community: catatsumuri

Laravel in 2026: Starter Kits, AI SDK, and the End of the Breeze Era

catatsumuri — Sun, 24 May 2026 22:57:40 +0000

Why Laravel? That is not the topic here.

This article assumes you already decided to build with Laravel, and instead focuses on a more practical question:

What does the Laravel ecosystem actually look like in 2026, and what should you choose today?

The original draft was based on material gathered through ChatGPT Deep Research, then heavily revised with additional analysis and commentary from actual ecosystem observation. The goal is not neutrality for its own sake, but a realistic reading of where Laravel is heading.

The State of Laravel in April 2026

Executive Summary

As of April 2026, the situation around Laravel starter kits has become fairly clear:

Breeze and Jetstream are not “dead,” but they are no longer the strategic center of the ecosystem.

Laravel officially shifted its public onboarding flow toward the new Starter Kits in 2025. Breeze and Jetstream still receive maintenance updates even in 2026, but their READMEs explicitly position them as belonging to the Laravel 11 era and earlier.

The practical conclusion is:

Breeze should no longer be considered the default choice for new production systems
Jetstream remains acceptable for existing systems, but is difficult to justify for new adoption
The modern default is now Starter Kit + Inertia, especially React
Livewire is still highly relevant and should not be dismissed as “legacy inertia”

That last point matters more than many people realize.

A surprisingly large portion of the discourse around Laravel UI strategy focuses only on GitHub stars of the public starter repositories. That produces a misleading picture.

Yes, React Starter Kit currently has stronger momentum as the public-facing “entry point.” But the broader Laravel UI ecosystem still shows enormous Livewire adoption.

The ecosystem split is becoming increasingly visible:

React + Inertia dominates external AI-oriented products and modern SaaS UX
Vue remains a pragmatic choice for teams with existing Vue investment
Livewire continues to excel in internal systems, admin panels, and PHP-centric organizations
Svelte is promising, but still lacks ecosystem gravity for default adoption

The larger story, however, is not merely frontend selection.

The real shift is that Laravel’s AI SDK is beginning to change Laravel’s architectural assumptions themselves.

This is not just “another package.”

Laravel is increasingly treating AI capabilities as part of the framework’s default application model:

AI SDK
MCP integration
Boost
Cloud APIs
Agent Skills
Maestro-managed starter kits

These are not isolated experiments anymore.

They are converging into a coherent platform direction.

Research Assumptions

This analysis prioritizes primary sources:

Laravel 13 release notes
Official AI SDK documentation
Starter Kit documentation
Laravel blog posts
Public statements by Taylor Otwell
Official GitHub repositories, issues, and pull requests

Community discussions in both English and Japanese were used mainly to identify practical pain points rather than as authoritative sources.

One important complication is that the new Starter Kits are distributed as cloneable repositories rather than Packagist packages.

That means install counts cannot be measured in the same way as Breeze or Jetstream.

As a result, public GitHub signals such as:

stars
forks
issue activity
ecosystem discussion volume

must be treated as imperfect adoption proxies.

This is actually a structural weakness of repository-template distribution models in general.

Comparing the Starter Kit Options

Let’s state the conclusion first.

Breeze is no longer the default recommendation for new production applications.

Jetstream is difficult to justify outside existing systems.

The primary battlefield is now Starter Kit + Inertia or Starter Kit + Livewire.

The strongest default choice today is React + Inertia.

However, dismissing Livewire as merely “legacy momentum” is a serious misunderstanding.

Breeze

Breeze still has real advantages:

minimal structure
easy-to-read authentication flow
relatively small codebase
useful for backend/API-oriented systems
easier onboarding for traditional Laravel developers

There is also a practical reality many people understate:

A large number of teams still adopt Breeze successfully even in Laravel 12 and 13.

Why?

Because the modern Starter Kits are heavy.

Not only technically heavy, but operationally heavy:

rapidly changing upstream conventions
evolving frontend architecture
weak documentation stability
limited Japanese-language ecosystem support
frontend discipline requirements many Laravel teams historically never needed

In practice, many teams still choose Breeze simply because they can fully understand it.

That matters.

Still, from Laravel’s strategic direction, Breeze is no longer where the framework’s future investment is concentrated.

Laravel increasingly treats the application starting point not as:

“authentication scaffolding”

but rather as:

“AI-ready frontend + auth + DX platform foundation”

That is a major philosophical shift.

Breeze still has value.

But increasingly, that value resembles:

learning material
minimal proof-of-concept foundation
compatibility layer
reference implementation

rather than “the modern standard.”

Jetstream

Jetstream faces a harder problem.

Historically, Jetstream differentiated itself through:

teams support
2FA
session management
more feature-complete authentication workflows

But much of that territory is now being absorbed by the Starter Kit ecosystem itself.

Laravel’s newer Starter Kits increasingly support:

built-in authentication
WorkOS integration
passkeys
social login
magic authentication
SSO flows
team variants

Meanwhile, Maestro now manages large variant matrices internally across:

Fortify
WorkOS
Teams
framework variants

As a result, Jetstream’s unique positioning has weakened significantly.

Existing Jetstream systems are still perfectly reasonable to maintain.

But for greenfield applications, the argument for starting with Jetstream has become increasingly thin.

React Starter Kit + Inertia

This is currently the strongest default recommendation for new external-facing Laravel applications.

The reasons are straightforward:

React ecosystem dominance
strong AI UI ecosystem compatibility
shadcn/ui momentum
Radix primitives
React 19 ecosystem maturity
TypeScript-first workflows
modern component architecture

More importantly, AI-oriented UX increasingly favors rich client-side interaction models.

That naturally aligns with React.

Laravel appears fully aware of this.

The modern Starter Kits are clearly optimized around:

TypeScript
component-driven UI
modern frontend tooling
AI-ready interaction patterns

rather than traditional server-rendered MVC assumptions.

The downside is equally obvious:

This stack requires real frontend engineering discipline.

Teams accustomed to purely backend-centric Laravel workflows often underestimate:

frontend state complexity
TypeScript maintenance
component architecture overhead
npm ecosystem churn
modern frontend build tooling expectations

Still, for customer-facing AI-heavy products, React + Inertia is currently the strongest default choice.

Vue Starter Kit + Inertia

Vue remains the pragmatic choice for organizations already invested in Vue.

The migration cost is lower.

The mental model is stable.

The Composition API ecosystem is mature.

However, React currently has stronger gravity in:

AI-oriented UI libraries
external ecosystem examples
modern component ecosystems
bleeding-edge frontend tooling momentum

Vue is therefore less “future dominant,” but still highly viable.

For many teams, stability may matter more than ecosystem fashion.

Svelte Starter Kit + Inertia

Svelte is interesting.

The developer experience is genuinely attractive.

Svelte 5 is modern and elegant.

Inertia integration is surprisingly clean.

But ecosystem gravity still matters.

Right now:

ecosystem scale remains limited
learning resources are thinner
Laravel-specific operational knowledge is scarce
hiring pools are smaller
official investment signals are weaker

Svelte is viable for teams already committed to it.

But it is still difficult to recommend as the default Laravel frontend strategy.

Livewire Is Not Dead

This point deserves emphasis.

Many discussions incorrectly frame Livewire as a fading legacy option.

The numbers simply do not support that narrative.

Livewire still maintains enormous ecosystem presence:

tens of millions of installs
massive production footprint
strong GitHub activity
official Laravel investment
Flux UI integration
Livewire 4 ecosystem momentum

The important distinction is this:

Public starter kit repository popularity does not equal total ecosystem dominance.

Livewire continues to perform extremely well for:

internal business systems
admin dashboards
operational tooling
PHP-centric organizations
teams minimizing frontend specialization

Where Livewire becomes less comfortable is extremely interaction-heavy AI UX with complex client-side state.

There, React usually provides more architectural flexibility.

But for large classes of real-world business applications, Livewire remains extremely competitive.

Calling it “only inertia” misunderstands the actual Laravel user base.

Laravel’s AI Direction

The most important shift in Laravel right now is not frontend technology.

It is the framework’s AI-native direction.

Laravel increasingly behaves as though AI is not an extension layer, but part of the framework’s core application model.

This matters because many frameworks currently integrate AI as:

external orchestration
generic SDK wrappers
thin API abstractions

Laravel is instead attempting to integrate AI directly into:

queues
events
auth
filesystem
application lifecycle
structured workflows
operational tooling

In other words:

Laravel is trying to remain Laravel while becoming AI-native.

That is strategically important.

And honestly, fairly ambitious.

1-Year Outlook

Over the next year, Laravel’s AI direction will likely continue aggressively.

The signals are already obvious:

AI SDK
MCP support
Boost
Cloud APIs
Agent Skills
Maestro
Starter Kit consolidation

The likely short-term evolution areas are:

conversation state stabilization
tool-loop orchestration
structured output improvements
vector-store integrations
multi-tenant AI architecture support
operational maturity around AI workflows

This is not based on secret roadmap knowledge.

It is simply the logical reading of where official framework investment is concentrated.

3-Year Outlook

Within roughly three years, Laravel’s UI strategy will probably polarize even further.

The ecosystem split may become:

React + Inertia

external-facing products
AI-first experiences
rich interactive UX
modern SaaS platforms

Livewire

internal systems
management interfaces
operational tooling
PHP-centric organizations
productivity-oriented systems

Vue likely survives as the “stable pragmatic middle.”

Svelte may remain niche unless official investment accelerates significantly.

Meanwhile, Breeze and Jetstream increasingly transition into compatibility assets rather than ecosystem centers.

5-Year Outlook

Five years is long enough that predictions become dangerous.

Still, some directional probabilities are visible.

The Laravel components most likely to remain strategically central are:

Eloquent
Queue
Events
Auth
Broadcasting
Filesystem
AI-integrated application primitives
Maestro-managed starter ecosystems

The components most likely to lose strategic importance are:

legacy authentication starter packages
older frontend assumptions
Blade-first public application architecture

This last point deserves nuance.

Blade itself is not dying.

Blade remains deeply embedded inside Laravel:

mail rendering
internal templating
Inertia foundations
server-side workflows
operational tooling

But Blade is increasingly no longer the assumed default public UI architecture.

That distinction matters.

Final Thoughts

Laravel in 2026 feels fundamentally different from Laravel in the Breeze era.

The framework is no longer optimizing primarily for:

simple MVC onboarding
lightweight auth scaffolding
traditional PHP-only workflows

Instead, Laravel is increasingly positioning itself as:

an AI-native application platform
with integrated operational tooling
modern frontend expectations
strong developer experience
full-stack orchestration assumptions

That creates both strengths and risks.

The strength is coherence.

Laravel increasingly feels like a unified application platform rather than a disconnected package collection.

The risk is that complexity rises.

The modern Laravel ecosystem now expects:

frontend literacy
TypeScript familiarity
operational maturity
AI workflow understanding
ecosystem adaptation speed

For some teams, that is exciting.

For others, it is exhausting.

But regardless of preference, the direction itself is becoming difficult to ignore.

And if you are building new Laravel applications in 2026, pretending the ecosystem has not changed is probably the real mistake.

Contributing to Laravel Maestro Starter Kits Without Losing Your Changes

catatsumuri — Thu, 21 May 2026 22:35:18 +0000

What is Maestro

Maestro is an upstream generator repository for generating and managing Laravel starter kits.

The following starter kit repositories are downstream repositories generated from Maestro, and directly modifying the starter kit side does not propagate changes upstream.

laravel/react-starter-kit
laravel/vue-starter-kit
laravel/svelte-starter-kit

Therefore, when making changes such as the following, you must modify the maestro side instead.

Shared starter kit bug fixes
Cross-variant fixes
Generator-level specification changes
UI consistency adjustments across stacks

Maestro Structure

Unlike a normal Laravel application, Maestro has the following structure.

kits/ — source template
build/ — generated application (generated runtime)
watcher — synchronization layer from build/ → kits/

Inertia Variant Matrix

variant	build command	starter_kit
React Fortify	`php artisan build --kit=react`	`react`
React WorkOS	`php artisan build --kit=react --workos`	`react-workos`
React Fortify + Teams	`php artisan build --kit=react --teams`	`react-teams`
React WorkOS + Teams	`php artisan build --kit=react --workos --teams`	`react-workos-teams`

The same applies to Vue / Svelte.

If you misunderstand “which side is the source of truth,” unintended rollbacks and unnecessary diffs are very likely to occur.

Basic Principles

`kits/` Is the Source of Truth

Any diff that should be committed must exist in kits/. build/ is generated output and should be treated as a working directory for verification, temporary edits, and runtime testing.

You must not commit diffs from the build/ side.

`build/` Is Disposable

Treat build/ as something that can always be regenerated. Since its contents change significantly whenever variants are switched, do not place long-term changes, source patches, or persistent fixes directly in build/. Permanent changes belong in kits/.

`composer kit:run` Is Convenient but Also Dangerous

composer kit:run is a convenience command that launches setup, the Laravel dev server, the Vite dev server, and the watcher together.

However, the watcher treats build/ as authoritative and writes changes back into kits/. As a result, if you start kit:run using an outdated build/, changes in kits/ may get rolled back.

After directly editing kits/, never run composer kit:run with an outdated build/. Always rebuild first.

Initial Setup

git clone https://github.com/laravel/maestro.git
cd maestro/orchestrator

composer install
npm install

Building a Starter Kit

At the beginning of work, expand the target variant into build/.

cd orchestrator

php artisan build --kit=react
php artisan build --kit=vue
php artisan build --kit=svelte

php artisan build --kit=react --workos
php artisan build --kit=react --teams

The current build target is stored at:

orchestrator/storage/app/private/starter_kit

Starting the Development Server

Do not start directly from build/. Instead, run the following from orchestrator/.

composer kit:run

This command performs the following together:

composer setup in build/
Starts the Laravel dev server
Starts the Vite dev server
Starts the watcher

Typical endpoints:

Laravel: http://localhost:8000
Vite: http://localhost:5173

Safe Workflow

Pattern 1: Edit on the `build` Side (for temporary verification)

build → kit:run → edit build → verify behavior

Convenient for exploratory UI adjustments. However, since build/ is disposable, it is safer to reorganize the final source patch into kits/.

Pattern 2: Edit on the `kits` Side (recommended path for PRs)

edit kits → php artisan build ... → composer kit:run → verify

This is the recommended approach when preparing PR patches.

Switching Variants

Do not incrementally update an existing build/. Rebuild every time.

php artisan build --kit=react
php artisan build --kit=vue
php artisan build --kit=svelte

After switching, rerun composer kit:run each time for verification.

Verification Notes

DB Initialization

composer setup only runs up to php artisan migrate --force. If seeded data is required, run the following inside build/.

php artisan migrate:fresh --seed

Removing Stale Files from the Watcher

When switching variants, the watcher may determine some source assets are stale and delete them.

Examples:

kits/Inertia/Fortify/React/chisel-paths.php
kits/Inertia/Fortify/Vue/chisel-paths.php
kits/Inertia/Fortify/Svelte/chisel-paths.php

Handle these separately from the main change set.

Example Routes for Verifying UI Copy Changes

For UI text changes in the Fortify variant, the following routes are usually sufficient to verify the primary flows.

/login
/user/confirm-password
/verify-email
/settings/security
/settings/appearance
/settings/profile

Since WorkOS has a higher verification cost, prioritizing Fortify variants is acceptable for minor changes.

How to Think About Staging

If the PR’s main purpose is a UI copy change, then only stage the text-related diffs.

The following should generally be separated:

chisel-paths.php deleted by the watcher
Temporary fixes in build/
Assertions for browser tests
Unrelated runtime bug fixes

# Instead of git add ., explicitly add target files
git add kits/path/to/changed-file.blade.php

Pre-PR Checklist

[ ] Are there any staged diffs from build/?
[ ] Are stale deletions from the watcher mixed in?
[ ] Are there unnecessary cross-variant diffs?
[ ] Are temporary browser test changes still present?
[ ] Did you check git diff --cached?
[ ] Is the source of truth correctly on the kits/ side?

Summary

If you handle Maestro like a normal Laravel app, diff rollbacks and unnecessary commits become very easy to trigger. To create PRs safely, maintain the following sequence.

Safe PR Flow

Apply changes in kits/
Rebuild with php artisan build ...
Verify with composer kit:run
Stage only intended diffs
Separate watcher/browser-test side effects

Laravel Starter Kit Localization Is Surprisingly Painful

catatsumuri — Sun, 17 May 2026 10:01:21 +0000

About Laravel Starter Kits Since Laravel 12

These are meant to rapidly deploy functionality that is almost essential during the initial launch of an application, including the following:

Layouts
- A typical sidebar layout
- Or a typical header layout
- Breadcrumbs
Authentication
- Basic session management
- Password reminders
- Self-registration
- TOTP-based 2FA
User settings
- Profile
- Light mode / dark mode switching
- Account deletion
Simple dashboard

Provided authentication screen

Part of the user settings

As you can see, this is extremely convenient for getting a project off the ground. However, especially in Japanese-speaking regions, adoption does not seem to be progressing very well. One reason is probably that the functionality is somewhat difficult to understand, but another major factor is likely the effort required for Japanese localization. Nowadays, with AI programming, identifying and rewriting English interfaces is not especially difficult, but not everyone has access to AI development agents, repeatedly translating everything with AI is exhausting, and if you are making an ambitious attempt to support multilingualization as OSS, then Laravel Starter Kits will inevitably run into localization issues.

Laravel Starter Kits Actually Come in About Four Flavors

Even when we say “Laravel Starter Kit,” there are currently about four flavors. First, I want to organize them.

Livewire-based
Inertia.js-based
- React
- Vue
- Svelte

At a broad level, things first split into Livewire and Inertia.js, and under Inertia.js there are three more flavors, each with branches beneath them... This huge number of variations is itself one of the characteristics of this project. Since the localization situation differs between Livewire and Inertia.js, you first need to understand that distinction.

To give the conclusion up front: if you intend to complete your project with Livewire, multilingualization is not especially difficult, and there is already some infrastructure in place. However, if you try to localize Inertia.js, there is no translation mechanism in the Starter Kit’s default state.

Projects for i18n in Laravel

Laravel’s Built-in Translation Mechanism

On the backend side, Laravel itself already has localization functionality, which is reinforced through additional resources provided by Laravel Lang.

Laravel 13 Localization Documentation:

https://laravel.com/docs/13.x/localization

About Laravel-Lang

There has actually been a project called Laravel-Lang for quite a while, and it already provides some multilingualization mechanisms.

https://laravel-lang.com/basic-usage.html

Following the documentation:

composer require laravel-lang/common

This resolves and installs the following dependencies:

laravel-lang/publisher
laravel-lang/lang
laravel-lang/attributes
laravel-lang/http-statuses
laravel-lang/starter-kits

At first glance, it seems like this package might somehow magically handle Starter Kit localization, but reality is not so simple. We’ll look at that later. Simply installing the package only expands files under vendor/, so at this stage, nothing is actually usable yet.

Deploying Into the Actual Project With the lang:add Command

You execute it like this. Here, we’ll only deploy ja.

php artisan lang:add ja

The actual implementation of this command comes from the previously resolved dependency laravel-lang/publisher, which performs the following tasks:

Determine the target locale
Select only enabled plugins from the plugin list
Read the key list from source/...
Read values from locales/{locale}/...
Write them into lang/{locale}.json or lang/{locale}/*.php

In any case, once this command is executed, things should expand like this:

   INFO  Collecting translations...

  LaravelLang\Actions\Plugin ............................................................................. 2.37ms DONE
  LaravelLang\Attributes\Plugin .......................................................................... 0.83ms DONE
  LaravelLang\HttpStatuses\Plugin ........................................................................ 1.28ms DONE
  LaravelLang\Lang\Plugin ................................................................................ 5.90ms DONE
  LaravelLang\StarterKits\Plugin ......................................................................... 1.37ms DONE

   INFO  Storing changes...

  ja.json ................................................................................................ 5.04ms DONE
  ja/actions.php ......................................................................................... 4.65ms DONE
  ja/auth.php ............................................................................................ 0.45ms DONE
  ja/http-statuses.php ................................................................................... 2.02ms DONE
  ja/pagination.php ...................................................................................... 0.55ms DONE
  ja/passwords.php ....................................................................................... 0.52ms DONE
  ja/validation.php

Locale Configuration

As described in the official documentation, this is determined by the APP_LOCALE environment variable, and falls back to APP_FALLBACK_LOCALE if unavailable. Therefore, for Japanese localization, the configuration would typically look like this:

#APP_LOCALE=en
APP_LOCALE=ja
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

This localizes the backend.

For example, after installing the package and configuring the locale, even 404 pages are immediately translated into Japanese. But this is backend functionality.

Frontend Support

This is where the problem begins.

As mentioned earlier, the situation differs between Livewire and Inertia.js. To say it first: the only thing functioning relatively properly at the moment is Livewire. So let’s start with the Livewire side.

Roughly How Laravel-Lang Builds Translation Files

There are actually two major types of translation files: .json and .php types. Since the frontend mainly uses .json files, I’ll focus on those here.

At this point, the dependency resolution from laravel-lang/common should have expanded the following four files:

vendor/laravel-lang/starter-kits/locales/ja/json.json
vendor/laravel-lang/lang/locales/ja/json.json
vendor/laravel-lang/http-statuses/locales/ja/json.json
vendor/laravel-lang/actions/locales/ja/json.json

These are merged together to ultimately form the file lang/ja.json. However, not everything is blindly copied over; there is actually a filtering stage called source defined beforehand. For example, let’s look at the Livewire one.

https://github.com/Laravel-Lang/starter-kits/blob/main/source/livewire/main/livewire.json

Only the keys listed here are picked up and internally expanded, so this mechanism seems intended to filter out unnecessary keys.

Meanwhile, the current React situation looks like this:

https://github.com/Laravel-Lang/starter-kits/blob/main/source/react/main/react.json

…Yeah.

So let’s look at how the Livewire Starter Kit is actually translated by examining the login screen.

Translating the Livewire Starter Kit Login Screen

https://github.com/laravel/livewire-starter-kit/blob/main/resources/views/pages/auth/login.blade.php

In this case, translation hooks are already embedded throughout the UI from the beginning. For example:

<!-- Remember Me -->
<flux:checkbox name="remember" :label="__('Remember me')" :checked="old('remember')" />

<div class="flex items-center justify-end">
  <flux:button variant="primary" type="submit" class="w-full" data-test="login-button">
    {{ __('Log in') }}
  </flux:button>
</div>

As shown, it passes things through PHP’s translation system using __(). Since Livewire is tightly integrated with the backend (essentially operating in a pure Blade-like manner), this approach is possible.

The Quality of Livewire’s Japanese Resources

So does installing the language pack solve everything? Unfortunately, no. At present, the translation quality is extremely poor, or rather, most of it is untranslated.

https://github.com/Laravel-Lang/starter-kits/blob/main/locales/ja/json.json

Since translation files are generated based on this, there’s honestly no way around fixing it. I’ve been sending PRs and discussing things, so maybe it’ll improve somewhat, but who knows...

https://github.com/Laravel-Lang/starter-kits/pull/1902

https://livewire-starter-kit-ja.catatsumuri.org/login

You can view the current proposal using test@example.com / password

As for Inertia.js UIs Like React

Let’s look at the login screen again. Since we compared the Remember me section earlier, here’s just the corresponding part.

https://github.com/laravel/react-starter-kit/blob/main/resources/js/pages/auth/login.tsx#L76-L94

The strings are written directly into the source code, meaning that whether it’s Japanese or any other language, nothing gets translated as-is (naturally).

Conclusion

That is the current state of localization (i18n) in Laravel Starter Kits. Outside of Livewire, things are honestly pretty rough. For English-speaking users, this tends not to become a major issue, but outside that environment... the problems become extremely apparent. I suspect everyone is just aggressively rewriting UIs using AI or similar tools, but I really wish things were handled a little better. For now, I’ve at least tried contributing Japanese resources through PRs, but in the end, what’s actually going to happen here?