There are many scenarios where you have to use other libraries and frameworks with livewire, simply because some problems are out of the scope of livewire. For example we need css frameworks for styling, layout and components, and we need js frameworks for frontend reactivity.
Of course livewire should and will grow in many areas, but since the basic features are there and the stability is acceptable, this might be an important bottleneck right now. The problem is some css libraries like bootstrap are tightly coupled with old and unnecessary js libraries (not naming any names), and others like buefy assume you're doing everything with ajax, and that's just styling and basic components. If you try to do anything serious with Vue or other js frameworks you won't have an easy time.
So we need to talk to other frameworks that are trying to solve different problems than ours, and it shouldn't be a problem, but it is, because they are also trying to solve them with very different mindsets.
Livewire is a new way of thinking, a new paradigm if you will. So, we need to put some time into making its position in the big picture of web development a bit more clear, if it's going to be a reliable tool.
For css frameworks, the first quick workaround might be to use pure css frameworks like Bulma, Tailwind or Milligram. But since there's no escaping the js framework integration, we might wanna keep an eye on frameworks like Buefy, Vuetify, Materialize, Material Lite, etc. that either use Vue or their own minimal js behaviours.
For js frameworks, there's more to do. I remember when you decided that livewire isn't for things like animations and everything that needs to be fast and doesn't rely on backend data. That was a good call. But what about the things that don't fetch data from server but work with data that are already fetched by livewire and might be updated? Like autocomplete for example. It's probably easy enough to wire:model the query, but how do you pass the data to autocomplete components?
Here are some very basic things that can't be easily done apparently:
https://github.com/livewire/livewire/issues/388
https://github.com/livewire/livewire/issues/349
https://github.com/livewire/livewire/issues/190
https://github.com/livewire/livewire/issues/301
You might have a clear decision about some of these problems. Then it's a matter of educating people on it. But even if there are real problems, they are of course solvable like every other problem livewire has encountered until now. We just need to keep it in mind, and give it some love.
Very much agreed on @mokhosh. You captured the situation perfectly.
Here are the options:
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)
Pros:
B) Focus on supporting Vue out-of-the-box, as it's the most popular in the Laravel ecosystem. (this was the original approach)
Pros:
C) Provide a JavaScript framework solution (Project X)
Pros:
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. What do you think?
I also DO see the potential for ProjectX being the recommended JS solution with Livewire. They both share a lot of the same API and approach anyways.
Moving this discussion over here: https://forum.laravel-livewire.com/t/should-livewire-support-vuejs/74
I'm so confused why I'm hearing about ProjectX for the first time here, and so happy I just said to myself "hey google it, it might be a real thing and not just a placeholder name" even though I wasn't all that optimistic! 馃槄
@mokhosh
projectX has been renamed to Alpine.js and can now be found at this link
Most helpful comment
Moving this discussion over here: https://forum.laravel-livewire.com/t/should-livewire-support-vuejs/74