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

151–160 of 242 posts

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

#151

Post by hn_throwaway_99 »

xmprt wrote: post #75
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…

I think you feel that way because you're comparing Node to Python. Neither of them are particularly good languages for servers. Languages like Go and Java/Kotlin are much better when you're building complicated systems that need to be performant and reliable.

Hard disagree on Node (at least if you're using Typescript) not being a good server language, and I say this as someone who was a Java dev for the first 15 years of my career. I've seen more performance nightmares with Java compared to a well-written Node server, though Java has improved a ton in recent years with things like virtual threads and the community has generally seen the error of the unnecessary AbstractFactoryBuilderGenerator shit that was so common for a long time in Java.

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

#152

Post by brokencode »

PebblesHD wrote: post #15
brokencode wrote: post #12

Earlier quoted context omitted.

I think companies are way too worried about hiring developers based on their specific technology they’ve previously worked with. Unless maybe you are doing something radically different, like web development to graphics drivers or something. Development skills are typically very transferable between languages, libraries, etc. And I think it’s healthy for developers to branch out and try new tech stacks from time to t…

Your example of web devs writing drivers is why I posed the question, as go is very much not a widely used web dev language, and the devs who know go may not at all understand the common web development patterns and practices. Rather than the specific language, I’m more thinking of the domain, meaning ‘web devs who know go’ being a smaller cohort than ‘webdevs who know react’.

I think it’s better to have somebody who has a deep understanding of all layers of the application rather than only one part.

If a developer is already an expert in the back end using Go, then great. Maybe they’ll bring a different perspective when they work on the front end. And they will probably enjoy a new challenge.

Web development is not so hard that a good developer can’t learn the basics in a couple months, especially with some mentoring.

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

#153

Post by pwdisswordfishz »

Muromec wrote: post #138
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…

It sounds like people having fun, which means they would care more and ship faster if it works out. If it doesn't work out, they will do something boring. Why hate on people actually enjoying the thing at times when everyone with the boring stack is one round of layoff away from the door?

Why call every little disagreement and pointing out of inconsistency "hate"?

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

#154

Post by panstromek »

fragmede wrote: post #141
panstromek wrote: post #131

This is pretty interesting. I have some questions. Since I don't know the product, I don't understand why doing all of this data crunching on the frontend. Seems like the same motivation could be applied to moving more of the heavy work to the backend before sending results to the frontend. Making the app more of a thin client. Am I missing something, is there a reason to keeping the work on FE?

Cost. To take it to an extreme, you could render everything on the back end and stream video, like GeForce Now or Stadia, but in doing so, the backend needs to be quite beefy. As clients these days usually have some modicum of processing power, doing it on the front end so you're not also playing for an extra fleet of VMs on the backend saves money and increases revenue. At a high level, you want the line for revenue…

That doesn't seem to be the case here - they already mentioned that the data is heavy, which means they have to send a huge amount of data over the network, only to crunch it down and show a subset of it (I don't think the UI shows all of that data at once). This seems more costly than sending some UI updates over the wire, for example.

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

#155

Post by theanonymousone »

kolanos wrote: post #27
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.

Looks like it was compressed to 4MB, but still.

Coincidentally, I just checked the LinkedIn page of a colleague, and Vivaldi said it was loading ~30MB of data for that.

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

#156

Post by jusssi »

xmprt wrote: post #74
Aeolun wrote: post #53

Earlier quoted context omitted.

> 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 think a lot of frontend engineers can do backend work and vice versa, but it takes a lot to be very good at both. It's not impossible but also I think it's rare that a backend engineer would voluntarily decide to also become a frontend expert instead of leveling up their backend skills. Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.

Most of the time being very good doesn't matter, when you're thrown into a process that's designed to extract mediocre work out of everyone, regardless of how good they are.

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

#157

Post by notpushkin »

golergka wrote: post #59
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.

Not a fan of this bundle size, but it's not a web store landing page — it's a professional application, and it's users are likely to use it extensively through their day, and all hundreds of navigation events and new tabs will (if handled correctly) hit the same cached bundle.

It’s a good point, but keep in mind that’s 32 MB of code: you can cache it, but you still have to parse and initialize it for every tab. (It might not be as bad as it sounds, WASM is lighter in this aspect than JS; but it’s still a good proxy for startup performance IMO.)

It should work well for applications with longer session size, like Figma: you open a project one time and work on it for hours. I’m not sure if that’s the case with Dagger Cloud: you might be looking at a single trace, or compare dozens of builds throughout the day. The post only claims “better overall performance and lower memory usage”, but without any numbers it’s hard to tell anything.

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

#158

Post by notpushkin »

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’ve been looking at Zig for some time, too. Perhaps I should give it a go!

Any particular tricks on making bridged DOM fast?

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

#159

Post by politelemon »

pwdisswordfishz wrote: post #153
Muromec wrote: post #138

Earlier quoted context omitted.

It sounds like people having fun, which means they would care more and ship faster if it works out. If it doesn't work out, they will do something boring. Why hate on people actually enjoying the thing at times when everyone with the boring stack is one round of layoff away from the door?

Why call every little disagreement and pointing out of inconsistency "hate"?

The comment in GP is not a 'disagreement', it is just bad faith.

"Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming."

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

#160

Post by hnlurker22 »

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…

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