Pascal Baljet

Never waste precious time reinventing tables again. Impress your clients with a modern, fast, and responsive table component. Inertia Table is the ultimate table package for Laravel and Inertia.js. It is compatible with React and Vue and is stuffed with features like extensive filters, row links, bulk actions, dark mode, exports, a built-in query builder, and it is super customizable!

Thoughts on Splade: I took a week off to look around and reflect.

In the summer of 2022, I took a month off from work as our daughter was born. Before leaving, I worked mainly on Inertia projects, but I also had a huge Laravel project built with Blade and some Vue components. I had already released some Laravel packages, but wanted to do something different after I came back. So I opted for an open-source Inertia app (not a package), but then Splade came around, and I shelved the Inertia app.

It started with some very basic components, but I managed to build some more complicated ones and even adopted Inertia's SPA philosophy. Honestly, I was a bit frightened to release it, but I'm glad I did! I released it as v0.1 as it was quite experimental, and I still needed to build real apps with it. After four or five months, I tagged v1.0 and worked on it for months. Some people liked it and started building apps with it, which is honorable. I positioned it somewhere between Inertia and Livewire, though it was always hard to compare it to those. Mind, this was before Livewire 3.

Maintaining a large package like Splade is also demanding. Feature requests, bug reports and questions come in all the time. Most can be fixed and addressed, but occasionally some request would pop up where I would think: This is would be easy in Inertia/Vue. The goal of Splade was to use Blade as much as possible, and use Vue where necessary. It shouldn't make things harder.

The problem with Splade v1.

Two major things are bothering me with Splade's current architecture: customization and expandability. Of course, there are other concerns, but these two things keep me up at night.

Let's start with customization. People primarily want to customize the components that come with Splade, not the JavaScript part under the hood that manages SPA navigation, lazy loading, etc. There are many renderless components where Splade doesn't provide any template or markup, but it is about the components that do provide a template. Splade Components consist of a Blade Component and a Vue Component (with only a script, not a template). Essentially, we render the Blade part and pass it as a template to Vue. You see where this is going. To customize the template, you have to publish the Blade view from the vendor directory and then forever keep up with the upstream changes. Maybe even more demanding: The Blade view uses data and methods from the corresponding Vue Component. One should understand and maintain that link as well. And if you want to customize the behavior of the Vue Component, it gets even more complicated.

Splade doesn't offer an architecture to expand it with your own components. Funny enough, it doesn't need to because anybody could do the Blade-in-Vue trick; you don't need Splade for that. But it would be convenient if Splade offered a way to help, for me as well! There's no mechanism to keep the Blade and Vue parts in sync. I have to look in the Vue script to see what a method is called and what it does to use it in the Blade view. It's not a great experience, and it's prone to errors.

How can this be solved?

At first sight, the customization problem seems more straightforward to solve than the other. We could introduce more slots to the templates and replace the Tailwind classes with generic classes (and provide a Tailwind implementation). There are many more clever ways of improving this, but you get the point. For expandability, we could introduce a bunch of helpers to improve the binding and syncing of the Blade and Vue parts. All this might take away some pain points, but the bottom line is that it's still a lot of work to maintain a customized Splade Component. This two-part component architecture will always differ from regular single-file Vue Components or Blade Components sprinkled with Alpine.js. This whole 'sprinkled with Vue' idea is wonderful until it's not.

Let's solve it.

My next big experiment was to bring the Vue script block to Blade and keep it all in a single file. Hugely inspired by Laravel Volt, I started working on Splade Core. This would be the missing helper that fundamentally brings Blade and Vue together, not as an implementation of components but as a tool to build components. With Splade Core, you start with a <script setup> block in your template and then write your regular HTML template below it. I got it working pretty fast and even got some cool features working, like two-way binding of props between PHP and Vue and even calling PHP methods from Vue. At this point, it began to feel more like Livewire than Inertia, but I had no problem with that. So, I started implementing some real-world components from Splade v1, like the Form Components and SPA navigation.

Splade Core is a dead end.

Splade Core works beautifully in most cases. It's exactly what I was looking for, and I was motivated to rebuild all Splade v1 features upon Splade Core. But as I got to the more complex components and situations, I saw the downside. It got really, really complex, and not everything is even working correctly. Particularly, the concept of slots is hard to tackle as Blade and Vue handle them differently.

I'm parsing JavaScript in PHP, messing around with the Blade compiler, automatically generating Vue components, building a Vite plugin to keep everything in sync, providing a tricky skeleton for others to develop and release components, and this list goes on and on. Each feature is well tested, but this beast is unmaintainable and super hard to debug. I can't go on like this. I'm wasting valuable hours, and people probably wouldn't get on the 'Splade Core'-train, even I don't know what's going on some of the time.

