vecty VS live

Vecty

It depends on how specifically you don't want to write HTML/CSS/JS and how broad your definition of "frontend" is. There are a handful of all-go frontend frameworks such as Vecty and Vugu of varying maturity and completeness. Then there's other libraries that more or less have you write HTML tags in go, such as go-app.

It draws on Go's syscall/js library as inspiration, which is pretty powerful (I wrote a pretty popular React-like framework using it a while back.)

A note on wasm: I'm building a hobby project with it right now and have tried different frameworks, I tried vecty which is nice to compile but full of bugs and unexpected behavior. I'm now on vugu which works better but is still harder to work with than a JS framework.

https://github.com/hexops/vecty/ is a framework for developing dynamic web frontends in Go. It's not production-ready, and will likely get some rewrites once generics drop, but it's pretty neat (I'm a contributor).

There's Vecty, though it's likely to get a bit of a redesign once generics drops.

How does it compare to https://github.com/hexops/vecty or https://github.com/bep/gr ?

Reminds me of Vecty from the GopherJS project: https://github.com/hexops/vecty .

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