live VS hotwire-rails

Looks like there are a couple of attempts but my google fu didn't really yield a winner.

https://github.com/while1malloc0/hotwire-go-example

https://github.com/jfyne/live

if that's the case, there is definitely an opening on the market for such tech.

As someone who's been writing web apps since DHTML days, Livewire/Turbo feels like we've finally reached the future.

You can see all those “live-” attributes in a small example above. We just say: “ live-click=’tempUp’ “ and Live implementation makes all bindings to our backend code and makes a websocket call for the appropriate Go handler.

LiveView implementation for Go raised the same type of feelings in me when I went through this for the first time.

And here it is, where LiveView programming concepts help us in a great way. LiveView uses websockets to create a persistent connection between the client and the server, which enables the server to push updates to the client in real-time. This allows developers to build interactive user interfaces that can update dynamically in response to user actions or changes in the application state, without the need for traditional page reloads or AJAX requests. LiveView programming style is based on this excellent Live project that is an implementation of the LiveView approach in Go.

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me. I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion having many years of experience in both kinds of web apps.

I've been working on a Go implementation if you fancy trying it out

https://github.com/jfyne/live

I built it because I love building highly interactive web pages, but the current state of JavaScript leaves me cold. I got really excited when I saw what Phoenix was doing with LiveView and thought I could see the light at the end of the tunnel. There are already a couple of projects also inspired by LiveView (GoLive, live), but I had my own vision that I wanted to realise.

Josh Fyne started a nice implementation of a Phoenix LiveView Go implementation here: https://github.com/jfyne/live

Applications generated with Rails 7 will get Turbo and Stimulus (from Hotwire) by default, instead of Turbolinks and UJS. Hotwire is a new approach that delivers fast updates to the DOM by sending HTML over the wire.

For Ajax-y stuff, I am really excited by the new crop of "HTML-as-a-Service" or "HTML-over-the-wire."

https://htmx.org/

https://hotwired.dev/

For all the turbo/stimulus/hotwire mix, you want to add a new feature just for the sake of adding it? or do you have a use case that fits the feature? if you have then you probably already have an implementation with a different technology (stimulus reflex? some custom websockets or ajax implementation? something with anycable?) and you have to check how to migrate from that technology to hotwire. If you just want to use the feature with no real need for it to practice then just pick any tutorial from the internet (like the intro in the official website https://hotwired.dev).

I was recently interested in similar topic. Here are 3 similar solutions I found:

* https://htmx.org/

* https://unpoly.com/

* https://hotwired.dev/

My personal preference is Unpoly (the idea of "layers" is awesome). But the best explanation of concept as a whole (HATEOAS, keeping app state on server using partial page updates, etc) is at HTMX homepage, and in these essays:

* https://htmx.org/essays/hateoas/

* https://htmx.org/essays/locality-of-behaviour/

At the end of 2020 the Basecamp team released a collection of Javascript libraries called Hotwire. Modern web stacks have popularized javascript-rendered front ends and JSON transmissions. Hotwire's primary motivation is to reduce the Javascript footprint and allow application front ends to be created in primarily HTML. It pairs very nicely with the Ruby on Rails ideology and is often demonstrated in that context. I aim to write a series on how Hotwire can be used in any application to simplify development and reduce the need for heavy Javascript downloads. Hotwire currently consists of two javascript libraries: Turbo and Stimulus. The first part of this series introduces Turbo.

I've been doing that a while until I just got sock of the JS spagetti and often duplicated code and went full on Angular CSR and never looked back. That being said, I've been seeing a lot recently about Laravel's Livewire and Symfony and Ruby on Rail's integration with Hotwire (stimulus+turbo).