Sasa!
2020 will be remembered by many as the year when their life radically changed. I am also part of the many, as I had to do a hard career drift: from being a well known music producer and teacher to a wannabe web developer. I went back to school, did my bootcamp, completed my internship and allowed me to earn my daily bread with code.
Even with being a nerd in the past (considering that my first babysitter was a C64 and I started to learn Python at the age of 10), it was still a hard career switch: from being considered a guru in my field to restarting at the bottom of the food chain. Luckily my mentor and my colleagues made this transition smoother.
In these 2 years I learnt a lot in the field, and discovered that a lot has changed in the world of web development. I was hired as a full stack developer, mainly on Laravel. The CTO of the company and by then my mentor, introduced me to the Laravel framework: Livewire.
Livewire is a Laravel framework, developed by Caleb Porzio, claims to do magic, allowing the developer to write and execute most of the frontend functions and features in the “code behind”, de facto reducing the need of Controllers.
It somehow resembles to old way of developing for the web: instead of exchanging JSON payloads that are gonna be interpreted by some Javascript, and then rendered client side, with Livewire there is an exchange of pieces of HTML, that are just going to be interpolated with what’s already on page. With this way of functioning, there is only one source of the truth, which is the server.
Sorry for the simplifications here, but I do not want to dive too deep into the technical nitty-gritty, as the magnificent Laracast series done by Caleb Porzio covers it all, and surely a gazillion other articles cover the topic better than I would. In this article I’m just going to give a scratch-the-surface overview about my 2 year experience with it, from a freshman point of view.
Livewire can blow you away
Used to a more classic MVC pattern, the first attempts of using Livewire were a bit… weird, as I felt I was missing something. Not having to create a Controller for every set of operations for a Model could be a bit destabilizing. The business logic is written within a component, which handles and honors all the requests coming from the client. The component exposes all data and functions that are declared public, removing the hassle of manually creating endpoints for each operation.
Livewire isn’t… Live
There isn’t a session running on the server keeping track of the component’s state, only HTML traveling at each request and response cycle; modified accordingly. This reduces the number of things a web developer should take care of, and returns the focus on the coding.
Too much magic is dangerous
In some cases, especially when you are dealing with a medium complex app, having large payloads traveling over the wire can generate bugs and unexpected behaviors. Sometimes, integrating external libraries to do things like nested multi selects or WYSIWYG editors can generate little code monsters, especially if nested within part of the code that is hidden during the fist render, like modals or slideovers. Luckily, the community is vibrant, and some ready made solutions have been developed since then.
Your file explorer won’t be happy
When I started, I was a fan of premature optimization: I liked my components to be 100% reusable and having the possibility of declining them in all the nuances I would have wanted. This just creates more complexity within every single component, making the maintenance and the extension of them hell.
My initial low coding skills had contributed to creating some little monsters, but in recent times I found myself refactoring a lot of things giving them more specialized purposes, even if the context was similar. Always remember: more components equals more code to take care of.
Go with the flow, but don’t bend it
If you want to try the HTML-over-the-wire approach Livewire can give you a taste of it, but you have to marry the whole concept. Trying to mutate the nature of one component differently might reveal itself as a mere exercise, making your code base less maintainable and hard to work with
Stay on the surface
Due to its nature, one of the big limits of Livewire, is that nesting components with more than 2 levels of depth is not advisable, as Livewire might not understand what you want to do and render its own thing.
DTOs are your friends
When exchanging data between 2 or more components, exchanging data in native and simple forms is highly advisable, as you can’t really have a lot of control over the parsing that Livewire does. A simple way of implementing such, is by instantiating Data Transfer Objects to and from the components. This way it will be possible to have more control over the data types, and also remove some of the business logic from the component itself.
Monoliths, monoliths everywhere
As per my newcomer’s point of view, Livewire goes against the flow with what’s trending in web development. Why?
By melting the frontend with the backend, abstracting most of the API endpoints, and by doing its DOM diff magic, this makes it difficult to develop microservices and favors instead a monolithic approach.
Good, bad? It depends on what you are trying to do: if you are a lone wolf or you work in an understaffed team, Livewire is the tool that serves the purpose, especially if the app you are working on is not that complex. But as complexity increases, the number of quirks and workarounds you have to do to make things work might not be worth the amount of code Livewire spares you from.
My take-away
Livewire, together with its other companions in the TALL stack made my transition as a web developer smooth and somehow magical, allowing me to rapidly grow my skills. Maybe I would have appreciated it more had I started using it after measuring myself with other frameworks like Vue or React, or maybe had I tasted a bit of the Javascript fatigue.
In conclusion, Livewire is a solid and mature framework to build and maintain specialized web apps in a quick and fun way.