Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We replaced our React front end with Go and WebAssembly

dagger.io

Post reply on HN
Print view View original

211–220 of 242 posts

Re: We replaced our React front end with Go and WebAssembly

#211

Post by whitehexagon »

notpushkin wrote: post #158
whitehexagon wrote: post #112

Earlier quoted context omitted.

I also struggled with the binary output size of Golang WASM, and that it was growing with each version. Someone recommended TinyGo, and although I haven't needed it for a couple years now, at the time the WASM binary output size was much better. Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough…

I’ve been looking at Zig for some time, too. Perhaps I should give it a go! Any particular tricks on making bridged DOM fast?

I use a custom API on the JS side, and making the most of the shared memory for strings. For widget creation within DOM I have small API wrappers on the JS side to avoid too much bridge crossing with attribute sets/gets.

For 2D/3D moving the canvas animation loop to the JS side helped.

So far the html (inc custom JS API) comes in at 20KB, and my wasm around 80KB (SVG based UI with a small embedded font).

Not sure how the latest Zig compares, but I'd be quite happy stuck on this older version for this project because it seems very stable.

Re: We replaced our React front end with Go and WebAssembly

#212

Post by vito »

kabes wrote: post #120

Early in the post: > As a small team, we need to ship fast. So they chose a solution that required them to: > Spent almost a month prototyping > there was no real ecosystem for Go-app UI components and we knew we’d have to write our own > Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture Not sure what their definition of shipping fast is, since this just sounds like resume oriented…

What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first.

During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.

Re: We replaced our React front end with Go and WebAssembly

#213

Post by spiffytech »

ahoka wrote: post #173
iforgot22 wrote: post #166

Earlier quoted context omitted.

Can that at least be a separate wasm file from some common URL so the browser can cache it?

Browsers don’t do that. Caches are not shared across sites.

Nit: they don't do that anymore, because cross-origin caches cause privacy problems. But they used to, and this news is still percolating through the industry.

Re: We replaced our React front end with Go and WebAssembly

#214

Post by pier25 »

omcnoe wrote: post #139
pier25 wrote: post #20

WASM makes sense for certain niche use cases but it's really absurd just to make a regular web app. This is an app made with go-app and it loads 3.6MB of WASM code for a simple media player. https://lofimusic.app/collegemusic It's not much different for Blazor. Even for a simple app you're looking at an initial load of at least +1MB.

Apple music web player loads >8MB of resources. Spotify loads >12MB. Sure this is including some images etc. not just the code bundle, but it's not like other examples of SPA's are small. IMO the end solution for this bundle size issue is for browser vendors/wasm designers to work with languages to setup cross site caching for these large language runtimes, built and distributed from trusted upstream builds instead o…

> Apple music web player loads >8MB of resources. Spotify loads >12MB. Sure this is including some images etc.

I wasn't counting content, just the WASM files.

Spotify , SoundCloud, etc are not great examples as their players are bloated with tracking features etc.

Our player at Wavekit[1] weighs 33kB (compressed) and is customizable, includes multiple web components, etc.

[1] https://wavekit.app/

Re: We replaced our React front end with Go and WebAssembly

#215

Post by XCSme »

gloosx wrote: post #165

>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for; After going though demo a bit, I can see this is what they wanted to say here: we have a team of strong Go engineers who are not that strong when it comes to web frontend, the smells of it are everywhere. The signup page don't fit in the screen and have empty scrollable space around it. Ev…

> a complex UI that TypeScript/React didn't scale well for

You can go a long way with render optimizing on the web. Even some basic virtualization should allow for showing millions of log entries. Or, you could still use web technologies (OffscreenCanvas), a bit weird to go directly with WebAssembly.

Re: We replaced our React front end with Go and WebAssembly

#216

Post by pier25 »

onion2k wrote: post #44
pier25 wrote: post #20

WASM makes sense for certain niche use cases but it's really absurd just to make a regular web app. This is an app made with go-app and it loads 3.6MB of WASM code for a simple media player. https://lofimusic.app/collegemusic It's not much different for Blazor. Even for a simple app you're looking at an initial load of at least +1MB.

People get really hung up on page weight. It's nice when an app loads fast with a cold cache, but if it's something that you load once and then keep open, or it's something that's easily cached for a long time after the first visit, page weight is much less of a worry for most users. Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to…

I'm not arguing about page weight per se. The more code you have to download, parse, and run, the more CPU and memory and battery you'll be using.

WASM enables certain use cases like using FFMPEG in the a browser or game engines running on canvas which are super cool. But for 99.99% of DOM related functionality, JS is really the way to go.

Edit:

Here's another example. Loads and executes like 10MB of WASM code for something that could be done in 100kB of JavaScript.

https://stalcrafthq.com/

Re: We replaced our React front end with Go and WebAssembly

#217

Post by hnlurker22 »

zero_shift wrote: post #208
hnlurker22 wrote: post #160

Earlier quoted context omitted.

It simply means that, for their purposes, React wasn't good enough. Personally, I applaud any effort that doesn't use React.

> Personally, I applaud any effort that doesn't use React. Why?

There needs to be competition

Re: We replaced our React front end with Go and WebAssembly

#218

Post by pier25 »

Muromec wrote: post #62
onion2k wrote: post #44

Earlier quoted context omitted.

People get really hung up on page weight. It's nice when an app loads fast with a cold cache, but if it's something that you load once and then keep open, or it's something that's easily cached for a long time after the first visit, page weight is much less of a worry for most users. Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to…

The problem with wasm is also not having a straightforward way to load the thing in chunks. I think the right way to do it for frontend is running small isolated apps that communicate with each other through channels or actor model or what not.

I believe Blazor can load chunks of WASM.

Open the network tab on this Blazor app (not mine).

https://stalcrafthq.com/

(you need to delete the app data in the Application tab of Chrome for the WASM files to reload)

Re: We replaced our React front end with Go and WebAssembly

#219

Post by taurknaut »

Aeolun wrote: post #53
hansonkd wrote: post #48

Earlier quoted context omitted.

Hard disagree. Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both. Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chan…

> Almost never have a met a person who was equally good at both. Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it. The thing is, you need an actually senior engineer for th…

> I’ve definitely met people that were equally competent at both

Tbh this is a meaningless statement. How on earth is any sane person supposed to compare competencies?

I both describe myself as full-stack and associate with other people who do the same. There isn't a single person among us who would try to pitch ourselves as equally competent on the front end and the back end. Who would do this? Why? To what end? This simply ignores why people actually use the term "full stack": to indicate willingness to take on work, not competency.

Re: We replaced our React front end with Go and WebAssembly

#220

Post by Muromec »

pier25 wrote: post #218
Muromec wrote: post #62

Earlier quoted context omitted.

The problem with wasm is also not having a straightforward way to load the thing in chunks. I think the right way to do it for frontend is running small isolated apps that communicate with each other through channels or actor model or what not.

I believe Blazor can load chunks of WASM. Open the network tab on this Blazor app (not mine). https://stalcrafthq.com/ (you need to delete the app data in the Application tab of Chrome for the WASM files to reload)

You certainly can have multiple wasm apps on the same page and you can also implement you own runtime linker. It's just not the wasm thing. I don't know which one blazer is doing because I won't sit there and reverse engineer it npw.
Post reply on HN