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

121–130 of 242 posts

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

#121

Post by baq »

moron4hire wrote: post #25
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…

I disagree. I don't think it's too much to ask of software developers to be the bare minimum of competent enough to wire up a basic web service in whatever language they are dealing. REST is not complex.

Over the past two decades I’ve seen a well implemented RESTful API exactly once, in a relatively small project. The rest of REST apis are ad-hoc RPC over HTTP, I’d argue because it isn’t complex and complexity moves to the client.

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

#122

Post by hedora »

dtquad wrote: post #23
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…

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.

Typescript’s concurrency story is much stronger than go’s.

Unlike Go, but like Rust, it has a reasonable type system, and is data race free (since JS is single threaded).

Anyway, I come from a C++/Rust background, but have been using TS recently, and it’s a much nicer language than I’d have guessed.

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

#123

Post by emseetech »

taurknaut wrote: post #108
emseetech wrote: post #86

Earlier quoted context omitted.

A true fullstack developer is a jack of all trades. The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one ." A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack. But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, ea…

The second part of that adage was added on I believe centuries after the attestation of the first part. It's still a nice saying, of course. I think there's a third part to the phrase but I can't remember it for the life of me.

That's true, but the original phrase was from the 1500's so added centuries later could still mean centuries of usage.

It's important to not see any iteration of the phrase as either praise or insult. There is nothing wrong with being a specialist or a generalist, only that there are uses for both.

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

#124

Post by aledalgrande »

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.

Figma is much more than that and lots of people use it daily

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

#125

Post by neonsunset »

mmgutz wrote: post #16

So, this is similar to .NET's Blazor. The same issues apply. Startup should be faster for Go's smaller runtime.

Wait until Blazor switches from Mono-WASM to NativeAOT-LLVM. There will be zero chance for Go to compete :)

AFAIK It can also do SSR, SSG and hybrid rendering, I keep being skeptical on Blazor but everyone I know who tries it out keeps signing it praises so...we'll see how it goes.

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

#126

Post by 8note »

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…

backend engineering is really straightforward nowadays. same as frontend, its mostly knowing a couple tricks about how to format data. mostly is language agnostic api calls of some kind and you can have minimal transformation code over some fully managed platform. typescript seems to be one of the more supported transpilation tools.

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

#128

Post by EVa5I7bHFq9mnYK »

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…

JS can serve API all the same as Python, and faster in most cases.

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

#129

Post by xlii »

hansonkd wrote: post #90
leetrout wrote: post #77

Earlier quoted context omitted.

What is the sacrifice, specifically?

Same reason you hire an architect, electricians, carpenters and plumbers to build a house instead of getting an equal number of handymen and telling them to get at it. Thats not to say a layperson can't build a house, but having experience and training about a specific domain can make later modifications and updates significantly easier.

I find this comparison overly simplistic.

You don’t get back to architect when you’re doing plumbing. You don’t get back to plumbing when doing electricity.

And not only those are often highly isolated tasks but those domain have specialist in it as well. You might go to electrician who can do high voltage installations and you don’t care because he can to general wiring too (thus being full stack).

But there’s different about sacrifice that’s bigger issue. In software engineering handoff costs can be absurdly high. Teams can be allocated and if backend team misses on deliver the next window of opportunity can be in couple weeks. In micro, highly agile teams it’s yeah whatever, but I’ve yet to see a dedicated team of frontend/backend that’s on standby for the other party.

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

#130

Post by 8note »

smarkov wrote: post #57
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…

I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.

moreso, you cant share promise chains or streams well across api boundaries, so it isnt seamless, even in the same language
Post reply on HN