32 MB binary is a big no-no though.
We replaced our React front end with Go and WebAssembly
11–20 of 242 posts
Re: We replaced our React front end with Go and WebAssembly
#12Would 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…
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
#13Re: We replaced our React front end with Go and WebAssembly
#14I'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
#15Earlier 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…
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
#16Re: We replaced our React front end with Go and WebAssembly
#17Is there a video of this ui??
Re: We replaced our React front end with Go and WebAssembly
#18Would 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…
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
#19Re: We replaced our React front end with Go and WebAssembly
#20This 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.