I was excited to try it out but the necessity of using either GH or Google SSO is a bit of a turn off.
Everyone wants your data.
We replaced our React front end with Go and WebAssembly
101–110 of 242 posts
Re: We replaced our React front end with Go and WebAssembly
#102Go 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?
Well, for one, you need the whole Go runtime.
Re: We replaced our React front end with Go and WebAssembly
#103Earlier quoted context omitted.
These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design. On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers…
They’re definitely not totally different, it’s still programming. I’m competent in both and have occupied both roles in my career, but more importantly I’ve worked with people much better than me in both areas :) They were more similar than they were different. I do agree with you that there are skills specific to each layer of the stack and they don’t all cross apply. You definitely don’t get to be good at backend a…
Carpentry and cabinetry are both wood working as well, and both professions have somewhat of an overlapping tool set. However the professions are still very different, and being good at one will not make you good at the other. A good carpenter will have to learn a whole new skill set if they want to be a good cabinet maker.
Re: We replaced our React front end with Go and WebAssembly
#104Go 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?
Probably that Go has to ship heavier runtime (with its own GC etc)
Re: We replaced our React front end with Go and WebAssembly
#105Earlier 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…
> 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’ve definitely met people that were equally competent at both
This is somewhat silly because there's no good way to compare backend and frontend abilities. And why would you! A full stack engineer indicates willingness to tackle both sides, no equivalent competancy.
Re: We replaced our React front end with Go and WebAssembly
#106Will 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…
I also think having one language can be a detriment at times. The JavaScript that you write on the server is so different than that on a browser. Same with Clojure/ClojureScript. This idea that everything is in one language so everything is understandable to everyone just isn’t true in my experience. It’s more like trying to learn to speak Brazilian and European Portuguese at the same time
There is something to be said about language _pairings_ though. I was building with a Python backend and ClojureScript front end for about 8 months and it. was. [expletive]. miserable. The context switch between the two languages was insane.
I rewrote the backend to Elixir and the problem completely went away. No more context switching. Elixir is amazing at what it does. ClojureScript is amazing for UIs and state management. Everything is functional and immutable.
That being said, I do occasionally wish the data validation could be written in one language and used on both places. But that’s just the engineer in me - in practice I have had 0 data validation mismatch errors
Re: We replaced our React front end with Go and WebAssembly
#107Earlier quoted context omitted.
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.
A true fullstack developer is a jack of all trades. The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one ." A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack. But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, ea…
I think it depends 100% on the person.
I’ve met people who haven’t solved a partial differential equation in 10 years and still remember how to do it whereas some people barely remember the library they used last week and have to keep a mountain of notes.
The people in the former camp have a lot of very deep knowledge on a lot of things.
Re: We replaced our React front end with Go and WebAssembly
#108Earlier quoted context omitted.
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.
A true fullstack developer is a jack of all trades. The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one ." A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack. But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, ea…
The second part of that adage was added on I believe centuries after the attestation of the first part. It's still a nice saying, of course. I think there's a third part to the phrase but I can't remember it for the life of me.
Re: We replaced our React front end with Go and WebAssembly
#109> 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
Headless stuff died in the sense that it got integrated into the mainstream ecosystem and people stopped buzzing about it.
Re: We replaced our React front end with Go and WebAssembly
#110Earlier 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…
These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design. On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers…
It really depends on the product (or feature) how much of that expertise is necessary. You need some domain experts for sure who really know the ins and outs of the specific backend and frontend technologies to architect the overall app and build system, and do the hardcore stuff like optimization that you mention.
But fullstack engineering is just much more individually productive, if you're updating a settings page why involve multiple engineers and coordinate a handoff, when one engineer can just add the API calls on the backend and add the new toggles to the frontend in a single day? Most software doesn't need to be beautifully polished and completely excellent.
Anyway I personally just find it fun, I get to breathe life to a vision end-to-end and tackle a wide variety of problems, and I can deliver quickly. Even if I'll never be (and don't desire to be) a super expert in one technology.