Live data from Hacker News

We replaced our React front end with Go and WebAssembly

dagger.io

11–20 of 242 posts

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

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

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

#12

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…

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

I’d be more worried about a developer who doesn’t have the versatility to pick up something new. Because they probably also haven’t invested the time and effort to really understand what they’ve worked on in the past.

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

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

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

#15

Earlier quoted context omitted.

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…

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

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

#18

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…

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 before the introduction of Runes that often led to deadend packages or solutions that resulted in odd performance.

I'm sure eventually it'll be resolved, but ultimately I would only recommend people sticking to more traditional languages and frameworks that have been around for many years now and are relatively unchanging in order to benefit from chatGPT. Basically, the more projects you find using that thing on github, the better your outcome is going to be with current LLMs.

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

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

Post reply on HN