Pro hype here, BUT add htmx to it and it's a match made in heaven. Rationale: templ is a template engine with the same syntax as go (so no need to learn or be worried about any new syntax). Htmx makes html more powerful
I don't see how it compares. Go-app does page rendering in the frontend, in this website's case based on Markdown files. It does have some backend generation capabilities (for SEO, apparently) but that's not its main feature.
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.
The same developers that were raised and soaked in Java enterprise development are now Go developers. Expect more of this especially as Go enters the Enterprise sphere.
I figure that Go is to C what Java was to C++. Between that and Go's background as a big company tool designed for big company work, the tendency towards Javafication should come as no surprise.
Just need to point out that "Most HTML is valid JSX" doesn't really sound true to me. Eg, show me a non-trivial HTML web page that doesn't have any `class="..."` attributes (I've managed to avoid doing much React/JSX for the last few years, but I seem to remember that you had to use `className` because `class` is a reserved word in JS).
What I mean is that what’s old has been new again for at least 9 years (React), but it’s also been looking quite similar for at least 3 years (SwiftUI and Flutter).
The biggest difference being in React, the render cycle is a synchronous, blocking function call, but attempting to access any remote data is purely asynchronous.
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.
There is obviously an improvement in type safety. This would transform silent HTML typos into Go compile errors. Though I could understand some thinking this is not worth the extra syntax.
Am I the only one who uses declarative programming when it makes sense, and $other-type-of-programming when that make sense?
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.
Counterpoint: Everyone had to "get used to the patterns" for the first programming style they learnt (even if they've been programming long enough to forget that).
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).
I think you’re confusing Progressive Web App (PWA) with Progressive Enhancement. PWA is basically a web app (typically an SPA) that behaves like a native app, as described in the MDN page they reference. Loading progressively such that the page is still useful without JS is Progressive Enhancement.
It looks like an HTML templating engine. I guess it packages the HTML rendering itself into client side WASM, but I'm not sure if that's an improvement.
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.
I find that most these sorts of projects are for people just toying around or who have an irrational hatred of the JS ecosystem... Ultimately they lock devs into a tight, less supported ecosystem, and they might end up writing some parts in the languages native to the web anyways. And I mean, the page doesn't even load for me on my browser, just stuck at 0%. What kind of documentation page even needs a progressbar, just use a static page, right?
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.
Loads just fine in my browser. I wonder what's causing this to fail for so many people. If I hold down F5, I do see the progress bar rise to 484%, but it loads in a flash for me. Maybe it's a bandwidth issue? The 4.5MB WASM file could've overwhelmed the website when it got slashdotted by the (many bots crawling the) HN front page.
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 progress bar is (presumably) for PWA installation, it really shouldn't be showing beyond the first load (yet it is, lol). Ideally it should just do the install in the background while you use the site normally, too. It's a shame the offline functionality of the doc site just _isn't very good_ even though documentation is one of the easiest types of application to serve offline.
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.
As someone who has contributed to Electron alternatives, I welcome it. Electron.js is so large, binary size wise, that we should be picking the right web-app stack for the job. Webview for example, to allow one to write web-apps in C++ with bindings for other languages.
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.
No, it’s not an alternative. It’s a runtime for doing PWA’s using Go for WASM targets. Not even the same thing. But, if you’re doing go on the back, and now go on the front, there’s very little glue required for a full-stack standalone go app with a beautifully complex HTML UI.
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.
Find me another way to build cross platform applications with a consistent look and feel that isn’t Qt/C++. Electron sucks but it’s filling a gap left by the desktop api teams. As said, there’s others instead of electron. The post here is about building wasm pages as a PWA. So it’s something you could use for pure web applications (in go).
I shipped a huge product with GWT. Backend and frontend in Java. It's still running (unlike many Java GUIs I made). I don't see why this wouldn't work.
Templ is a far more elegant solution for composing HTML within Go