Inertia.js allows developers to write single-page applications (SPAs) using classic server-side routing and controllers. Inertia tightly couples the backend to the frontend so that developers need not write APIs. Developers can use battle-tested server-side frameworks (e.g., Laravel, Ruby on Rails, Django, AspNetCore). On the client, developers can use React, Svelte, or Vue to implement the user interface.
Inertia.js takes a singular position in the SPA solution space between fully client-side SPAs and MPAs (multi-page application). Inertia refers to its approach in the following terms:
Inertia is a new approach to building classic server-driven web apps. We call it the modern monolith.
Inertia allows you to create fully client-side rendered, single-page apps, without much of the complexity that comes with modern SPAs. It does this by leveraging existing server-side frameworks.
Inertia has no client-side routing, nor does it require an API. Simply build controllers and page views like you’ve always done!
Inertia provides three official client-side adapters (React, Vue.js, and Svelte) and two server-side adapters (Laravel and Rails). Community adapters are however available for a range of server frameworks, including AspNetCore, CakePHP, ColdBox, Django, Go, Masonite, Mithril.js, Node.js, Phoenix, Symfony, and Yii2.
Inertia allows developers to build web applications as if following an MPA architecture. Developers leverage a server-side web framework for routing, authentication, authorization, data fetching, and more. The view is however the responsibility of the client, like in SPAs. The documentation explains:
The only thing that’s different [from an MPA] is your view layer. Instead of using server-side rendering (eg. Blade or ERB templates), the views are JavaScript page components. This allows you to build your entire front-end using React, Vue, or Svelte.
The first time a client requests a page, Inertia returns a full HTML response. On subsequent requests, server-side Inertia returns a JSON response with the JavaScript component (represented with its name and props) that implements the view. Client-side Inertia then replaces the currently displayed page with the new page returned by the new component and updates the history state.
Client-side, the request handling is implemented by using a custom <inertia-link> component that wraps around a normal anchor link. Links are thus intercepted so that the default behavior of the browser (full page refresh) is replaced by sending an XMLHttpRequest (XHR) request to the server.
Inertia requests use specific HTTP headers to discriminate between full page refresh and partial refresh. If the X-Inertia is unset or false, the header indicates that the request being made by an Inertia client is a standard full-page visit.
Server-side, a request with a X-Inertia request header set to true will trigger a JSON response that includes the name of the component that displays the requested page, the props for that component, the requested URL, and a version number.
The documentation provides the following example of a response object corresponding to a request:
REQUEST
GET: http://example.com/events/80
Accept: text/html, application/xhtml+xml
X-Requested-With: XMLHttpRequest
X-Inertia: true
X-Inertia-Version: 6b16b94d7c51cbe5b1fa42aac98241d5
RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json
Vary: Accept
X-Inertia: true
{
"component": "Event",
"props": {
"event": {
"id": 80,
"title": "Birthday party",
"start_date": "2019-06-02",
"description": "Come out and celebrate Jonathan's 36th birthday party!"
}
},
"url": "/events/80",
"version": "c32b8e4965f418ad16eaebba1d4e960f"
}
The version parameter addresses asset versioning and helps ensure that the server returns a full HTML response when the requested asset has changed.
The documentation addresses commonly occurring cases (scroll management, forms, error handling, cross-site request forgery protection, progress indicators, local state caching, code splitting, and more). Authentication and authorization are handled server-side by the chosen server framework. A demo app (Laravel + Vue) is available online.
Inertia targets developers who want to reuse their skills or an existing codebase. The documentation mentions:
Inertia was designed for development teams who typically build server-side rendered applications using frameworks like Laravel, Ruby on Rails or Django.
As part of an animated discussion on Hackernews of an article proposing alternatives to SPAs (titled If not SPAs, what?), one developer with extensive experience with Ruby on Rails shared a positive opinion of Inertia:
I have been using Ruby on Rails with Vue.js + Inertia.js and honestly my productivity has skyrocketed. I don’t worry about writing APIs for the frontend, no need to maintain separate router on frontend and no state management required.
Using this stack I’m able to build a highly reactive app with minimal efforts.
Another alerted however about the absence of support of server-side rendering:
Working on a project with Interia.js which I will be taking to production shortly. The one thing you have to watch out for is that there’s no support for SSR like you would get with Nuxt. You’ll need to set up an additional service for that like prerender.cloud or prerender.io. If you’re thinking about bigger projects then you’ll need to think about this. Not all search engines or SEO tools will run JavaScript.
Danny Moerkerke, in his article titled Your Single-Page App Is Now A Polyfill, proposed an alternative technique to write faster SPAs that uses HTML streaming and service workers to proxy and cache full page visits. Every new page is a full-page reload but only the content that changed from the server is fetched. As with Inertia, no client-side routing is necessary.
Inertia is open-source software distributed under the MIT license. Feedback and contributions are welcome and should follow Inertia’s contribution guidelines.