Go Package for Building Progressive Web Apps(go-app.dev) |
Go Package for Building Progressive Web Apps(go-app.dev) |
Templ is a far more elegant solution for composing HTML within Go
I suppose you could probably port templ to a frontend framework through WASM, but I don't know why you would go through the effort when go-app is already there.
"Software engineer who loves building fancy and unuseful things for the sake of freestyle."
Most HTML is valid JSX, minimizing the mental overhead. JSX has great tooling, and TSX has great type safety.
But nobody wants to make An App.
Jakarta and go-app.dev seems to be similar to React, but in no way similar to JSX.
When creating UIs, I haven't found anything better than declarative programming. But in the end, it's all trade-offs, nothing seems to be a silver bullet, UI programming just fucking sucks in general.
This is only true for basic UI. The more complex it gets, the less I like declarative programming.
Declarative is great for simple static UI, and configs. That's pretty much it.
I waited about half a minute for percent counter reach 100%, then it just keep loading with the counter beyond one hundred lol
So “progressive”
I'm not sure what the WASM part does from the website to be honest, at first I thought the server generates the HTML but it seems everything is rendered client side? The architecture page (https://go-app.dev/architecture#app-wasm) describes the basic working of a WASM application, but that's it. There's also pre-rendering (https://go-app.dev/seo) for SEO reasons, so in a sense the project is ALSO a server-side HTML templating system.
Has anyone ever worked on a product where this would be even remotely feasible?
Edit: for what it's worth, I gave this a second chance with raw Chromium. Loaded up to 400%, heh, but tbf the page does have product examples for seemingly useful products.
These projects make a lot of sense, I think. You only write one system, not a separate frontend and backend, and let the middleware sort everything out.
The code rendering the plain HTML is the same code that re-renders the entire page when you switch to another page, without necessarily re-fetching data from the backend.
This is terrible for websites (ironically, like this website, which documents the framework), but great for web applications. Most native browser navigation is pretty jarring unless you add a bunch of javascript to hide navigation taking place, but if that frontend expands, you're pretty quickly building two systems (a frontend and a backend) to solve one problem.
The page _does load_ offline, but several pages are showing markdown render errors (may just be unvisited pages), images are generally missing and showing alt-text instead, etc.
I'd say offline access is the killer feature of PWA as documentation, but it's just not executed well enough here.
There are multiple "Built with" examples on the page - but why does everything have to be a product at the end of the day?
Personally, go’s ability to serve content from its own binary using the `embed` package is one of the most killer features. I can ship a single binary and have my entire client packed inside. All at 28mb.
There's atleast https://wails.io/ for Go, and https://tauri.app/ for rust ofc.
Most people doing Electron probably never went through the XUL and MSHTML hype cycles.
Electron will eventually join them.
That shouldn't be a reason to avoid learning a different style -- unless there's good reason to believe that style B's patterns are much harder to learn than style A's were (which I'm sceptical of in this specific case).
So yeah, it’s not an electron alternative, but another arrow in the quiver to get Golang to be taken seriously outside of microservice/system-land. It deserves more. It’s not Rust, but it should be easier to build apps with Go for distribution.
This package though can help some folks bridge the gap between WebGL/WebGPU in Go WASM and their HTMX UI. I could be entirely mistaken having not used the package before but from what I’ve seen on their docs it should be possible to do full client wasm.
There's no way to repeat the horror of calling MySQL from a PHP template or whatever you might be able to do here.
It's still possible to write bad code, of course, but the old justification don't quite apply to react like they might here, or elsewhere.