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

201–210 of 242 posts

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

#201

Post by mckravchyk »

Maxence wrote: post #198
mozey wrote: post #150

Earlier quoted context omitted.

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 e…

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

That looks really interesting. I'm curious, are there any performance drawbacks to updating DOM via WebAssembly or is it negligible? I.e. let's say you are building an editor of some kind. If the entire app is in Go, that means sending the keydown event to the WASM module and having it update HTML back. Is it not better (from performance perspective) to just use JavaScript all the way?

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

#202

Post by [deleted] »

kubb wrote: post #185
gloosx wrote: post #165

>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; After going though demo a bit, I can see this is what they wanted to say here: we have a team of strong Go engineers who are not that strong when it comes to web frontend, the smells of it are everywhere. The signup page don't fit in the screen and have empty scrollable space around it. Ev…

I can hear these Gophers in the meeting complaining how TypeScript is „completely unreadable”.

[deleted]

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

#203

Post by qvq »

notpushkin wrote: post #158
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’ve been looking at Zig for some time, too. Perhaps I should give it a go! Any particular tricks on making bridged DOM fast?

https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%...

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

#204

Post by kabes »

Muromec wrote: post #178
bdelmas wrote: post #164

Earlier quoted context omitted.

Is it? What if instead it was another “We did a full rewrite and it was a mistake. Here is why” type of postmortem?

I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.

Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo.

But if you claim to be a small team that needs to ship fast, I believe you should just pick the industry standard boring technology and grind away.

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

#205

Post by [deleted] »

hnlurker22 wrote: post #160
kabes wrote: post #120

Early in the post: > As a small team, we need to ship fast. So they chose a solution that required them to: > Spent almost a month prototyping > there was no real ecosystem for Go-app UI components and we knew we’d have to write our own > Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture Not sure what their definition of shipping fast is, since this just sounds like resume oriented…

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

[deleted]

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

#206

Post by brokencode »

gf000 wrote: post #188
brokencode wrote: post #152

Earlier quoted context omitted.

I think it’s better to have somebody who has a deep understanding of all layers of the application rather than only one part. If a developer is already an expert in the back end using Go, then great. Maybe they’ll bring a different perspective when they work on the front end. And they will probably enjoy a new challenge. Web development is not so hard that a good developer can’t learn the basics in a couple months, e…

I wouldn't say that web dev is "hard" as in any part would need a very deep knowledge, but it sure as hell very wide. There are so many things and concepts, multiple must-know languages, browser quirks, some networking knowledge, CORS, etc. If you do use an "industry-strength" backend framework then the complexity surely drops, e.g. it will handle injections and stuff, but not having heard at least a bit about what y…

If you’re trying to build a team from scratch, you probably want to hire devs with relevant experience.

But I think it’s a sign of an unhealthy or immature team if it is unable to onboard and train new developers.

You are right that a new developer could easily make a lot of mistakes, but it is the responsibility of the senior developers on the team to give feedback and review the code of less experienced members.

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

#207

Post by bdelmas »

kabes wrote: post #204
Muromec wrote: post #178

Earlier quoted context omitted.

I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.

Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo. But if you claim to be a small team that needs to ship fast, I believe you should just pick the industry standard boring technology and grind away.

Exactly. People only look at success.

The question is to fully see (and boringly like the parent post was talking about) what are the rewards and the risks to decide if it is worth it or not. What if it made the company tanked financially (like you would have to go back to the state before but have to rewrite the rewrite because you had to change the database design in your first rewrite or something) and not be able to ship for another 6 months? Being a small team you don't have all the cash you want unless you already made it big. Also you have to explain to your investors why you won't ship. And really how come you are an expert in tech when you had to redo it from scratch so next time maybe they can reinvest.

This type of decision needs clear planning, reward and risk, and a real business goal to happen. But let's be real many times it's not the case and X is the new cool tech. I am all about being audacious but in a calculated way.

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

#208

Post by zero_shift »

hnlurker22 wrote: post #160
kabes wrote: post #120

Early in the post: > As a small team, we need to ship fast. So they chose a solution that required them to: > Spent almost a month prototyping > there was no real ecosystem for Go-app UI components and we knew we’d have to write our own > Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture Not sure what their definition of shipping fast is, since this just sounds like resume oriented…

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

> Personally, I applaud any effort that doesn't use React.

Why?

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

#209

Post by Muromec »

bdelmas wrote: post #207
kabes wrote: post #204

Earlier quoted context omitted.

Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo. But if you claim to be a small team that needs to ship fast, I believe you should just pick the industry standard boring technology and grind away.

Exactly. People only look at success. The question is to fully see (and boringly like the parent post was talking about) what are the rewards and the risks to decide if it is worth it or not. What if it made the company tanked financially (like you would have to go back to the state before but have to rewrite the rewrite because you had to change the database design in your first rewrite or something) and not be able…

To me what they did looks exactly that -- being audacious in a calculated way that benefited them.

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

#210

Post by sunaookami »

gf000 wrote: post #189
sunaookami wrote: post #50

Earlier quoted context omitted.

Maybe JS devs will learn to stop reinventing the wheel every half a year thanks to the knowledge cutoffs.

React was released 11 years ago and is the de facto default choice for most of the web applications. They have definitely chilled out on "reinventing the wheel" quite a few years ago.

No? React reinvents itself constantly. I've worked on React websites and am currently working on a React Native app. React was first classes-based, now there's functions, hooks and it will soon get a compiler. Not to mention that they nudge you to use Next.js (and Expo for RN) now. Svelte did the same with the switch to these god awful Runes. Not to mention a lot of libraries that constantly get deprecated or don't work anymore with React 19.
Post reply on HN