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

181–190 of 242 posts

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

#181

Post by pjmlp »

jillesvangurp wrote: post #162
panstromek wrote: post #104

Earlier quoted context omitted.

Probably that Go has to ship heavier runtime (with its own GC etc)

Probably that. Kotlin waited until wasm GC was available and now has a compiler that relies on that. Kotlin wasm binaries can be pretty small depending on what libraries you use. Probably a bit of work but there should be no reason why Go would not be able to do the same at this point.

.NET is still not using WASM GC for Blazor, because it doesn't support all the use cases in .NET runtime, that is the thing wiht having a single GC implementation for everyone.

People tend to think all GC are the same, they are not.

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

#182

Post by iforgot22 »

Muromec wrote: post #179
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?

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.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

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

#183

Post by pjmlp »

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…

In the brave new world of chatGPT, developers will be in for a shock once they get good enough to generate executables.

It will be like looking for a job as Assembly programmer, when everyone else has moved into high level programming languages.

Better improve those architecture design and social skills.

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

#184

Post by pjmlp »

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…

As backend developer/devops that dabbles in (Web) frontend, I am fully spot on the point of view.

The only kind of frontend I could equally consider myself good, are native frontends on Apple and Microsoft platforms, but that is because native GUIs do most of the UI work and don't require CSS wizardy skills to turn divs into drop down boxes with type-ahead search.

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

#185

Post by kubb »

gloosx wrote: post #165

>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for; After going though demo a bit, I can see this is what they wanted to say here: we have a team of strong Go engineers who are not that strong when it comes to web frontend, the smells of it are everywhere. The signup page don't fit in the screen and have empty scrollable space around it. Ev…

I can hear these Gophers in the meeting complaining how TypeScript is „completely unreadable”.

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

#186

Post by gf000 »

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…

If anything, LLMs require "boring tech" much more so than people.

Sure, it may know the language, but God save us from all the hallucinating in case of some niche lib

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

#187

Post by JoeyJoJoJr »

hn_throwaway_99 wrote: post #118
hansonkd wrote: post #76

Earlier quoted context omitted.

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 f…

On my company’s latest project we are using Spring Boot on the backend with Typescript and React on the front-end. We are using Swagger for API specs which means we can generate type safe Typescript code for the front-end, including schemas for Zod and Tanstack query functions. With this codegen I can’t see many benefits to using Typescript on the backend, although the project is a rather standard CRUD app. I can understand why you might not want to use Java, but surely there are better backend choices than Java or Node?

I am curious - could you explain how you are benefiting from using Typescript on both back and front end?

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

#188

Post by gf000 »

brokencode wrote: post #152
PebblesHD wrote: post #15

Earlier quoted context omitted.

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, e…

I wouldn't say that web dev is "hard" as in any part would need a very deep knowledge, but it sure as hell very wide.

There are so many things and concepts, multiple must-know languages, browser quirks, some networking knowledge, CORS, etc. If you do use an "industry-strength" backend framework then the complexity surely drops, e.g. it will handle injections and stuff, but not having heard at least a bit about what your framework does for you, and reinventing the wheel can go really bad really fast.

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

#189

Post by gf000 »

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.

React was released 11 years ago and is the de facto default choice for most of the web applications.

They have definitely chilled out on "reinventing the wheel" quite a few years ago.

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

#190

Post by Muromec »

iforgot22 wrote: post #182
Muromec wrote: post #179

Earlier quoted context omitted.

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.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

It's more of a go problem than the wasm problem. Don't bundle such a big runtime and pass memory pointers around and you can have nice things.

Something beam-hosted with zero pointer sharing between nodes and smaller runtime maps to wasm much better.

Post reply on HN