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

31–40 of 242 posts

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

#31

Post by braindeadly »

From the webpage:

"Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture changes and the creation of a “smart backend” for incremental data loading over WebSockets, using Go's rarely-used encoding/gob format."

From https://pkg.go.dev/encoding/gob

"This package is not designed to be hardened against adversarial inputs, and is outside the scope of https://go.dev/security/policy. In particular, the Decoder does only basic sanity checking on decoded input sizes, and its limits are not configurable. Care should be taken when decoding gob data from untrusted sources, which may consume significant resources."

How do they sanitize the gob data?

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

#32

Post by nicoburns »

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.

Yeah, but with most JavaScript frameworks (and even Rust compiled to WASM), 4MB (at most!) would be the size of the uncompressed bundle.

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

#33

Post by TheCapeGreek »

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…

At the least, tools that minimise the usage of certain languages (i.e. JS if you're not a JS shop) or general frontend boilerplate will also do this.

See: Rails Hotwire, Laravel Livewire, Alpine.js

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

#34

Post by temporallobe »

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 is why Rails is a decent solution for many apps. It’s “Ruby everywhere” including the data layer.

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

#35

Post by benatkin »

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

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

#36

Post by brunoqc »

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…

Gleam might be a good fit for that.

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

#37

Post by meandmycode »

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

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

#38

Post by xboxnolifes »

PebblesHD wrote: post #15
brokencode wrote: post #12

Earlier quoted context omitted.

I think companies are way too worried about hiring developers based on their specific technology they’ve previously worked with. Unless maybe you are doing something radically different, like web development to graphics drivers or something. Development skills are typically very transferable between languages, libraries, etc. And I think it’s healthy for developers to branch out and try new tech stacks from time to t…

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

Go is a pretty popular language for web servers, so while "react devs who know go" might be small, "go devs who know react" might have large overlap.

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

#39

Post by onion2k »

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.

REST is not complex.

REST isn't complex, but API design is still hard. Making a strategic choice not to design a service API but to ship the same code in two places is valid, and arguably the right one if that's what the teams skills lend themselves to.

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

#40

Post by teg4n_ »

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 is not simple. it has like every language feature in existence
Post reply on HN