Should Livewire Support VueJS?

#1

Livewire has supported (or tried to at least), VueJS since the beginning because of its popularity in the Laravel ecosystem.

I have made no secret that I think Livewire shouldn’t be used for all front-end interactions, but I haven’t been as clear on what the recommended JS approach/framework is.

I started building Project X to answer this question, and I still believe it will be a viable solution.

Here are the 3 options as I currently see them:

(These are taken from this GitHub issue)

A) Remove third-party library support from Livewire’s core and set a precedent of building plugins to add support (Vue, Turbolinks, Bootstrap’s JS part, Project X)

  • Cleaner core (and more “extendable” architecture)
  • Doesn’t favor or align with any specific front-end tech
  • Provides a path for devs to create their own integrations and understand Livewire more fully
  • Saves me time by allowing others to maintain integrations

B) Focus on supporting Vue out-of-the-box, as it’s the most popular in the Laravel ecosystem. (this was the original approach)

  • Makes the easiest onboarding ramp
  • Doesn’t require the dev to deal with installing and managing another dependancy

C) Provide a JavaScript framework solution (Project X)

  • Could have deep integration with Livewire
  • Would fit each other’s use-cases perfectly
  • A bunch of other obvious wins

A gets my vote. I think we need to just decide on it and move forward. Starting with moving the Vue integration into a separate repository. But I want to hear everyone’s thoughts.

Thanks! (Also, thanks @mokhosh for getting the conversation started)

5 Likes
#2

Was thinking about this just yesterday. Here’s my opinion, but keep in mind I haven’t used 0.5 of Livewire OR project-x (yet).

I think a combination of A and C sounds even better. It makes sense to separate Livewire from the various frontend adapters folks would want to use. However, I think having a “default” opinion (including project x scaffolding) would help adoption.

We could provide a command to swap it out for other adapters / presets, but would still be able to provide a nice quickstart sort of thing for folks who want to get moving in a hurry.

Livewire is awesome, but at the end of the day, we still need to write some javascript for modern apps. Bundling or defaulting to shipping project X with it would put the cherry on top, so to speak.

Another story / example: Laravel still ships with bootstrap defaults, and just with version 6.0 they split the frontend stuff into the laravel/ui repository. However, last night when I started a new app and wanted no frontend scaffolding, I noticed they removed any reference of artisan preset none from the docs. This is super confusing, and it left the experience feeling disjoint and very un-laravel-like. I couldn’t remember what it was and was baffled to find this missing from the docs.

Anyway, I think A is an acceptable solution, but bundling or shipping the default with C would remove a lot of “getting started” and “best practices” confusion.

4 Likes
#3

I pretty much agree 100% with this approach, combining A and C. I would love to see how Livewire can come standard with some functionality from Project-X, but if I want Livewire to work with some other JS framework, I would think I should install a different package.

From a maintenance standpoint it makes complete sense. You (Caleb) are never going to be an expert or even necessarily aware of every technology someone may want Livewire to interact well with. Forcing integrations with these systems to be a part of the Livewire core makes it a bad experience both for you and for someone who is an expert on [insert JS framework here] and wants to build and maintain the integration.

3 Likes
#4

I think we can go with ABC, and exactly in that order. It would be like a spaceship. First we make everything modular, and remove tight couplings. Then we take advantage of Vue’s current momentum and popularity and other integrations, because it’s not just basic binding and animations, vue has a ton of features most of which could be necessary in big projects, and also many comprehensive css frameworks. Then, when the time is right and projectX is solid enough, we swap out vue for projectx and save the world.

But I wanna stress on a more important point here: perspective and ambition. As I said in the github issue Livewire is not just a Laravel extension. It’s a new way of thinking, maybe a new paradigm, and a very dreamy one. So, it’s a good decision to decouple it from vue, and maybe even Laravel! If it grows big enough, other frameworks and tools will be opening issues in their forums and discussing how they should adapt to livewire. Let’s just keep this in mind and let it direct our decisions.

1 Like
#5

Thanks for the good thoughts everyone.

I think A->B->C is probably the best approach actually.

So first step is getting Vue support out of core and into a package the Livewire import’s by default. It will also make contribution to that part easier and less intimidating.

3 Likes
#6

A. Anything that requires you to track with other framework’s changes seems like a dark path.

1 Like
#7

Yes. Options A > B > C seems the most efficient approach.