Laravel Livewire is a terrible idea

Sounds like a hot take, but actually, it's a good example of choosing the right tool for the job.

Background

At work, we meet up biannually to discuss our progress as a company and decide on what the next 6 months will look like. The work I do is for a occupational health platform. So it is mostly just changing forms and database schemas. Unfortunately, the code base is written in a PHP 4 style. Instead of having a nice Model View Controller (MVC) structure, with separate functions for different http verbs, it's a file based system, where all the verbs, logic and templates are mixed together in the same file. Sadly, this codebase has incredible amounts of technical debt. So there is a strong push by the senior developers to clean this up and move on to something much more modern.

The Discussion

It is common for these meetings to divulge in software architecture talk. Some of the more senior engineers strongly believe that we should implement a MVC style application, but have differing opinions on how to achieve this. I have a strong Laravel PHP background, so i am keen to move towards Laravel, as it has a rich ecosystem of packages that we could re-use. Many others agree with me but some would like to use the Slim router instead. The Laravel camp is split though, as there are a few solutions for the front end.

There's

• Blade: PHP Template Engine (basically deprecated)

• SPA: Vue JS / React integration via Innertia or with an API

• Livewire

Quick Recap

Blade was the original way to do templates in Laravel, where you create templates and it looks at lot like PHP. It has some excellent integrations into the Laravel framework and it is super easy to learn. However, it feels like it is being phased out by the Laravel team.

Alternatively, writing a Single Page Application or SPA, comes in a few flavours. It is also the option that seems to be encouraged the most by the create laravel app. Historically, VueJS has been the king in this arena, as it has deep integrations into Laravel, which are similar to Blade. However, since the inertia library was introduced, react - arguably the world's most popular front end framework - is becoming the de facto for a lot of new projects written with Laravel. The more serious architects in the room, try to avoid inertia though, in favour of creating a traditional SPA, with a separated API back end. The main take away here, is that you make your front-end in TypeScript/JS which runs in the browser, but you code your back-end in PHP/Laravel which runs on the web server.

This is where Livewire comes in. Using the same architecture that sites like GitHub originally employed. Where a user clicks on an action, it sends a request to the server, which then responds with a snippet of html, to replace only a part of the web page. Livewire, provides a small JS/PHP library that does the same thing, except it maps the requests to PHP classes and methods on the server. So every time you do an action, like click a button, select some text, select a dropdown or radio button, and so on; Livewire sends a request to the server, asking PHP Laravel what to do, and how to respond to the event.

My Reasoning

At this point you might be asking, is that it? what is wrong with that? why the hot take?

Let me start by giving the Livewire team their dues. For such a small JS/PHP library, it is a very interesting way to code the front-end. When it first came onto the scene, it was marketed towards back-end devs who either didn't know front-end technologies/workflows, or didn't want to work with such frameworks. The core idea is that just code in PHP instead of JS.

Therein lies the problem. In my view, you are not a real web developer, if you do not understand how JavaScript and the Web as a platform works. This includes how your web browser works, the protocols it uses, and how back-end servers process requests.

You also are not giving your users the best possible experience. See, one of the key reasons for writting a SPA becoming popular in the web 2.0 days (yes i am that old), was that you could create super interactive experiences, that just ran in the web browser. Thanks to XML HTTP requests, you could contact the server to just get data you need, without the extra processing to generate the html on the server. This meant that you could do cool things, like animations, and helpful hints while the user filled in a form. At the time, that sort of thing was new, but it has gradually became to be the expected norm. Back then, internet connections were much slower than today. So were the servers that ran the web applications. In other words, it took longer to generate a webpage and send it down to the web browser. That is what a SPA is suppose to solve.

These days, users are expecting web applications to have rich interactions that do not take anytime.

With Livewire, every interaction the user makes, results in a web request to the server. This request must be handled by the server, which causes the browser to block, and the user to frustratingly experience freezes and latency between interactions. You can configure livewire to largely ignore such events, but you then loose the ability to provide rich interactions.

My Conclusion

And therein lies the problem. SPA equals high interactivity, Livewire provides low interaction experiences. Thus, waiting for a web request for every single little action is stupid.

Devils Advocate

Sadly most healthcare software UX is 15 years behind the curve. Since the platform I work on is mostly simple forms. it does raise the question: do we need a high level of interaction?

I will leave that with you to decide...