As a Laravel user, I still avoid Livewire like the plague. Way too much 'magic' and it's not solving any of my real problems. I don't want to waste time learning Livewire because I really don't need to. Same goes for Laravel Breeze, Jetstream, Inertia, i'm sure they're great but I don't need any of it and they are becoming a thing that gets in the way more and more..
As a Laravel user, I am extremely happy about the different paths you can take and I think it's absolutely fantastic that you are _able_ to avoid those magical things like a plague, if you don't want or need them.
I find Livewire a pleasure to work with. It's certainly not a hammer for every nail, but a refreshing step away from the JavaScript madness without sacrificing all of the good parts about it (anything async, basically).
Like I said, It becomes harder and harder to avoid it and that worries me. I used Laravel because anyone could just hop in and be productive.. I've asked myself why I'm not using just Symfony already, because I think Laravel is something that it's not anymore, or wasn't ever. Laravel is basically Taylor's view on how people should write code.
Breeze and Jetstream are more recent optional packages, and Laravel is still productive without them. So effectively you are saying, “I wish Docker Hub had fewer images available, it’s more productive without.” Pfffft
I get your point and this conversation might be as old as Laravel itself. I would like to point out a couple of things though:
The "hop in and be productive" part is directly related to Laravel being pretty opinionated. It's hard to have the one without the other. I think it's comparable to Steve Jobs, who had pretty strong opinions about certain things, too. The end result is a "product" that doesn't try to be the right fit for everyone.
Livewire, just like Jetstream[1] etc. is opt-in. When Jetstream was introduced, there was quite an uproar (by parts of the community) about Laravel forcing users into Livewire or Inertia[2]. The end result was (imho) a very healthy shift in communication around it (to emphasize the opt-in part), followed by the introduction of Breeze[3], which goes to show that Taylor does recognize the reservations some people may have about those new shiny toys.
It's a very natural thing that big projects like that will have an ever-growing feature set. That is an important part of keeping existing users excited. The Jetstream-discussion has been an important lesson for the team (I hope) and I'm glad it ended the way it did.
You can still build your Laravel app in a pretty similar fashion as you would have done 5 years ago and if you want, you can make use of the recent additions, so I think there's not too much to worry about to be honest. If you have outgrown the magic, isn't it pretty amazing that you can drop down one level of abstraction and just use symfony? Also, do you think you would've grasped many of the underlying features of symfony, if it wasn't for Laravel's opinionated wrapping in a nicer syntax (pardon my oversimplification)?
Nevertheless, I think it's good to keep up the warning signs and have this discussion from time to time. ;-)
I have to admit, I'm still a bit biased against Taylor because of the Jetstream fiasco, but it seems it's getting harder to justify those feelings. Thanks for refreshing things.
Yes. But that is the case of all other tools and frameworks: a product devised by an individual's (or a group of individuals), opinion, taste and experience.
I totally agree and I hope they will remain external packages.
My workflow does not use/require any of them and I am happy as it is.
What it looks like Livewire is trying to solve is having a "reactive" way of doing things without touching javascript and by elimintating the need of implementing an API.
I understand the need of consolidating the dev process to one single language and siplify it but there is a reason why we separate backend and frontend.
I went down the rabbit hole of trying to minimize client side JS usage for web applications and interactions on websites with these kind of paradigms. I understand where it comes from and at first seems like a good idea. I tried prototypes, different libraries, tried to roll my own solutions etc.
What I found is that this is a good idea in _some_ contexts, namely if you can and want to treat the browser as a rendering engine for state snapshots. If you break with that assumption, you want something else, or you'll be slowly creeping into an ad-hoc, complicated mess, where there is no clear abstraction boundary for the UI. You just end up smearing it all over your code.
There are some fundamental reasons for this.
A technical one is that HTML isn't just data representation. It also dominates the shape of your UI tree. Do we really want to complect these things? The separation between HTML, CSS and JS is extremely leaky and blurry. The more you try to pull them apart, the more painful it gets. It's also the ultimate de-normalization of your data. Meaning it's going to be a huge PITA to coordinate if its not done in one coherent place.
Another issue is that you are breaking a separation of concerns and encapsulation. Does the server really have to know how I just toggled a menu, rearranged some widgets with drag-n-drop or switched a stylesheet? Trivially no. The server might care about some of that happening after the fact, but almost never about the details of how.
But this gets even more pronounced when you implement features touching on security, consistency and reliability. With a clearer UI and server separation you have two distinct mental models or modes. On the front-end you only care about the user experience and optimize for that: Immediate feedback, guiding messages, visualization and transitions. You can treat the user as your best friend and fulfill all of their wishes. But on the server you treat them as an incompetent stranger and/or as and adversary. Because, you know, its the Web! With this separation you enable focus and avoid mental taxation mixing things up. It's ultimately a simplification in the pure sense of the word.
With all that said, I don't doubt that many find this paradigm useful, especially because of what you said in your last sentence. And I'm sure that in many cases you can work around the problems I mentioned, or even model them well if you don't break with the assumption I mentioned at the start. But if you do anything interesting _in_ the browser you'll likely be forced to patch over the fact that you are now smearing your front-end logic all over places.
I feel like that sometimes but if you look at the open-source code and take time to understand it, it's not magic anymore but powerful abstractions. You could say the same about Laravel itself.
I don't argue with that. But the biggest problem is IDE integration. Too much magic and your IDE is becoming useless because it cannot autocomplete the most basic things anymore..
As a Laravel user, I agree with you completely. Laravel for API, Next.js/Nuxt.js to handle the frontend. It avoids depending on Laravel-<insert-name> frontend tool/framework/you-name-it.
Exactly, being able to pick your own frontend is what makes Laravel so useful to me. I hope they will give API functionality the same love and attention some day.
Swagger integration or something similar that generates documentation and live testing based on OpenAPI. Some support for endpoint versioning. Better ways to serialize models that have properties with computed values, on a specific request. ($_appends and $_hidden properties are getting a mess in complex projects). Plus, I'm sure people can up with more things I never knew I needed!
