Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

MtDalPizzol's avatar

Laravel + Vuetify vs Livewire + Tailwind

Hi, folks.

In my last project, I coupled Laravel with Vue.js and Vuetify. This had its upsides and downsides. For my next project, I’m trying to figure out which route to take:

  1. Should I stick with my Laravel + Vue.js + Vuetify stack

  2. Should I try Livewire with Tailwind

So, I’d like to share my thoughts on what I liked and disliked on the last project and find out what others opinions are.

Using Vuetify was really good for theses reasons:

  1. I (almost) didn’t need to write CSS. I can safely say that I spent less than 1% of the time of the development writing CSS. This is really important since I think this is the main time consumer on my workflow.

  2. I didn’t need to worry about responsiveness. Vuetify components took really good care of that.

  3. The end result of the UI was incredibly good and no users reported any sort of problems in the 2 weeks the project is online.

  4. The assets generated by Vue CLI are PERFECT. All the codespliting, treeshaking, minification and that complicated Webpack stuff that we usually almost loose our minds with were handled gracefully by the CLI.

The downsides were these:

  1. Duplicated validations: validations which are ready out of the box on Laravel needed to be duplicated with vee-validate on the client side.

  2. Another problem is related with URLs. I love Laravel’s named routes and these are the only way I reference and generate URLs on my app. Not having access to these functionality on the client side sucks and I don’t like using something like ziggy, which adds code to be delivered to the user for something that is ready on the server.

  3. Handling permissions on the client side sucks. I love Laravel’s policies approach and I think it’s a real loss having to map permissions to a JavaScript object so Vue.js can decide what to and what no to render, for example.

  4. Not SEO friendly. Well.. You all know about that...

For the upsides, I MAY BE WRONG, but I have a feeling that all of those goodies will go away adopting Livewire + Tailwind.

My main “fear” on adopting Livewire + Tailwind is ending up having to tweak lots of classes and losing a lot of time to get something not as good as what is ready with Vuetify. I would also have to worry about responsiveness and It seems to me that Livewire handles “codesplitting” on a more traditional way. Adding script and style tags and latency (more round trips) to the page when it’s needed.

On the other hand, I think that every time we can keep things on the Laravel side of things, it’s a big win. Testing Livewire, for example, looks a lot better than testing Vue components. Since my main “fear” is losing time with CSS, one could suggest the new Tailwind UI. And I’m considering it. But it seems to me that it only solves the CSS problem. You’ll still have to write the JavaScript interactions with the components, which are ready in Vuetify.

So. I’m really, really undecided and I’d like to hear from you what your thoughts are.

Thanks in advance.

0 likes
5 replies
MarianoMoreyra's avatar

Hi @mtdalpizzol

Have you considered Inertia.js? It seems to tackle some of the downsides mentioned without having to change entirely to a new stack. (I must warn you that I haven't had the opportunity to fully try it myself)

From it's documentation:

1.Duplicated validations: validations which are ready out of the box on Laravel needed to be duplicated with vee-validate on the client side.

You can keep your server side validations without duplicating at client side: https://inertiajs.com/forms#server-side-validation

2.Another problem is related with URLs. I love Laravel’s named routes and these are the only way I reference and generate URLs on my app. Not having access to these functionality on the client side sucks and I don’t like using something like ziggy, which adds code to be delivered to the user for something that is ready on the server.

Here you'll still miss having named routes at client side, although they offer some alternatives (including ziggy which you already said you don't like it): https://inertiajs.com/routing

3.Handling permissions on the client side sucks. I love Laravel’s policies approach and I think it’s a real loss having to map permissions to a JavaScript object so Vue.js can decide what to and what no to render, for example

I don't know if it's the best way it's handled. I guess it's almost the same as mapping permissions to a Javascript object as you said, although they make it seem clean at least: https://inertiajs.com/security

Also, you can check this post from Freek Van der Herten (from Spatie) showing how they've implemented front-end authorization using Inertia: https://freek.dev/1391-how-to-handle-front-end-authorization-using-laravel-inertia-and-typescript

Anyway...maybe it still haves some of the downsides, although once again...it offers some interesting solutions while you can keep using Vue and Vuetify just like you've been doing.

For more info, you can check this blog that makes a comparison between Inertia and Livewire: https://sebastiandedeyne.com/inertia-js-and-livewire-a-high-level-comparison/

Hope all this helps!

MtDalPizzol's avatar

@marianomoreyra , Thanks for the response

In fact, I have tried Inertia. The problem with that, for me is this: it reinvents the wheel at sometimes, and you end up having A LOT of problems related to Webpack configuration. This had more to do with laravel-mix than Inertia itself.

I remember spending 2 days tweaking Webpack configs to get codesplitting and treeshaking working properly with Inertia and, at the end, I still had problems with CSS extraction and stuff like that, and this was all related to Mix, which was behind some Webpack plugins and loaders fixes. Also, Inertia docs recommended DOWNGRADING Mix even more.

This was the reason why I end up with a custom workflow. Instead of fighting Webpack to get things working with Inertia, I simply created a Vue CLI app on a "frontend" folder at the root of my Laravel project and EVERYTHING related to the frontend and Webpack was magically working out of the box

And finally, Inertia dosn't tackles the SEO problem. You'll have to use some "foreign" service to generate SEO friendly verisons of the pages.

jcs224's avatar

As far as the Webpack issues with Inertia, I switched from Laravel Mix to Parcel and the config problems basically went away. I have a blog post draft on how to do this, I'll have to finish it soon. Works with Vuetify and Inertia.

Sinnbeck's avatar

Inertia is made for apps that require login, so no SEO isn't a priority (quote from Reinink himself).

Please or to participate in this conversation.