There aren’t really much PWA/front end libraries for Go, despite being a strong backend language. I am curious to see how Go would compare with JS considering that WASM exists, and Go has GopherJS and Yew. Also would it be faster than JS if it were browser-native?
1 Like
It is hard to compare a server side language with a browser side language IMO. But I prefer Javascript /AJAX when fetching data from API or a database in order to reduce the flickering because the whole page do not have have to be rendered / reloaded when updated with new data. I cannot see any speed increase using Go instead of Javascript. Just less flickering…
Both SSR (Server Side Rendering) and CSR (Client Side Rendering) have their benefits. But a mix of them is SSG (Static Site Generation) may be more beneficial. Which means that Go renders the HTML at build time from templates and all dynamic content provided by AJAX (Javascript).
Disclaimer: I have not tested WASM, but as I understand it will it be slower to load initially.
1 Like
Apart from Go’s fat WASM size which is a severe con for now, I would hope WASM can replace Javascript entirely whenever possible. Why? → Mainly due to:
- type constraints
- code shedding (only packs codes that I need)
- Re-use my Go library as much as possible
- PWA compatibility (offline and online modes)
What I can see Javascript framework/library can’t get through code shedding (hence the complaint of fat and bloating library or framework, usually near its development maturity) without another of its derived library to do the compiling job.
Do I hate Javascript and its derivatives? No. However, if a CSR can re-use my SSR library codes with a single programming language, I will definitely use it.
I can see the next evolution is server-side only offers API while client-side performs user interface rendering and operations, especially given the current geo-political reasons and warfare =( ; and E2EE requirements (e.g. Bitwarden).
FYI: I will begin full WASM exploration starting next month intending to upgrade my hugo theme module into full CSR frontend library.
1 Like
Well, I would not hope to much in this direction mainly because WASM programming is very complicated than the classical even if we are talking about JS and suppose a big effort even to do small things. I suppose that this is the reason because is not wide spread nowdays.
1 Like
I believe it’s some JS task force members (those that have superiority complex) are blocking improvements. It’s not just affecting WASM; even JavaScript is affected [This Stage 3 time library proposal (Temporal documentation) caught me completely off-guard and by surprise. Still experimental and proposal?! are you kidding me?].
Besides, it’s quite obvious the original intention was to replace JS. However, this will trigger tech political uprising among the JS community so it was changed to complimentary. As you know, when politics involves, everything is expensive and slow.
If Autodesk can bring AutoCAD (Roundup: The AutoCAD Web App at Google I/O 2018 | AutoCAD Blog | Autodesk) to the cloud without too much changes (https://web.autocad.com/login), heck, I’m convinced with the investment.
Besides, we’re not limiting to Go. C, Rust, or other proper programming languages can go on-board with WASM.
1 Like
Yeah C and Rust can also be used, but I just love how Pythonic Go looks like and how batteries-included it is. Rust seems too hard, and C is like Bugatti: really fast, but lots of maintenance needed with nulls, memory, etc.
1 Like
Also, I wonder if there’s a Phoenix Liveview backend only web app framework for Golang.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.