8 ms·
A Go Package for Building Progressive Web Apps
- habibur 5y agofunc (h *hello) Render() app.UI { return app.H1().Text("Hello World!") } Using a template would have been easier and more clear.
- wingi 5y agoCheckout hyperapp - same design, but pure javascript.
- dalu 5y agoI agree that it feels unnecessary and uncomfortable. There might be a reason why he chose this vs plain text or template, not sure.
- Maxence 5y agoHi, go-app’s creator here. I did it in previous version and since there is no code check/lint on HTML templates within strings, debugging HTML was a pain in the ass. More clear is a matter of taste and you can do pretty clear code with this syntax.
- kitd 5y agoSee also https://news.ycombinator.com/item?id=28564107 https://news.ycombinator.com/item?id=28564107
- pcr910303 5y agoIt looks like the browser crashes on every screen change on Safari 15 on macOS...
- charrondev 5y agoSame on iOS. It’s been a while since I’ve seen a documentation site with a loader that goes multiple seconds.
- mrweasel 5y agoI didn't think Safari supported PWAs, or is that a new feature in 15? Personally I'm still not a fan of PWA. I don't see what they give me as a user, other than a worse experience than a native application would have.
- sroussey 5y agoNo App Store, no install, no walled garden, no 30%.
- mrweasel 5y agoAs a user I like the App Store, all my software and purchases are all in on place. Installs aren’t really an issue, and less so if you like the app store. I can see the point about wall gardens, but you can still just install non-app store programs on all operating systems. Regarding the 30% I not convienced that saving are directly passed on to the end users. Edit: It just occurred to me that you might be think about software on phones. I don’t exactly care about mobile, but yes, then your argument makes more sense.
- sroussey 5y agoYes, I was thinking mobile when I wrote that. :)
- oefrha 5y agoPWA isn't a singular feature (well, beyond ServiceWorker, which is pretty essential), it's a group of loosely connected features exposing more native functionality to the web, and making the web app experience more native-like. The ServiceWorker API has been supported by iOS Safari for years: https://caniuse.com/mdn-api_serviceworker https://caniuse.com/mdn-api_serviceworker. When people complain about lack of PWA support on iOS Safari, usually the #1 complaint is lack of Web Push: https://caniuse.com/push-api https://caniuse.com/push-api. In this specific case, the site is working fine on iOS Safari 14, and Safari 15 TP on macOS Big Sur. I'm not sure if there are problems specific to Safari 15 on not-yet-released iOS 15 or macOS Monterey, I don't have an installation of either.
- oefrha 5y agoOne problem with golang's wasm target is that the generated binary is huge. For instance, I checked app.wasm of this documentation site and the four examples listed at https://go-app.dev/built-with https://go-app.dev/built-with: 0. This site: 14.9MB, 3.4MB gzipped; 1. 13.5MB, 3.2MB gzipped; 2. 15.4MB, 3.2MB gzipped; 3. 4.7MB, 1.2MB gzipped (this is an extremely bare bones demo); 4. 25.0MB, 5.4MB gzipped. You can save a bit more with brotli, but not much more. I built an app with golang wasm last year, but ended up rewriting everything in good old TS since I couldn't justify the ~15MB raw, ~2.7MB brotli'ed payload. I guess you can make some huge savings if tinygo has enough capabilities to cover all your needs. Not sure if it's possible with this library, but if it is, they certainly haven't explored it, hence the 3.4MB gzipped wasm for a documentation site.
- donatj 5y agoThe “good” news in my experience is that they don’t seem to usually get much larger than 15mb, I’m guessing it’s the wall you hit once most of the standard library is already included. It’s certainly not enviable, but I have absolutely seen sites with an equal volume of JS, so it’s not unheard of.
- chrismorgan 5y agoOne thing for old-school performance comparers to remember here is that WASM is very significantly cheaper than JavaScript to parse and compile. On an arbitrary fairly weak phone, 15MB of WASM might take two seconds to compile, but it can do that while downloading, so that in practice your network link will probably be the limiting factor. So the transfer size is typically the figure to care about and the uncompressed size actually doesn’t matter all that much. 15MB of JavaScript on that same device might take ten seconds or even more to compile, and it largely can’t even start until it’s finished downloading it. Consequently, you need to care about both the transfer size and the uncompressed size, in different ways. (My figures are super dodgy as I can’t find any recent concrete figures, but they should be in vaguely the right ballpark.) This is all about comparing just the cost to the CPU; data transfer costs money too and takes time, and several megabytes transferred is inconvenient to many for reasons of cost or time, and decidedly wasteful. Multiple megabytes even of WASM is still madness and folly for simple stuff like this, severely restricting its potential usefulness. Thank you for deciding not to ship something like that yourself.
- pdpi 5y agoWasm is good for a lot of things, but this isn't one of them. Go is notorious for generating enormous wasm binaries, and, sure enough, the wasm blob for this page weighs in at 14MB. I don't know how somebody keeps a straight face clainming their 14 meg page is SEO-friendly.
- dublin 5y agoSo much for assembly language being the most compact and efficient form of software... (Yes, of course I know it's assembly for a VM, but still, there's NO excuse for this kind of outrageous bloat!)
- pdpi 5y agoIt is compact and efficient. Problem is that there's a lot of it, because these payloads also have to include large chunks of Go's standard library. Apparently fmt and http are particularly large packages that will each add 1-2MB to your was binary.
- hbn 5y agoThe runtime alone is also roughly 700kb, or at least was as of 2017 when this SO answer was written https://stackoverflow.com/a/46159048 https://stackoverflow.com/a/46159048 Not sure if anything's changed since then
- oefrha 5y agoWith go 1.17, a minimal program doing absolutely nothing when built with GOOS=js GOARCH=wasm go build -ldflags='-s -w' comes in at 1.2M raw, 362K gzipped, 276K brotli'ed (default compression levels).
- cutler 5y agoHorrible html syntax. No thanks.
- trutannus 5y agoYikes, that's really nasty, you're right. Not sure why frameworks like this tend to reinvent the wheel. This isn't the first to create a new DSL for writing HTML. The most efficient way to write HTML is to use HTML, or an in-html template like Handlebars or embedded elixir. No need for a senseless abstraction layer on top of an already existing markup language.
- dalu 5y agoI saw this a longer while ago on reddit and wasn't convinced, because I asked questions but felt ridiculed in the answer. The question was about component reusability and inheritance. Also what about real time changes to contents when the values in the data store change (see ngrx, redux, vuex) aka reactivity. However good that I found it here because I wanted to take a closer look at it and play with it and doubt that I'd be able to find the post on reddit again. Also as much as I dislike Rust, it's closer to typescript in philosophy than Go and might actually be a good fit for the frontend wasm. I'm ignorant however and idk if the binary size is also a problem for Rust like it is for Go.
- Maxence 5y agoHey folks, just find this post, I’m go-app’s creator. Looks like a bunch of the discussion is about the wasm size. When its gzip it is not that big. People are talking about 15MB, none of my projects reached that size, and they are usually pretty liked by my users. For the syntax, it is a matter of tastes but things that people like about it is that its full Go and everything is discoverable from your editor with auto completion. At the end what’s matter is that it’s good enough to build beautiful UI only by using Go and it’s ecosystem.
- themihai 5y agoI've been building wasm powered apps (compiled from Go) for almost a year. Main issues: - the size of your build: you need to check what packages you import and possible trim them down - resource usage and performance(due the lack of DOM). - bugs/implementation: the browser may stop working/freeze after a while. There were some issues with the scheduler, I'm not sure if it's still the case. If you develop an UI for an embedded device this is a big issue. It may work for Desktop apps (electron based) or some enterprise apps so it has its niche but you definitely can "feel" the difference between a wasm implementation and a pure JS implementation. As a client you will prefer the JS version. As a developer you will love the Go version All that being said it's great to be able to use Go in browser and as the devices are getting faster along with the network I guess it will work just fine once 5G becomes mainstream. Hint: If you process HTML, always use the DOM/JS interface. Any processing of HTML (i.e. via x/net/html) in Go will make your app VERY slow.
- deleted 5y ago[deleted]
- turtlebits 5y ago3.5mb for a documentation site. This is several orders of magnitude worse than the JS framework plague. At least have a demo that warrants a package that large.
- windows2020 5y agoClick your mouse three times and say 'progressive web app' and you'll be taken to a bloated website in two seconds.
- zackoverflow 5y agoI enjoy Go but I don't see it playing nicely with wasm anytime soon. It's runtime is big, it has a garbage collector, and getting the complexity and nuance of goroutines to work in the browser with webworkers seems like a scary challenge.