Show HN: Build progressively enhanced reactive HTML apps using Go and Alpine.js

Show HN: Build progressively enhanced reactive HTML apps using Go and Alpine.js livefir.fly.dev/...

Fir leverages Golang’s standard library html/template package and a bit of alpinejs to allow building reactive UIs. You start with plain old html and use alpinejs to enhance it to bring no-page-reload interactivity to web apps.

The Fir toolkit is designed for Go developers with moderate html/css & js skills who want to progressively build reactive web apps without mastering complex web frameworks. It includes a Go library and an Alpine.js plugin.

How it works ?

On receiving user-interactions the fir server re-renders html templates and sends it over the wire where the fir client library selectively updates the changed areas.

When a user event is received by a Fir route, an array of html templates are rendered on the server and returned as an array of DOM events to the browser. The DOM events are consumed by the alpinejs plugin and dispatched within the DOM where listeners attached to elements can use the event to update the DOM.

See the demo and quickstart here: https://livefir.fly.dev/

The idea of using Go and Alpine.js together for building reactive web apps seems promising. As you mentioned, Fir is targeting devs with moderate HTML/CSS & JS skills.

How does Fir handle more complex scenarios such as nested components, handling form submissions with client-side validation, and integrating third-party APIs or libraries?

Does the toolkit offer any built-in functionality or guidelines for handling these cases, or is the developer expected to handle them using custom code and Alpine.js plugins?

Also the site is super slow!

realrocker · 3 years ago

This example has most of the scenarios you have called out: https://github.com/livefir/fir/tree/main/examples/fira. Fir aims to limit itself to rendering templates on the server and making it available for all subscribers as a browser CustomEvent which is consumed by alpine.js for more complex interactivity. The expectation is the that the developer handles it via either alpine.js plugins or standard JS code.

[edit] This is still a work-in-progress so I will certainly add better guides and documentation moving forward. Although its good to get feedback that this approach might be interesting for at least some people.

Art9681 · 3 years ago

I think this is adding unnecessary complexity. One of the reasons developers gravitate towards a framework like Alpine or HTMX is to write less JS and go back to enjoying HTML. Of course there are a lot of use cases that require custom JS scripting. But bootstrapping a project with another Go web framework and adding Alpine is also trivial. But keep going and follow your vision. I love these types of projects. Check this one out:

https://pushup.adhoc.dev

It's got some unique ideas.

ajd1988 · 3 years ago

fshr · 3 years ago

Interesting stuff; is this intended to be an experiment or a longer-term project? I think a straight-forward comparison of Fir and things like HTMX (htmx.org) would be a good addition to the demo page or docs. I’m not one, but from what I gather many golang enthusiasts like using the std http features of the language and other libraries like HTMX seem more appealing as they live just in the html templates. It’d help get a quick idea of how it fits in with existing libraries. For instance, the pubsub feature would be a distinction.

It is intended as a longer-term project originating from the previous experiment: https://github.com/adnaan/gomodest. You are right, a better selection criteria for the target audience should be enlisted. I have been working on this for a while so I just got greedy for some early feedback.

kindofabigdeal · 3 years ago

The one thing that golang really needs is a templating library that doesn't suck, Html bindings in this language feel more like an after thought and this is coming from a person that really likes this language.

lormayna · 3 years ago

Have you tried this: https://templ.guide/ ?

This is a very simple and clean Go templating library.

austinpena · 3 years ago

I’m really looking forward to IntelliJ support

jakelazaroff · 3 years ago

I spend most of my time in the JavaScript ecosystem, but I've worked with Go and Rails and have been working with Django recently and my take is that this seems to be true for most other languages/frameworks.

There are plenty of valid criticisms of React/etc, but the one thing they got really really right was making "templates" be normal functions that return a data structure representing the HTML. Logic is way less awkward, no global variables spanning partials in different files and it's impossible to write incorrectly nested markup. I really wish backend-only frameworks would steal that idea.

quickthrower2 · 3 years ago

Next.js very literally does by running React on the backend too!

Dead Comment

whiddershins · 3 years ago

The second example counter is jumping around instead of incrementing/decrementing by 1. Is state being shared between users or somesuch?

Or is it because I first clicked the full reload example several times?

iOS

The state is shared between users for the demo. Its possible to separate state in the library per user but I haven't enabled it.

tobr · 3 years ago

It’s a rather confusing demo. If that’s the intended behavior, I think you need to think of a less surprising use of it that can be understood as a demo, and perhaps even comes across as a benefit rather than a bug.

quaintdev · 3 years ago

Seems like everyone is just pushing the red button. Let me give some love to green button.

As a sibling said, this is not a bug, but a feature, if explained as such.

I wonder if it slow because of the locking, because other than that it shouldn't use much resources to run this.

Anyway I am lazy, so I would probably just use HTMX boosting:

    <div hx-boost="true">
        // traditional code goes here
    </div>

Its locking and the state is shared. Didn’t expect a lot of interest for this or I would have built a better demo :)

htmx is great!

mcspiff · 3 years ago

Is there a tl;dr on why I’d want to boost? Vs say normal browser behaviour

So that the things that change only appear to update, not a flash of the entire screen. If the request is slow, this makes a bigger difference of course.

examplary_cable · 3 years ago

I'm currently working with Alpine.js in order to try to build "Universal Components" or "Hypermedia Components". Where you just hit a URL and get your component like /components/infinite-canvas or /components/svg-2-base64 or /components/lib-somelib.

[1] ilse.ink/components(It's not ready yet)

TigerTeamX · 3 years ago

Sounds interesting.

ilse.ink/components didn't work. Could you post a link to it?

I'm still working in it, but that's going to be the link.

Trying to make universal components is hard, like, I wanted to make all components available trough a "filter" where you could re-use React.js, Vue.js, Svelt, Solid components with each other. When you think about it, components are just I/O with maybe some libraries. I'm thinking this is field is right for some standardization.

msolberg · 3 years ago

This is very cool. I'm working on a side project right now with a go back end and alpine front end. One of the things I've had to overcome is handling cookies and CORS since not everything is served from localhost.

I ended up packaging my frontend in an nginx container and using that same nginx container as a proxy for the backend but the whole time I thought maybe this small project would be easier if everything was served by go.

Will definitely keep an eye on this for future stuff.

cyneox · 3 years ago

I've also used alpineJS, Golang and tailwindCSS to build gocial [1]. The source code is also publicly available [2]. The whole project is hosted at netlify as a big Lambda function.

But I think for future projects I might use HTMX + Tailwind.

[1]: https://gocial.netlify.app/

[2]: https://github.com/dorneanu/gocial