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

221–230 of 242 posts

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

#221

Post by groby_b »

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…

I mean, with selective quoting you can make any point you want. Let's do the full quote:

> So, we ended up with two interfaces trying to accomplish the same thing, one of them in one language and ecosystem (TypeScript/React), the other in a totally different language and ecosystem (Go), and we couldn't easily share business logic between them.

> As a small team, we need to ship fast. Having to re-implement every feature twice was just a massive tax on our velocity.

Oh. Wait. They're cutting away an entire code base and a second language & ecosystem to support. Maybe it's not quite as resume-oriented after all.

We can certainly argue if that was the right way to do this, but it's not like it's an entirely unreasonable resume padding exercise.

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

#222

Post by runarberg »

Aeolun wrote: post #196
runarberg wrote: post #66

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

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…

How you optimize for speed, size, and memory are very different between the frontend and the backend. On the frontend the best optimization is quite often to simply let the backend handle it.

For example if the the app is too slow because we are pulling in thousands of records and rendering it to the DOM, the correct optimization is to paginate the results. Both frontend and backend devs should know that. However the frontend dev needs to make the pagination a fluid UX for the user, decide between page controls or infinite scroll, implement search on type, set the correct aria-attributes so assistive technology knows this is an incomplete list, etc. The backend dev however needs to optimize the database queries, decide on the type of pagination (keyset vs. limit-offset vs. cursor etc.) and map the response such that the frontend won’t have to do too much work ones received (I guess a frontend dev should be able to do the latter; but it is hard to ask a frontend dev to be an expert in optimizing database queries; or implement proper keyset pagination [although if the UX team decides on infinite scroll that limits the possible pagination types a little]).

> If you go even 7 years back you’d have needed to consider all these as a “back-end” developer

I have been a frontend dev for almost 15 years, and I very much disagree with you here. I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers (case in point: Intl.PluralRules became widely available 7 years ago).

This may have been true in 2009 when web-apps were fairly simple (often just a series of form submissions), you had a good idea about the screen size of your users, it was hard to mess up accessibility (and yet, many developers did), localization was mostly done on the backend, single page apps were almost unheard of, etc. But not in 2018.

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

#223

Post by kflgkans »

satvikpendem wrote: post #93
ucirello wrote: post #56

Earlier quoted context omitted.

Why not Zig?

Why not Rust? Zig does not have nearly the same memory guarantees as Rust, I mean, why create a new language and still make the same fundamental errors when we've fixed them in other languages. That's also how I feel about Go and its lack of algebraic data types.

Zig is a completely different language than Rust. Memory safety is just one aspect. I personally find Rust to be very difficult to read and can never manage to be productive in it.

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

#224

Post by satvikpendem »

kflgkans wrote: post #223
satvikpendem wrote: post #93

Earlier quoted context omitted.

Why not Rust? Zig does not have nearly the same memory guarantees as Rust, I mean, why create a new language and still make the same fundamental errors when we've fixed them in other languages. That's also how I feel about Go and its lack of algebraic data types.

Zig is a completely different language than Rust. Memory safety is just one aspect. I personally find Rust to be very difficult to read and can never manage to be productive in it.

Lacking memory safety is a fundamental mistake in my opinion, not merely one aspect. We have learned much from the days of C and C++, so much that companies are migrating away and finding that many of their bugs are solved with memory safe languages like Rust.

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

#225

Post by gloosx »

XCSme wrote: post #215
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…

> a complex UI that TypeScript/React didn't scale well for You can go a long way with render optimizing on the web. Even some basic virtualization should allow for showing millions of log entries. Or, you could still use web technologies (OffscreenCanvas), a bit weird to go directly with WebAssembly.

Exactly, it's hard to imagine a UI so complex it would "not scale" in the browser.

Not looking like they are making Concorde cockpit or something.

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

#226

Post by XCSme »

gloosx wrote: post #225
XCSme wrote: post #215

Earlier quoted context omitted.

> a complex UI that TypeScript/React didn't scale well for You can go a long way with render optimizing on the web. Even some basic virtualization should allow for showing millions of log entries. Or, you could still use web technologies (OffscreenCanvas), a bit weird to go directly with WebAssembly.

Exactly, it's hard to imagine a UI so complex it would "not scale" in the browser. Not looking like they are making Concorde cockpit or something.

I mean, the browser itself was made to display complex UI elements, and is optimized for displaying interactive dashboards (at least it tried to in the last 20 years).

Plus, computers are fast enough, if something is somehow still slow, you can still make it seem fast if you add proper transitions and fix the timing of animations and loading order. For example, maybe one log file is 10GB, of course the browser will crash if you try to load all of it in the browser. Simply preload the latest 1000 lines, then use websockets to load new data as the user scrolls. Now, if you scroll first and then load the data, the app will seem slow, the trick is to start loading the data when the scroll already reached 90% of current buffer. Anyway, tricks like this will make any app seem instant, even if things still actually take time to load.

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

#227

Post by gloosx »

XCSme wrote: post #226
gloosx wrote: post #225

Earlier quoted context omitted.

Exactly, it's hard to imagine a UI so complex it would "not scale" in the browser. Not looking like they are making Concorde cockpit or something.

I mean, the browser itself was made to display complex UI elements, and is optimized for displaying interactive dashboards (at least it tried to in the last 20 years). Plus, computers are fast enough, if something is somehow still slow, you can still make it seem fast if you add proper transitions and fix the timing of animations and loading order. For example, maybe one log file is 10GB, of course the browser will c…

I sometimes remember what mad tricks game developers did in the late 90s and early 00s to optimize their games and all that "web doesn't scale" crap sounds just funny to me ;)

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

#229

Post by hn_throwaway_99 »

JoeyJoJoJr wrote: post #187
hn_throwaway_99 wrote: post #118

Earlier quoted context omitted.

Yeah, I agree with that. When I first saw the title on the article I thought "ergh...", because while I think Go is a fine language that really excels in some contexts, the number of developers who are familiar with "Go for the front end" is vanishingly small. My initial distaste was tempered by the fact that I thought they at least had a good reason for wanting to eliminate "need to code twice" for their different f…

On my company’s latest project we are using Spring Boot on the backend with Typescript and React on the front-end. We are using Swagger for API specs which means we can generate type safe Typescript code for the front-end, including schemas for Zod and Tanstack query functions. With this codegen I can’t see many benefits to using Typescript on the backend, although the project is a rather standard CRUD app. I can und…

I replied in another comment here, https://news.ycombinator.com/item?id=43009065.

When I've posted this before, the main objections I've got have usually been from the perspective on individual developers, or stuff like "you can't actually share a ton of code between front-end and back-end". That's not my primary point (though there are some places where it is nice to share code, e.g. input validation that you may want to run on the client for user experience/performance reasons but then that you also need to run on the backend for security reasons). The biggest benefit I've seen is in team dynamics which results in bugs getting fixed faster and new features getting added faster because it's easier for team members to "cross" backend/frontend boundaries.

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

#230

Post by iforgot22 »

spiffytech wrote: post #213
ahoka wrote: post #173

Earlier quoted context omitted.

Browsers don’t do that. Caches are not shared across sites.

Nit: they don't do that anymore , because cross-origin caches cause privacy problems. But they used to, and this news is still percolating through the industry.

Some of them still do, if someone is using an outdated enough browser :D for example Chrome <86 (released 2020).
Post reply on HN