7 ms·
Go Package for Building Progressive Web Apps
- bborud 3y agoWhy? Has anyone ever worked on a product where this would be even remotely feasible?
- hningonworktime 3y ago...So that you can make PWAs using Go? There are multiple "Built with" examples on the page - but why does everything have to be a product at the end of the day?
- FireInsight 3y agoI 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.
- jeroenhd 3y agoLoads 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.
- jackson1442 3y agoThe 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.
- reactordev 3y agoAs 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.
- pjmlp 3y agoI rather contribute to pure Web applications. Most people doing Electron probably never went through the XUL and MSHTML hype cycles. Electron will eventually join them.
- reactordev 3y agoFind 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).
- FireInsight 3y agoThis isn't an electron alternative, though, right? There's atleast https://wails.io/ https://wails.io/ for Go, and https://tauri.app/ https://tauri.app/ for rust ofc.
- candiodari 3y agoI 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.
- ekiauhce 3y agoIs this some kind of joke? 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”
- jbotdev 3y agoI 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.
- benatkin 3y agoIt’s conflating progressive with “progress”. It’s like conflating functional programming with whether it functions.
- Exoristos 3y agoTo be fair, Progressive Web App is a pretty stupid nomenclature.
- omani 3y agoI have used this and I like it.
- awill88 3y agoHold up, they lost me at “declarative syntax” no, it’s Golang. It’s not infrastructure as code. Hard pass, use templates..
- rubicon33 3y agoAm I the only one who feels like declarative programming fucking sucks?
- l5870uoo9y 3y agoOnce you are used to the patterns and functions coding becomes faster, easier to understand and less error prone.
- latchkey 3y agoYou should never have to "get used to the patterns"... that in itself is an anti-pattern.
- jcparkyn 3y agoCounterpoint: 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).
- diggan 3y agoAm 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.
- rubicon33 3y ago> When creating UIs, I haven't found anything better than declarative programming 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.
- 3y ago
- latchkey 3y agoSigh. What is old is new again. It was a terrible idea back then too... https://jakarta.apache.org/ecs/ https://jakarta.apache.org/ecs/
- benatkin 3y agoThis shouldn’t be news. There is JSX which is like this but with a special syntax, and there’s Swift and Flutter which look similar.
- latchkey 3y agoI created ECS... checks notes, 24 years ago. https://svn.apache.org/viewvc/jakarta/ecs/branches/ecs/ https://svn.apache.org/viewvc/jakarta/ecs/branches/ecs/
- benatkin 3y agoWhat 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).
- deleted 3y ago[deleted]
- zdragnar 3y agoThe 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.
- deleted 3y ago[deleted]
- dewey 3y agoI can't come up with a single reason that makes this better, easier, shorter than just using a html + Go templating.
- janderland 3y agoThere 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.
- Sheeny96 3y agohttps://github.com/a-h/templ https://github.com/a-h/templ Templ is a far more elegant solution for composing HTML within Go
- adonese 3y agoPro 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
- flashgordon 3y agoHoly mother of God. This is exactly what I've been looking for!!
- austinpena 3y agoHas anyone got this working with IntelliJ?
- jeroenhd 3y agoI 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.
- udkl 3y agoLooks like what PHP does !
- didip 3y agoI prefer writing a normal server-side with Go template and use HTMX on the client side.
- omani 3y agoLook at the comments here. Are you guys stupid bots? It's about WEBASSEMBLY. Not an html template system.
- cdelsolar 3y agoThat’s kinda mean
- wetpaws 3y ago[dead]
- jeroenhd 3y agoIt 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 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 https://go-app.dev/seo) for SEO reasons, so in a sense the project is ALSO a server-side HTML templating system.
- deleted 3y ago[deleted]
- jtokoph 3y agoIt’s odd to me that children are added via a Body method. I would assume it would be a Children method; plus body is its own HTML tag.