I recently started using htmx (<a href="https://htmx.org/" rel="nofollow">https://htmx.org/</a>) in combination with Django and have become a firm believer of sending HTML 'over the wire' instead of JSON structures that then get used client side.
I feel that the simplicity of just building on the server and pushing the updates across the wire is where we are heading. So a lot less double up, with regards needing to write both for the server and client. Validation especially will just need to be written once.<p>Although I do feel Phoenix Liveview is a better option because they implement sockets.<p>Also saw this update today they will allow you to trigger javascript on the client without the sever round trip, it's one of the things people get a bit stuck understanding. Generally they think to pop open a modal or menu requires a round trip to the server but really you should be using Alpine.js or similar for such things. This new pending update remove the requirement of needing a framework like Alpine. <a href="https://github.com/phoenixframework/phoenix_live_view/pull/1663" rel="nofollow">https://github.com/phoenixframework/phoenix_live_view/pull/1...</a>
Awesome. I’m noticing a ton of “alternative” front end development tools these days: Hotwire, Stimulus Reflex, LiveView, Livewire, etc.<p>However I don’t think javascript is the fundamental blocker. When people say they dislike building SPAs, they probably mean they dislike APIs and the whole circus of double validations, error catching, form handling and cache invalidations that come with a React/Vue SPA.<p>Inertiajs[1] is a really solid middle ground of MVC goodness and client side interactivity.<p>[1] - <a href="https://inertiajs.com" rel="nofollow">https://inertiajs.com</a>
Will we see a bit less SPAs and more of this?
Rails has come up with Hotwire. ASP has something similar I think...only questions is what CTOs will make of this. And front end devs who are super used to doing SPAs won't like this change I fear.
I'm really into the idea of HTML over-the-wire, with Blade templates and PHPUnit tests. No need to split the logic between the backend and the frontend.
However I still need SPA navigation and although there's a Turbo adapter [0], it looks like more of a prototype at the moment.<p>[0] <a href="https://github.com/livewire/turbolinks" rel="nofollow">https://github.com/livewire/turbolinks</a>
For Django users, see <a href="https://www.django-unicorn.com/" rel="nofollow">https://www.django-unicorn.com/</a> - which is pretty much a port of LiveWire.
Laravel abstracted the PHP language enough that there are "Laravel developers" who cannot work without a framework. Now, these gems are going to do the same thing with HTML and Javascript!<p>These tools are contributing to the lowering of code quality standards, regardless of their intentions or the rigidity of their coding standards. They're good tools once you understand how they work, but most of its users use it precisely so they don't have to.
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..
This is great. It inspired many frameworks to come up with similar solutions. Here is one for Python/Flask:<p><a href="https://pypi.org/project/Flask-Wire/" rel="nofollow">https://pypi.org/project/Flask-Wire/</a>
I use Livewire quite extensively in production and it’s great. As someone that never got into Vue/React it has allowed me to build some pretty awesome and interactive UI’s.