I really like the server side routing part of Inertia and that you can pass data to the frontend directly in the first request without needing to do an additional http request (altough this might be a bit problematic for sensitive information in case the sites are cached).
However, there are also things that make it feel gimmicky:
- There are issues like this where they could at least merge the PR to improve the documentation as there seem to be many people to misunderstand the usage the function but it did not happen https://github.com/inertiajs/inertia/issues/1631
It’s funny, this is how we built apps in 2014-era Rails at Airbnb, and by 2015 we were doing server-side rendering of some React components too. We had a thing to pop a React component into our regular rails views as a “partial”.
<%= render_react_component('MyComponent.js', :name => 'Hypernova The Renderer') %>
Wishing this (Hypernova) was still maintained at all! We've been eyeing it, and it would be an absolute perfect fit for our Rails / React-heavy shop that is close to requiring SSR. As is, it seems like the only viable, supported solution in this space is Shakacode's.
It’s really not a lot of code to do this. I’m sure you could study the codebase a bit and then write your own in-repo and have a great time. If I were writing a Rails app tomorrow I’d make my own, although the Shakacode docs looked fine too.
At the Laracon it was estimated the new version 2 of inertia will be released in October with new features like multiple async requests, polling, infinite page scroll with smart background loader, etc
Here's a server-side community adapter our team has been using for ASP.NET Core. It works pretty well! I helped contribute the Vite helper to bring HMR and ease of integration.
How difficult is it to troubleshoot Inertia when something breaks?
That was my only fear when I toyed with Inertia, Django, and Svelte for an afternoon. When I’d get an error it seemed obscure or not indicative of the underlying cause.
What’s everyone’s experience? Inertia seems like magic. And that’s what scares me a little.
My team of 5-6 devs has been using Inertia for a year now. I really don't think that Inertia is magic. Some of us have 10 years experience, some 2 years. I don't think anyone on the team has had to troubleshoot Inertia. Nothing with Inertia has ever broken. Juniors have never gotten confused by how it works.
It is just a simple bit of glue between your Vue app and your backend. The docs are good, and it overall just feels solid/stable. Super excited to see the new changes that are coming too!
I became aware of Intertia from a Ruby shop some time in 2022, who had good things to say, along the lines of "We could not ship as fast as we do without it." At work we are exploring Inertia to migrate parts of a long-lived Rails application quickly-but-gradually into an SPA. Have not gone live with the first feature yet, but so far a proof-of-concept and our exploration have been positive.
By "quickly-but-gradually", I mean that some pages will remain server rendered, and gradually more migrate to being browser-rendered, but each new page or slice of functionality is very quick to port over. If you have any sort of viewmodel, presenter, or form object abstraction in your server-rendering architecture, it is much faster to just turn that into JSON and use Interia than it is to convert everything into pure JS/TS and generalize a set of APIs to serve the frontend. Of course YMMV depending on your existing architecture and needs.
Is there any functionality that is not offered by SvelteKit? SvelteKit is batteries including SSR/web server solution for Svelte and works beautifully together, as they are tightly coupled.
I switched from Svelte/SvelteKit to Svelte/Laravel and my productivity went through the roof. Same would apply with Rails or probably other batteries included backends. SvelteKit gives you SSR but that’s it. Laravel/Rails/etc gives you database, queues, real time support, authentication, authorization, the list goes on.
I plan to make my next YouTube video making my case for why Laravel is better with Svelte than SvelteKit is https://youtube.com/@samldev
There isn't one. There's been a couple attempts but they just don't hit the mark like Rails or Laravel do.
Honestly, the upside of 1 language is not that high. Don't be afraid of PHP, it isn't the same language it was 15 years ago. I've been programming JS for 10 years but only been using PHP for a year, it's weird but it's got some nice parts too.
The lack of a clear leader Rails clone in NodeJS land is probably the ecosystem’s biggest weakness. The downstream effect is theres a bunch of typical libraries/clients are just… MIA in the node ecosystem. Like, there’s no production grade Memcached client for node. ¯\_(ツ)_/¯ We had to fork one & heavily patch it for Notion.
One (not only) of the problem is that you cannot do it in JavaScript very well due to poor underlying support for types. You neded TypeScript to have the equicalent of ActiveRecord or Django model.
This doesn’t follow because both Django and Rails evolved in languages without a type checking compiler. Rails is super dynamic in ways that would make Typescript type checker kind of sad.
SvelteKit is not a “full” (depending on the definition what full means) stack solution either, and is commonly used with backends like Django or Rails. For example, it does not have its own ORM.
You’re still not getting what inertia is and keep asking dumb questions that make no sense. Please, check inertia docs. It has nothing to do with sveltekit/next/nuxt.
It looks to me like you didn't even check what Inertia is?
It basically gives you access to the entirety of features provided by Rails, Laravel, etc without having to write an API, create a separate codebase or deployment. You don't get any of that with SvelteKit. This is apples vs oranges.
I really like Inertia. For my project, I have chosen yo use Laravel with the Jetstream starter kit, converted to React. It works quite well for my current use cases.
Having to load every single string from your entire application is something I don't like at all. I wish at some point we have a solution where we can just create a bundle per language so we can get code splitting, etc and just ship what's necessary for your locale.
For the Inertia project I work on at my job, we just use a "frontend" translation solution and keep the Rails translations system just for the backend.
We do actually have per-language code splitting with React/Vite. We essentially just have a map of [language, loader], where the loader utilizes lazy imports. Vite is smart enough to split those all out of the main bundle and they get loaded on demand as expected.
Then we consume it in a component which accepts the language key, lazy-loads the bundle by just calling `LOCALE_MAP[key]()`, and then uses it as the string translation set for a context function which looks up keys in a dict. Super simple.
Yes, it's all the strings per language, for the SPA. We also have services which we can use to request a bundle of strings from the backend, which I guess could in theory be an avenue for JIT translation on the frontend, but so far the per-language bundle splitting has kept things managable for us.
However, there are also things that make it feel gimmicky:
- The resolve function createInertiaApp runs more than once (mainly) on the first page load causing a re-render and it seems like there is no plan to fix that in near feature https://github.com/inertiajs/inertia/issues/1595 / https://github.com/inertiajs/inertia/issues/1091
- There are issues like this where they could at least merge the PR to improve the documentation as there seem to be many people to misunderstand the usage the function but it did not happen https://github.com/inertiajs/inertia/issues/1631
reply