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

61–70 of 242 posts

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

#61

Post by hansonkd »

golergka wrote: post #54
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…

> 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. So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boos…

> So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost.

Its a short term productivity boost sacrificing for long term maintainability and future productivity.

I would take 1 backend engineer + 1 frontend engineer over 3-4 "fullstack engineers" any day of the week.

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

#62

Post by Muromec »

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…

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.

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

#63

Post by rvz »

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'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 our case it was).

Absolutely bad advice and totally disagree.

So having a language such as TypeScript which is already built on top of an even more immature language such as Javascript in critical systems software or highly regulated settings is a good idea?

Having it on the backend is also bad enough, but everywhere really an indication of not being able to adapt into using a properly designed language for the specific use-case and just being inflexible because you are 'used to the language'.

This is not even talking about the entire TS/JS ecosystem which is has a sea of libraries which most of them are also immature and not production-grade at all.

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

#64

Post by mplewis »

cianuro_ wrote: post #22
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…

IME, the productivity promise falls short. I have found major gains following an integrated framework over multiple code bases with the same language. With the setup you described I just felt I had to write more, even if it was in the same language.

Perhaps use an integrated framework with one codebase then? RedwoodJS is one of these.

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

#65

Post by Muromec »

sunaookami wrote: post #50
nonchalantsui wrote: post #18

Earlier quoted context omitted.

Due to the restrictions (short term at least) when it comes to training data and availability of documentation, I believe coding in a new language or framework becomes an even bigger mountain than usual due to chatGPT providing misleading information. This is made worse if there are breaking changes in a new release that you are using. Even when the thing is popular, like Svelte, it was giving me outdated information…

Maybe JS devs will learn to stop reinventing the wheel every half a year thanks to the knowledge cutoffs.

No. JavaScript is a mid-level developer’s heaven — everyone has a right to framework

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

#66

Post by runarberg »

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…

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 to deliver a good UX.

On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.

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

#67

Post by valenterry »

have-a-break wrote: post #51
teg4n_ wrote: post #40

Earlier quoted context omitted.

Kotlin is not simple. it has like every language feature in existence

Why do people always mention kotlin, but not Scala? Scala is more similar to traditional Java while letting functional programming shine.

Scala is way superb for concurrency than what Go or Kotlin have to offer. But it is a complex language with a high learning curve.

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

#68

Post by Muromec »

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.

I never imagined I would say I miss flash. Flash somehow worked while loading.

We don’t just reinvent the wheel, we forget to reinvent airbags and all nice stuff too

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

#69

Post by MarkMarine »

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.

Kotlin’s structured concurrency and coroutines as a library are remarkable pieces of software engineering. It’s a great language and ecosystem… but

Modern java has been grabbing features from all the “better Java” languages at such a pace that the big gap right now that I see is the question mark operator.

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

#70

Post by hansonkd »

tobinfekkes wrote: post #60
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. 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…

perhaps you are the exception that proves the rule :shrug: or perhaps its hard to objectively measure one's owns abilities. which is the most common thing i have seen from "full stack" interviewees.
Post reply on HN