Splade Core doesn't have a future. I marked it experimental from the beginning, and that's where I'll leave it. I don't know how to complete and stabilize it without spending more days/weeks/months on it. Another thing I have to admit: I'm not enjoying building it anymore. It's become a burden instead of moving Splade forward. As you can imagine, leaving Splade Core behind was a tough decision. I already invested so much time in it, but investing even more is not worth it.

What's next?

Where does this leave Splade? I've thought of a few options. As Splade Core is dropped, so is Splade v2. I could rethink v3 with a new architecture, another variant of Splade Core, but I fear I fall into the same trap. There's no guarantee it will work out this time. So, there will be no v2 or v3 in the near future.

Another option is to pick up Splade v1. This won't solve any fundamental problems; I can't deny they exist. Splade v1 is not dead, but it's clearly not the way forward. There are 120+ open issues in the repository, and though fixing them would be great, the basics will stay the same. Addressing them would be great (not all are bugs), but it still doesn't feel like working on Splade's future. I may have taken this whole idea of Blade-in-Vue way too far. It feels strange to keep working on an architecture with this many concerns.

Last week, I took the opportunity to reflect on Splade and its future. I hope you see where I struggle. Besides determining a direction for v1 and a possible reimagined future Splade, this week was also an opportunity to reinvestigate Inertia and Livewire. I'm constantly working with Inertia, but I only briefly worked with Livewire 3. Especially with Inertia, I see a chance to improve the development experience.

What about that open-source Inertia app?

Remember that open-source app I started this post with? What if I took some of Splade's philosophies back to Inertia? I'm not talking about forking Inertia or rebuilding it. What about a set of independent, optional packages you can pull into your Inertia project to bring you some of Splade's ideas? Tuned explicitly for Laravel and Vue. The open-source app could be used as a way to demonstrate these.

Livewire 3 momentum.

Maybe it's needless to say, but Livewire has massive momentum. Its release was highly anticipated, and I also feel Filament contributes to that. I've built two Filament + Livewire 3 projects over the last months to get a feel for what it's like. I totally understand the appeal. One was a relatively simple site that needed some interactivity and a backend to manage the content. I absolutely enjoyed the experience. The amount of plugins for Filament is impressive! Also, the things that Livewire 3 now does are mind-blowing. Some of Splade's features were really hard to build; I can't imagine what it must be like to build them at the scale of Livewire.

On Laracon EU, I talked with Povilas about this momentum and how Inertia sometimes seems forgotten. I asked on Twitter where all the Inertia people are, and the response was what I expected. Inertia is such a thin layer between Laravel and Vue that it's not about debugging and learning Inertia. You learn to work with Livewire, but learning Inertia is mostly about Laravel and Vue. This reignited the spark in me why I loved Inertia in the first place: I love both Laravel and Vue. I love Blade as well, but as Taylor said himself, Livewire is what Blade should have been. It's missing the interactivity by default.

Both Inertia and Livewire grow in adoption.

Let's bust the myth that Inertia is dead. I must admit I had this gut feeling about Inertia for some time as well, even wondering whether it had a future, but now I know better. It's not dead. Yes, some repositories have tons of issues and PRs, and some features never got merged, but it's growing at a similar rate as Livewire. Maybe it's increasing even faster, as new releases of Livewire are much more common than new Inertia releases. It's not about who grows faster or is more popular, it's about stating that Inertia is alive. In this case, the release frequency should not play a role in choosing one of the other.

Conclusion: I probably need another week of research.

I'm surprised you made it this far, but here's a short list of what I've found out and decided this week:

  • Splade Core will be abandoned. It has no future.
  • This means Splade v2 or v3 will not happen soon as I need some variant of Splade Core.
  • Splade v1 has some fundamental flaws. I can't ignore them, and it feels odd continuing with v1, knowing I won't address those flaws.
  • Not sure if I should say this, but Livewire is not for me. The improvement from v2 to v3 is extraordinary, but it just doesn't click with me.
  • I've ignored my passion for Inertia for too long while building Splade. Not from a competitive point-of-view (because who cares?), but I got distracted by all the Splade excitement.
  • I see an opportunity to bring some Splade ideas to Inertia. No fork or rebuild, just separate packages.
  • I'd love to revisit my idea of an open-source Inertia app. Not only could I do the app, but it also provides an opportunity for more content (blog posts, live streams, videos, etc.)

The elephant in the room might be: what's the future of Splade? The truth is, I'm not sure yet, but I narrowed it down. I'll waste no more time on Splade Core or complete rewrites of Splade. This massively frees my mind to think about Splade v1. I can't give any guarantees. I can not promise I'll address and maintain all issues for years to come; the user base is not large enough, and I make practically no money from it. As I said, I need more time to figure out the future of Splade v1.