Inertia.js vs Livewire Laravel

This article was written in 2019.. and with time going on the saying that "single-page apps are not SEO friendly" will become less and less true.

https://www.smashingmagazine.com/2019/05/vue-js-seo-reactive-websites-search-engines-bots/

Looks like Google is seeing where things are going and is getting accustomed to JS-in-the-browser-rendered content

@techmasters also, Inertia do have SSR support

@adityar15 I'm currently facing the same dilemma. Initially chose to use Livewire for my UI, which worked fine at first when things were relatively simple. But as complexity has increased, and the number of reactive, interactive elements in my UI has grown, it's become a frustrating and time-consuming task to maintain and expand UI with Livewire.

Some of the problems I've experience are:

• Livewire errors tend to be very difficult to debug. The stack traces and console errors are vague and cryptic, at times forcing me to manually narrow down the problem area by cutting chunks of code until the error goes away, then repeat until I find the specific line.
• Livewire elements combined with SSR logic fail in very undesirable and sometimes unexpected ways. Resulting in things like missing HTML closing tags, and duplicated UI elements. This is compounded by the unhelpful errors, and results in a lot of frustration trying to isolate even minor problems.
• The seam between Livewire and AlpineJS for client-side logic is quite error prone, and full of unwritten rules due to the nature of the implementation. For example, computed Livewire properties can't be entangled, arrays can't be serialized by Alpine x-for directive but collections can, sometimes dispatching browser events from Livewire a Livewire class to AlpineJS listener just doesn't work for inexplicable reasons, user inputs can't use x-model on an entangled Livewire property (doing so without defer causes race condition, but sometimes I can't have input syncing be deferred, like an interactive search field). All of these issues have workarounds, but the problem is they aren't documented and have to be learned largely through trial and error.
• Unpredictable conflicts between Livewire & AlpineJS elements. For example, sometimes Livewire interprets the Alpine-compatible :class="alpineVar ? 'class1' : 'class2'" as Livewire logic. Which is fine, I can use x-bind:class instead, but it's inconsistent about when this conflict happens.
• Difficulty implementing 3rd-party JS packages for enhanced client-side functionality (Pikaday, Tippy, ApexCharts, Monaco Editor). Especially when those packages require knowledge of data stored across both Livewire variables and AlpineJS logic that responds to user input.
• Forced to use an ungodly combination of Blade, Livewire, and AlpineJS syntax to accomplish advanced UI patterns, and the combination is inconsistent across different scenarios. I Find myself having to implement boutique solutions to problems to work around the limitations of Livewire & Alpine.
• Unexpected issues can crop up when Livewire components and AlpineJS logic are nested
• Sometimes entangled Livewire & AlpineJS variables don't sync properly. Probably due to issues diffing some data types.

Overall, as complexity and interactivity increases, Livewire becomes quite a slog to build with. This results in more time debugging arcane problems and trialing workarounds to constraints and annoyances than actually implementing new code. It starts to show cracks any time I go beyond simple implementations. These days I feel like the framework is working against me, rather than for me.

I'd say it's fine for simple UI, but if you need a lot of JS packages, advanced UI patterns, or interactivity, Livewire may not be the best option.

@SleeplessDev Yeah, that's the problem with Livewire. The errors can just become very annoying and they are totally unpredictable for complex UI. With Vue 3 and Inertia, it is just smooth and pretty straightforward to work with.

@kreierson Sure, luckily I used ATOMIC design principles for my Livewire app. So it was easy to convert all the Livewire ATOMS to Vue ATOMS (input, label, img, etc). The good thing about Livewire is its implementation is somewhat similar to Vue's so it was easy to convert Livewire components into Vue components. A lot of rewriting of code though but there was no way out.

I created a backup repo just in case I have something if things mess up and then I started editing the current project rather than creating it from scratch.

Inertia makes it easy to take that shift thanks to its architecture. I don't have to write Sanctum APIs or take care of the Vue router and other state sharing. Inertia takes care of those tasks with ease. Additionally, it supports SSR out of the box so it made it straightforward to have SSR in my app.

SSR with Inertia or any Node environment is different. For Livewire all the requests are server-rendered while for the Node environment, the initial request is server-rendered (SSR) and then the browser takes on the rest of the control for routing.

Hope this helps :)

@kreierson i have been in your position in about year+ ago. I had 2 projects, pretty big (one is https://workzone.io, well known task management tool) built on Livewire. For us, it was getting harder to maintain it and adding new features, as well as updating old ones, and team faced some dilemmas that we did not know how to solve. Problems with performance, slowness, lack of support in discord channels, and most of all i presume, lacking knowledge and understanding. Been sponsoring github of livewire for many months, learning from course they have for sponsors, but all was pretty basics, and when we get to complicated things, we had to bail out. So we let all that with the water, and rebuilt it from scratch with Inertia/Vue. We have learned a lot, and i am about to rewrite one more project. Happy with that way, personally and my whole team likes inertia.js The beauties of inertia is that i know what is happening all the way, while with livewire, there were some magic things happening in background with alpine.js that were out of my control, its really magical and sometimes workd and sometimes not. Problem was that we could not easily debug it as it was under the hood. Coding style of people coding livewire examples is not really my style, and i did not like it. To directly answer to your question. I have had running app and i wrote down all the features i need to make, i have created everything from scratch, except the database tables, that i have used exsiting, but i did laravel new project-rewrite and started making new vue components. Now i starting new one, and on laravel 10

@vladimir Thanks for taking the time to tell your story. I did the exact same and started a new project, basically visiting each page on the old project and implementing them one by one. Everything is going great and I enjoy coding this way with Vue/Inertia over Livewire. I ran into the same issues, adding features was beginning to get more difficult, odd bugs cropping up here and there that were tough to troubleshoot. Quick question for you, when deploying your new app what was your process? We host our app on digital ocean, use Forge for deployments. I have copied all my migrations over to the new project so my thought process is this:

Rename old project folder on digital ocean. In forge: Update php version of server, as I am also updating laravel and need php v8.1 Change Git repository to point to the new project/deployment branch Press Deploy Now

Wonder if this will error out because the folder no longer exists on digital ocean?

Thinking I may need to first click "Uninstall Repository" on Forge to reset the site back to it's original state?

Curious to hear your thoughts and learn from your experience.

Thanks for your time!

@kreierson sorry for late response, must be turned notifications off. I never was so confident to go to try renaming folders etc. I did it one of two ways:

1. i change repo on forge, and set a new repo one i am ready to go. I do not even login into DO, and i do not rename/delete any site from forge.
2. I destroy droplet and make new from scratch, with a new repo

Not sure if this works for you, this is just how i do it.