We replaced our React front end with Go and WebAssembly • Hacker News Board

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

#91

Post by nesarkvechnep » Tue, Feb 11, 2025, 6:01 AM UTC

meandmycode wrote: post #37

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…

This was my view once, but practically the languages have their own ecosystem strengths, now I think most of the major languages have similar concepts, async await, etc.. instead we now teach transfer your skills, and tbh I think it makes for a more interesting culture that's adoptive and excited by tech, and also learns better

It’s called being a software developer instead of being a JavaScript developer. If someone knows how to engineer software, their skills are transferable. Stitching libraries together is usually not software engineering.

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

#92

Post by evantbyrne » Tue, Feb 11, 2025, 6:01 AM UTC

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…

It's kind of funny to me how derided full stack developers are as unskilled generalists. It would have been unthinkable back when I started web development to only learn half of what it takes to build a website.

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

#93

Post by satvikpendem » Tue, Feb 11, 2025, 6:01 AM UTC

ucirello wrote: post #56

bitbasher wrote: post #29

Go isn't a very good fit for this kind of thing. I've done it with Rust (Leptos, Dioxus, etc). The wasm binaries are a lot more sane when using Rust. On average, my wasm binary was around 240kb and it compresses really well over the wire.

Why not Zig?

Why not Rust? Zig does not have nearly the same memory guarantees as Rust, I mean, why create a new language and still make the same fundamental errors when we've fixed them in other languages. That's also how I feel about Go and its lack of algebraic data types.

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

#94

Post by 4hg4ufxhy » Tue, Feb 11, 2025, 6:02 AM UTC

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.

I'd imagine it's more common that a frontend dev moves to backend dev role.

From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.

Also they tend to have very good API design skills, since they understand both sides intimately.

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

#95

Post by satvikpendem » Tue, Feb 11, 2025, 6:03 AM UTC

benatkin wrote: post #35

yieldcrv wrote: post #3

> a complex UI that TypeScript/React didn't scale well for why do I have the feeling that virtual tables on tanstack would have solved their use case using typescript/react

Tanstack is supposed to be about headless UIs right? Didn't that trend kind of die down? It doesn't seem to hit a sweet spot between something prebuilt and something custom. I took a look this and tried reading several and it seems all right, but not especially interesting: https://github.com/TanStack/table/tree/main/examples/react

Died down? In what sense?

It's a low level table implementation, it's not supposed to be that sweet spot, there are many other table libraries, often written in top of TanStack table, like AG Grid.

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

#96

Post by satvikpendem » Tue, Feb 11, 2025, 6:04 AM UTC

simonw wrote: post #41

Is it even possible to make this combination screenreader accessible? I guess there may be a way to do that using a parallel DOM structure that exists to give the screenreader something to hook into, but at that point it's probably easier to go back to using HTML.

It is HTML, it uses WASM to DOM bindings. That being said, Flutter does have screen reader accessibility, if you look at their docs.

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

#97

Post by potamic » Tue, Feb 11, 2025, 6:04 AM UTC

bitbasher wrote: post #29

Go isn't a very good fit for this kind of thing. I've done it with Rust (Leptos, Dioxus, etc). The wasm binaries are a lot more sane when using Rust. On average, my wasm binary was around 240kb and it compresses really well over the wire.

What about Go causes large binaries?

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

#98

Post by panstromek » Tue, Feb 11, 2025, 6:04 AM UTC

rvz wrote: post #63

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

Sounds like a straw man to me

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

#99

Post by komali2 » Tue, Feb 11, 2025, 6:06 AM UTC

hn_throwaway_99 wrote: post #73

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…

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…

What are the downsides? Benefits are if you use something that uses Pydantic models (say, fastapi + sqlalchemy) for example you seem to be able to get more granular control over DB types than, in my recent experience anyway, we had using Prisma / Nextjs.

We switched over, have fastapi generate an openapi.json, then use Kubb to have it auto-generate typescript types (it can also do zod models), done.

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

#100

Post by taurknaut » Tue, Feb 11, 2025, 6:07 AM UTC

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…

> 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 never interpreted Full Stack to mean homogenous competency, which is a rather strange concept if you think of it.