Hey @Toby,
first I'd like to congratulate you for launching this project, it seems very well put together and mature to me. I regret that I currently don't have the need for a discussion platform, but Waterhole will be my first choice in case that changes.
As a fellow web developer I was wondering if you have any thoughts on the stack you chose for this Laravel setup, now that Waterhole is over a year old. I'm especially curious what you think about Hotwire in combination with Laravel.
Cheers from Germany,
Michael
6 Comments
Hi @Michael, thanks very much for your kind words.
In my other job I work with both React and Vue, and coming back to Waterhole is always breath of fresh air. I find the Laravel + Hotwire stack much simpler to work with and reason about. There's no client-side state management to worry about, no rendering performance issues, and working directly with the models/database is refreshing.
I'm a huge fan of Laravel's Blade components in keeping the view layer nice and tidy. And I really like the Hotwire paradigm, because at the end of the day, it feels like I'm building a really basic web 1.0 app, just with a bit of progressive enhancement. I would highly recommend it!
I really wanted to know, Why Hotwire? why not use Livewire for this project?
I only reason i'm still thinking about buying this package is Hotwire choice, not a deal breaker but i don't want to know yet another stack outside work.
@Manoj Hotwire and Livewire are both great, but they are quite different approaches to building Laravel apps.
Hotwire is an approach to progressive enhancement. You are basically just building a traditional hypermedia Laravel Blade app with forms and links. Hotwire is a light sprinkle of JavaScript on top which enhances those forms and links to use AJAX rather than requiring a full page reload. The app will still work fine if JavaScript is disabled or fails to load.
Livewire, on the other hand, is a more fundamentally different approach. You use Livewire components which have proprietary paradigms for managing state and interactivity between the client and server. If JavaScript is disabled or fails to load, the app won't work.
Hotwire's approach makes a lot of sense to me, which is why I chose it for Waterhole. It's simple, light, resilient, performant, and has a great developer experience.
@Toby I'm currently using Livewire alongside Waterhole but after reading this, I am considering switching to Hotwire.
I started my project off with the Waterhole Skeleton Repo (composer create-project waterhole/waterhole), and I was considering installing Turbo-Laravel as a package rather than relying on the version Waterhole/core is using (so I could update to the latest version of Turbo-Laravel faster than relying on Waterhole updating it's dependencies).
My question is, do you think that's a wise idea? My concern is that having two versions of Hotwire could cause issues.
In general, yes, it's wise to add a package you explicitly depend on to your project's
composer.jsonfile, rather than assuming that it is included via one of your other dependencies. This way you can specify your own version constraint, and then if there is an incompatibility between the version you depend on and the version Waterhole depends on, Composer will yell at you.If you want to depend on a version of the package that Waterhole is not compatible with, then you would need to either wait for Waterhole to update or separate Waterhole into its own project.
Okay, that makes sense, thanks!