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

231–240 of 242 posts

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

#231

Post by Aeolun »

runarberg wrote: post #222
Aeolun wrote: post #196

Earlier quoted context omitted.

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…

> I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers

This is all HTML & CSS. Bootstrap made responsiveness normal ever since it was introduced. If you have any form of server rendered application you have to handle these. It’s not like you can choose to hand it to a nonexistent front-end dev, since there is no separate front-end.

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

#232

Post by iforgot22 »

Muromec wrote: post #190
iforgot22 wrote: post #182

Earlier quoted context omitted.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

It's more of a go problem than the wasm problem. Don't bundle such a big runtime and pass memory pointers around and you can have nice things. Something beam-hosted with zero pointer sharing between nodes and smaller runtime maps to wasm much better.

It's also unfortunate for a lot of heavy JS libs out there that they can't be cached locally anymore, but security is important.

One WASM-related case I've actually encountered in the wild is Unity web. Similar problem as Golang, the runtime is heavy.

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

#233

Post by TehGM »

pier25 wrote: post #216
onion2k wrote: post #44

Earlier quoted context omitted.

People get really hung up on page weight. It's nice when an app loads fast with a cold cache, but if it's something that you load once and then keep open, or it's something that's easily cached for a long time after the first visit, page weight is much less of a worry for most users. Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to…

I'm not arguing about page weight per se. The more code you have to download, parse, and run, the more CPU and memory and battery you'll be using. WASM enables certain use cases like using FFMPEG in the a browser or game engines running on canvas which are super cool. But for 99.99% of DOM related functionality, JS is really the way to go. Edit: Here's another example. Loads and executes like 10MB of WASM code for so…

Author of ScHQ here. I want to explain the Blazor use here.

While I think it's a bit of a stretch to say it'd be 100kB JS (the app does a LOT of client-side lifting, so it'd definitely take more than that), otherwise you're right - WASM, specifically Blazor, is heavy. It's a bunch of download and non-ideal start time.

The reason I use Blazor here is that I work on this website alone, as a hobby project. This means I prefer to use tech (C# and .NET) I like to use instead of going lenghts learning additional frameworks. It also enables server and client share same code in places, so it can be used both in client and on server without having to program it twice. The website wouldn't be even nearly as feature rich if I had made it in JS.

The point I am making - I'd not advise Blazor use for every app, and if you already are familiar with JS frameworks, they're a good (or even better) choice. However WASM and Blazor has niches outside of "I do super fancy stuff" websites. It makes rich website development possible for backend devs and other people familiar with other technologies. It's good to think outside of the box sometimes.

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

#234

Post by neonsunset »

pier25 wrote: post #216
onion2k wrote: post #44

Earlier quoted context omitted.

People get really hung up on page weight. It's nice when an app loads fast with a cold cache, but if it's something that you load once and then keep open, or it's something that's easily cached for a long time after the first visit, page weight is much less of a worry for most users. Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to…

I'm not arguing about page weight per se. The more code you have to download, parse, and run, the more CPU and memory and battery you'll be using. WASM enables certain use cases like using FFMPEG in the a browser or game engines running on canvas which are super cool. But for 99.99% of DOM related functionality, JS is really the way to go. Edit: Here's another example. Loads and executes like 10MB of WASM code for so…

Interestingly enough, it loads just 1.15 MB compressed with the biggest assets being logos on Firefox. At the same time, I can see it downloading far more assets (as if, unpacked and uncompressed blazor bundle?) on Edge/Chromium. What's going on?

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

#235

Post by TehGM »

neonsunset wrote: post #234
pier25 wrote: post #216

Earlier quoted context omitted.

I'm not arguing about page weight per se. The more code you have to download, parse, and run, the more CPU and memory and battery you'll be using. WASM enables certain use cases like using FFMPEG in the a browser or game engines running on canvas which are super cool. But for 99.99% of DOM related functionality, JS is really the way to go. Edit: Here's another example. Loads and executes like 10MB of WASM code for so…

Interestingly enough, it loads just 1.15 MB compressed with the biggest assets being logos on Firefox. At the same time, I can see it downloading far more assets (as if, unpacked and uncompressed blazor bundle?) on Edge/Chromium. What's going on?

Make sure you open the page in incognito/private window.

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

#236

Post by dilyevsky »

iforgot22 wrote: post #166
tazjin wrote: post #102

Earlier quoted context omitted.

Well, for one, you need the whole Go runtime.

Can that at least be a separate wasm file from some common URL so the browser can cache it?

Can't be done until Wasm Components are widely supported by browsers and everything in wasmland moves at turtlespeed for various reasons...

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

#237

Post by owenpalmer »

hansonkd wrote: post #70
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…

perhaps you are the exception that proves the rule :shrug: or perhaps its hard to objectively measure one's owns abilities. which is the most common thing i have seen from "full stack" interviewees.

> perhaps you are the exception that proves the rule

As someone who worked directly with OP, I can confirm they are highly exceptional. Don't be too surprised when you encounter talented people on HN. I challenge you to be more inquisitive, rather than dismissive.

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

#238

Post by kflgkans »

satvikpendem wrote: post #224
kflgkans wrote: post #223

Earlier quoted context omitted.

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.

I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments.

I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.

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

#239

Post by satvikpendem »

kflgkans wrote: post #238
satvikpendem wrote: post #224

Earlier quoted context omitted.

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.

I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments. I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.

https://www.hnreplies.com is an unofficial way to get comment replies via email.

Perhaps you should look into Vale or Pony then, they have memory safety like Rust, also without a GC, but they use different mechanisms for it.

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

#240

Post by mmarian »

kflgkans wrote: post #238
satvikpendem wrote: post #224

Earlier quoted context omitted.

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.

I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments. I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.

> I don't know how to make HN give me some kind of a notification on replies to my comments

I built https://hackernewsalerts.com for that

Post reply on HN