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

111–120 of 242 posts

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

#111

Post by runarberg »

re-thc wrote: post #89
runarberg wrote: post #66

Earlier quoted context omitted.

These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design. On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers…

> On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure I hope the same applies for frontend. Let's not have the 20MB bundles (definitely exists) and seconds before a page loads etc. > which I don‘t even know about Security!

> Security!

This is why no-one should hire me as a backend developer ;)

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

#112

Post by whitehexagon »

notpushkin wrote: post #11

I was slightly worried it would be one of those “render to canvas” frameworks (which are an accessibility nightmare and are ever so slightly broken), but that’s not the case here! Looks like WASM – DOM interop is finally fast enough for this to work. 32 MB binary is a big no-no though.

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 for canvas 2D/3D or even DOM. It would be nice to ditch the JS bits, and I suspect the compositors all-the-way down are probably hitting my 2D performance.

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

#113

Post by neonsunset »

jilles wrote: post #26
dtquad wrote: post #23

Earlier quoted context omitted.

Definitely. Although Go is the simplest language with sane/good concurrency support so it's a good fit for Node.js/TS and Python shops that have run into a use case where they feel limited by their main language or runtime and need a concurrent backend service to implement a feature.

Kotlin also has amazing concurrency support. Plus you get the additional benefit of the entire Java ecosystem. I wish it got more love.

> I wish it got more love.

.NET is in the same predicament. Very convenient and highly efficient concurrency primitives.

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

#115

Post by bb88 »

nesarkvechnep wrote: post #88
tobinfekkes wrote: post #60

Earlier quoted context omitted.

> Almost never have a met a person who was equally good at both. I am literally that person. It's a good thing we've never met, or you wouldn't be able to say that anymore! Edit: Sorry for sharing my professional responsibilities, where some of my clients pay me for front-end work, some for back-end work, and some for both. I forgot that people on the internet that have never met me know what I do better than I do, a…

Or, you just think you’re literally that person. No offence, I’ve met my fair share of developers who are full of themselves but are barely tolerable at best.

The devs who don't ooze ego over all of their code and just let their code speak for itself are often the best developers.

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

#116

Post by J_Shelby_J »

whitehexagon wrote: post #112
notpushkin wrote: post #11

I was slightly worried it would be one of those “render to canvas” frameworks (which are an accessibility nightmare and are ever so slightly broken), but that’s not the case here! Looks like WASM – DOM interop is finally fast enough for this to work. 32 MB binary is a big no-no though.

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 swear, some people hate rust as much as the comment sections claim rust people are fanatics

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

#118

Post by hn_throwaway_99 »

hansonkd wrote: post #76
hn_throwaway_99 wrote: post #73

Earlier quoted context omitted.

In my experience, I've seen no benefits (and sizable downsides) to using Python on the backend when the front end is React vs. using Node. There are tons of robust API frameworks for Node, a huge ecosystem, etc. So with Node and Python it's more potayto-potahto, and if that's the case, there are benefits to having everything in Typescript for standard server/client cases. Note I'm not saying do this everywhere if the…

TBH the hardest thing for a long time about Node backend engineers isn't that there isn't great frameworks but a lot of times people choose node for the above use case. So developers who write Node backends were some breed of frontend people who chose node because they didn't want to learn another language as opposed to learning the language because it was the best tool for the job. Anyways recently the typescript ba…

Yeah, I agree with that. When I first saw the title on the article I thought "ergh...", because while I think Go is a fine language that really excels in some contexts, the number of developers who are familiar with "Go for the front end" is vanishingly small. My initial distaste was tempered by the fact that I thought they at least had a good reason for wanting to eliminate "need to code twice" for their different front ends.

FWIW I was a primarily a Java server developer for the first ~15 years of my career, then switched to Node and really loved it. It was at that point that I fell into the benefits of my "Typescript everywhere" mantra because it solved so many problems I had seen with the common setup of Java on the backend and Javascript with the rise of SPAs on the front end.

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

#119

Post by omcnoe »

braindeadly wrote: post #31

From the webpage: "Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture changes and the creation of a “smart backend” for incremental data loading over WebSockets, using Go's rarely-used encoding/gob format." From https://pkg.go.dev/encoding/gob "This package is not designed to be hardened against adversarial inputs, and is outside the scope of https://go.dev/security/policy . In parti…

It's not completely clear from the link but it seems like they are only using encoding/gob for backend -> client transmission over the websocket. In which case, it's your own backend, it is a trusted source. But the risk is that if there is any data going the other direction over the websocket in encoding/gob format. Probably best to just avoid completely.

Go JSON parsing isn't just slow in WASM, it's slow in native code also. I've never dug into why though, surely there are some big cost savings if this were to be optimized?

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

#120

Post by kabes »

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 programming.

Post reply on HN