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

171–180 of 242 posts

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

#171

Post by mckravchyk »

hansonkd wrote: post #48
hn_throwaway_99 wrote: post #14

Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams. I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in ou…

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…

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

I would not be surprised if in 10 years from now, there will only be full stack web developers.

I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.

Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...

Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.

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

#172

Post by iforgot22 »

mostertoaster wrote: post #10
PebblesHD wrote: post #5

Would be interesting to see a follow up in a few months on whether the tradeoff from a heavier but widely used stack to a possibly more performant but certainly more esoteric one works out positively. I can’t imagine trying to hire for a front end developer to work on something like this is that easy compared with finding a react dev.

Do you think maybe this is less of a big deal in the brave new world of chatGPT. I know I have zero worries about having to code in a new language or framework with the ability to get answers so quickly to my dumb questions, but maybe that is because I’m still choosing languages and frameworks that are fairly popular and have so much online documentation that the LLMs know about them, and if something is really esote…

An LLM makes it even more beneficial to use popular tooling, because it's going to be better at answering questions about it. Meanwhile it's basically useless for whatever I'm doing at work with internal tools unless I have a pure language question (which for C++ is still ehh).

Maybe this is what will get people to stop reinventing wheels.

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

#173

Post by ahoka »

iforgot22 wrote: post #166
tazjin wrote: post #102

Earlier quoted context omitted.

Well, for one, you need the whole Go runtime.

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.

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

#174

Post by iforgot22 »

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.

Didn't expect that, but not very surprised. So short of the browser giving the Go runtime some special treatment, this sounds like a no-go.

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

#175

Post by saila »

0xblinq wrote: post #117

Not much to see here. Just backend developers hating on JavaScript and looking for workarounds to avoid it that will come back and bite in the neck the poor souls that will have to pick up the project after the current Go devs leave.

I've been writing client-side JS/TS for many years and still enjoy it, but there are scenarios—quite a few in my opinion—where targeting WASM is a better technical and business choice. It's just a "right tool for the job" kind of thing.

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

#176

Post by pwdisswordfishz »

politelemon wrote: post #159
pwdisswordfishz wrote: post #153

Earlier quoted context omitted.

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

It's not allowed to disbelieve someone's claims, especially given evidence to the contrary?

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

#177

Post by Muromec »

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"?

Disagreement on values, especially coupled with outright dismissal falls into the hate category for me.

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

#178

Post by Muromec »

bdelmas wrote: post #164
Muromec wrote: post #146

Earlier quoted context omitted.

The adults would make a quarterly plan, schedule 16 hours of meeting each week, 4x the head count and put everyone into a silo. And then nothing gets done except next quarter.

Is it? What if instead it was another “We did a full rewrite and it was a mistake. Here is why” type of postmortem?

I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.

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

#179

Post by Muromec »

iforgot22 wrote: post #166
tazjin wrote: post #102

Earlier quoted context omitted.

Well, for one, you need the whole Go runtime.

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

You can't have dymanic linking of two C-like libraries compiled to wasm, because you would not be able to pass pointers around. Basically everything you compile to wasm becomes static binary which needs some bitfiddling to interact with.

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

#180

Post by pjmlp »

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…

Definitely, if there as a gold lesson I had with WebForms and JSF, was that frameworks that abstract the way that browser APIs work, without debugging tool for those additional cake layers are not what I want to spend my time on, unless I am told that is the way by higher ups.
Post reply on HN