Dev Diary #1: getting started with Livewire

I’ve been a web developer for years. Decades even. Back when frames were the “in” thing, transparent PNGs in IE6 needed Javascript to show transparency, and rounded corners on elements required images. And the industry is continually evolving: and now there are so many choices, options, ideas and ways to do, well similar things.

Livewire has been a tech that I have dipped a toe in… but never really embraced with open arms. Starting this year, I’ve blocked a weekly meeting with someone very important (that’d be me) to ensure there is blocked out time in my work calendar to do work, but not client work. It’s for me to learn something new, try a new feature, write more posts, or work on some of the Statamic addons I have plans for (but never seem to have time to do).

Up first, is exploring Livewire.

When I started working with Laravel, I went all-in, elbows deep: my first Laravel app was a Vue SPA (Single Page Application), using Vuex and Vue Router - so consuming a straight and standard Laravel backend. It works - and still works nicely to this day - but also is an incredibly manual and complicated setup. The Vue space has evolved since this app was created - so I have to juggle what’s new and happening in Laravel, and Vue, and Vuex, and Vue Router. Lots to digest there.

I think found Inertia JS, created by Jonathan Reinink. Inertia JS is a great way to simplify the SPA experience, with the developer’s choice of frontend: of course I stuck with Vue.

Over the years I have built many apps with Inertia and Vue - including one currently in-dev at the moment. But it also has the complexity of maintaining the Vue side, and ensuring data, when it is transferred from the backend to the frontend (and vice versa) remains in the same expected shape.

What I really like about Inertia is that I get to keep with the Laravel concepts: controllers, routes, form requests, responses. It is a really organised way to structure an app - but also has more code required to build. And when I look at the summary of the project repos, I actually see that I have more Vue code than Laravel code.

But my history really has been in the PHP space. I’m starting to find that working with Vue is becoming a chore, and things that should be simple still take time.

Don’t get me wrong: from my pre-Laravel days, everything took much much much longer… but also what can I do as a developer to work smarter and more efficiently to be able to produce the same high-end apps for my clients?

So, we’re up to date now: I love Inertia… but need to explore Livewire, and am considering if Livewire is a suitable candidate for some of my projects.

The majority of app-type projects I create are basic CRUD-type apps, the frontend needs to be functional, dynamic and extensible. I’ve seen many - on X, Bluesky, Reddit, in person - comment on how fast they can get things up and running. Heck, at Laracon AU 2024, Keith built a cocktail app in 30 minutes live on-stage.

There’s got to be something to this Livewire thing, right?

One of the biggest potential strengths here - besides potential for time-saving - is that my stack can be simplified. With Statamic-based sites, I’m SALT - Statamic, Alpine, Laravel and Tailwind. With Livewire, I can be TALL - Tailwind, Alpine, Livewire, Laravel. See the similarities there?

Livewire can also play nicely with Statamic. On this site (as of January 2025 at least) the blog page filtering is a Livewire component on a Statamic site, and still uses full static caching. Neat, hey?

My first experience with Livewire was v2 - and I did what the docs say, but in reflection, is so stupid. I want to open a model: OK, click a button, tell PHP, set a variable, respond back. Uh… the server shouldn’t (in most cases) give two rats whether or not a modal is displayed. But the docs did include examples to illustrate what Livewire can do, even though it wasn’t really the right way to do in a real-world app. Even looking back I can see how silly it is to ask the server to open a modal… but hey, it is what it is. I really did not get a great impression of Livewire based on this app implementation. But was 100% the developer’s fault. That’s me by the way.

Approaching Livewire 3 with a more mature mindset (and clearer definition between state and data - thanks Josh Hanley), it was time to get my hands dirty. It has been great to talk to people like Josh and Sam, both of who I met at Laracon AU 2023, and Sam and I have so many similarities with the way we work, expectations of code (including quality and readability) and pressures of a solo dev.

Reading the Livewire 3 docs made sense. I understood the concepts, I understood the patterns and lifecycle. But wasn’t really sure how to get started.

Josh and I have had a few pairing sessions to get things up and running - him helping me with Livewire, and me helping him with Statamic in return. Given Josh understands where I am as a dev, it has been great to go beyond the “hello, world” type tutorial and setup, and straight in to seeing how Josh structures his apps.

This initial setup has me playing with:

• starting from scratch (don’t try to run before I can walk)

• full page components

• a Livewire layout.blade.php file

• playing with wire:navigate (including on a redirect)

• forms

• fields

• Livewire form objects

• validation

• computed properties (for Eloquent data)

• persisting elements across navigation

It was a very productive few hours getting up and running and seeing what Livewire can do without the clutter of starter kits or frameworks or packages. Let’s just do things from the ground up and get my head around the basics.

I’m following Josh’s advice too for building a full Livewire app, starting with full page components, which require a route definition, but then the remainder of the logic (such as saving data) is handled within the component.

This is where my head breaks a little: I’ve spent years being told “you make a controller, it uses a form request, it has a response” to now looking at Livewire where it is more self contained, has no controller, no form request and no response. Well, not in the same Laravel way at least.

So for me, it is like a mental mindshift just needs to take place.

I want to keep building my little playground further: explore more of what Livewire has to offer, and see how I can evolve it in to a more real-world type scenario including roles and authentication - and the bigger impact of that with the feel and performance of the app.

I’m also really curious to look at Flux UI - still being actively developed, but also first party. And that fills me with confidence.

The other thing is testing. Sam showed me some testing of Livewire and it looks so simple and intuitive. So I’m looking forward to writing some tests to see how that can help (and give better confidence of testing both frontend and backend).

I do have a project on the radar at the moment and need to make a decision soon as to the stack: do I stick with Inertia and Vue (and find ways to streamline or help out that development cycle), or do I consider streamlining through building with Livewire?

One thing I do love about Inertia and Vue is that the Vue frontend - when running without issue, of course - feels robust. It feel solid. I’m yet to have that feeling with Livewire, and I think it is mainly because I keep looking at things being glass half empty. Waiting for something to go wrong. Some sign that it isn’t the right choice to make.

But it is, right? Or definitely could be.

I love the SPA-feel with Vue - back and forward works reliably, and page loads feel super snappy. I’m curious to see how Livewire feels on one of my servers. Does it still feel snappy, or are there things that can bog it down?

Just like any tech stack - Inertia included - the dev can do a lot to bog down performance. This is a good opportunity to learn things the right way - and having folks like Sam and Josh around who are incredibly skilled at what they do is comforting.

I love the modern feel of the Inertia app - but I love the appeal of simplifying development to be more productive - in turn helping my clients do more.

And that is incredibly valuable.

As I mentioned on Bluesky, it is like I’m waiting for the penny to drop but the concept hasn’t quite landed yet.

Part of me wonders if I’m waiting for permission (almost) to be told “yep, do it” or “nope, don’t do it” - and why. And of course, I’d love to hear your input on the discussion too.