Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Awesome looking project. I like how simple it seems to feel. As someone who is far less interested in writing web frontend, I have been keeping my eye out for projects that keep me from having to write JavaScript and let me express more of the logic in the Go backend. I noticed that you said the project took inspiration from gomponents. However that other project looks like it uses explicitly defined html methods instead of string literals (Div() as opposed to "div"). What are your thoughts on not having that compile time safety against mistyping a lot of things? I've seen other SPA projects also define out all the declarative tags. The Page object takes a specific zerolog Logger. Any reason not to accept an interface so projects can pass their own logger? Or is zerolog heavily relied upon internally? The one other project that I've had a quick play with is https://go-app.dev It is focused more on being PWA with the webassembly approach and let's you write Go logic in the client. But it also uses a declarative style and has explicit type safe tags. Any thoughts on this project compared with yours? Obviously yours is much lighter weight. Last question is, do you have an example that includes navigation? I was following your "one page one user" statement and curious what it looks like to design multiple views (pages?) with navigation.
I am aware of Hotwire, and I did consider it, but after studying it, I do not like the model.
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.
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.
I did start to build an HTML component library, but I found it was getting in the way of development as it's a great deal of work. I wanted to get the API right first. Once I feel I've got the API right, I will consider creating an HTML component library. I've already started on a component library, not for HTML but for https://bulma.io components (a set of components that works well with HLive). So far, it's working well, and I would not see issues with creating an HTML component library. I would also need to decide whether to keep it a separate project or include it directly in HLive.
This is still hypothetical. But ya here is one example of a plugin I currently use that would modify the DOM: https://github.com/gorhill/uBlock