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

191–200 of 242 posts

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

#191

Post by JoeyJoJoJr »

nesarkvechnep wrote: post #88
tobinfekkes wrote: post #60

Earlier quoted context omitted.

> Almost never have a met a person who was equally good at both. I am literally that person. It's a good thing we've never met, or you wouldn't be able to say that anymore! Edit: Sorry for sharing my professional responsibilities, where some of my clients pay me for front-end work, some for back-end work, and some for both. I forgot that people on the internet that have never met me know what I do better than I do, a…

Or, you just think you’re literally that person. No offence, I’ve met my fair share of developers who are full of themselves but are barely tolerable at best.

Well they didn’t say that they are specialist level at both. It could be that they are mid/good level at both, which isn’t a particularly egotistical view to have of oneself. I got the impression that they were highlighting their skillset is more broad than deep, which is basically what you’d expect from a good full-stack developer.

I’ve met a lot of programmers early in my career who were full of themselves, and a number of more experienced ones later in my career that understood their own capabilities very well.

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

#192

Post by WhyNotHugo »

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.

I had the same worry: that they'd be rendering everything into a canvas. It's very neat to see that the WASMDOM interop is there now, and they render actual native elements. Even inspecting the DOM it's quite readable (far easier to read that I've seen React produce).

OTOH, Rust solutions have been pretty disappointing so far; usually relying on macros (which are a pain to write, debug or maintain in any way) and lots of DSLs (which negate the value of any development tools).

The binary size for this approach is a big issue, but assuming that it can be decreased, I'd think that go can end up being a very viable candidate in this space.

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

#194

Post by [deleted] »

J_Shelby_J wrote: post #116
whitehexagon wrote: post #112

Earlier quoted context omitted.

I also struggled with the binary output size of Golang WASM, and that it was growing with each version. Someone recommended TinyGo, and although I haven't needed it for a couple years now, at the time the WASM binary output size was much better. Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough…

i swear, some people hate rust as much as the comment sections claim rust people are fanatics

[deleted]

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

#195

Post by andrewstuart »

>> We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for;

I simply do not believe the "complex UI that TypeScript/React didn't scale well for; "

That's just piffle.

It's them saying they don't know how to use React.

Without much more detail/evidence we must assume this is just a way of excusing themselves for doing something that makes no sense.

Here is a demo I made of React getting plenty of scaling done:

https://static.crowdwave.link/index.html

And the source: https://static.crowdwave.link/sveltetest.zip

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

#196

Post by Aeolun »

runarberg wrote: post #66
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…

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…

By your own admission, you are a front-end developer, so why do you feel qualified to make such a broad, sweeping statement? Just because it feels different now does not mean it will once you’ve spent years working with it. Just the idea that ‘optimization’ and ‘speed’ are a back-end thing…

It’s a very recent thing that these things you describe are even considered related to front and back-end at all. If you go even 7 years back you’d have needed to consider all these as a “back-end” developer.

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

#197

Post by tombl »

potamic wrote: post #97
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?

Go's "nothing is async because everything is async" model, combined with WebAssembly's (current) lack of support for stack switching and arbitrary goto, essentially mean that the compiler needs to insert extra code everywhere to support arbitrarily un/rewinding the stack.

This massively bloats binaries and means that go compiled to wasm is much slower than native speed, significantly more so than than the equivalent slowdown for c/rust.

see https://github.com/golang/go/issues/65440

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

#198

Post by Maxence »

mozey wrote: post #150
Maxence wrote: post #114

Hey, I’m the creator of go-app. What a surprise to come across this post on HN! I’m really happy to see you folks built something that fits your needs with it. Wishing you continued success with your product!

What is the benefit of writing Go to generate HTML? 1. With go-app func (h *hello) Render() app.UI { return app.Div().Body(app.Text(fmt.Sprintf("Hello %s", h.name))) } 2. Compared to using templ templ Hello(name string) { Hello, { name } } For me personally, the latter seems nicer - I can see at a glance the structure of the HTML - Completion on the HTML tags, attributes, etc - Completion on CSS (TailwindCSS LSP for…

In a previous version, I was using HTML, but it was written as strings. This allowed interaction with Go, but debugging was challenging since the Go compiler does not check the content inside strings, and no editor provides syntax highlighting for HTML embedded in a Go string.

With the current approach, the compiler can validate the written code, making it easier to use other Go code and enabling auto-completion in editors since everything is defined in Go.

Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.

The key point here is that the UI can integrate background mechanisms written in Go, making them easy to use within the interface.

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

#200

Post by yieldcrv »

hnlurker22 wrote: post #168
hnlurker22 wrote: post #160

Earlier quoted context omitted.

It simply means that, for their purposes, React wasn't good enough. Personally, I applaud any effort that doesn't use React.

>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for

Because its a bullshit assessment, they ran into the same limitations in their obscure choice, they didn’t move fast and break things, and both choices have optimizations to deal with these problems

and we would all fail system design interviews for considering the same thing

Post reply on HN