Comment by thefounder
2 years ago
I like it a lot tbh b/c it looks a lot like Go.
Unfortunately Go is unusuable as wasm target for browsers due its huge binary. The browser needs a lot of time to download and parse it. Not to mention it starts to crash if your app is large enough(i.e a complete SPA in Go only).
Yeah, Go has to embed the whole runtime and that amkes for huge payloads.
I'm interested in your experience as I've been working on wasm SPA with Go.
How does it crash? Seems to me that there are examples of stable webapps (for instance using go-app).
Were you using a framework or raw syscall/js call?
Have you tried compiling with tinyGo?
I've been using my own wrapper/library around syscall/js. It crashes mostly due memory issues/allocation. My own app worked fine until a point and then it started crashing.
I applied several temporary fixes by limiting the amount of memory it allocates at start-up. Then optimised various libs to use less memory such:
- instead of generating the html in pure Go using x/html package and applying it to the DOM later I created my own /x/html like package using the DOM (via syscall/js) directly. This was a big optimisation.
- "cleaned" up/forked some public libraries such these provided by Google. For example many of Google's libraries (and not only) use an OpenTelemetry component that's cpu/memory intensive(at least for wasm/browsers).
- replaced some libraries with my own implementation(i.e aws library) reduced to only the API calls I need.
Now it stopped crashing in firefox/chrome (at least on my computer) but it crashes on Safari(at least on mobile). At this point I stopped working on it because I feel the platform is just not ready and I no longer have the drive to fix it(been working for more than 2 years on it).
As you can see it forces you to think about resource management and browser compatibility and you are working in the dark b/c these limitations are not published/official.
Keep in mind that I didn't run intensive tasks. Just SPA stuff(web services requests, data rendering etc).
I didn't try to compile it with tinyGo because I built my tooling/libraries based on Go and unfortunately I do not have the resources required to support yet another platform/compiler(tinyGo). I made extensive use of reflection and last time I checked tinygo had some issues/restrictions with that. Recently I've implemented generics as well(where it made sense).
I may revisit Go with WASM if/when there is a WASM-GC integration.
The good part is that perf issues aside it made UI apps development a pleasure(for me at least).
I see. In my experience, the wasm target is very allocation-sensitive.
I've had to implement a few free-lists myself and went for allocation hunt.
Perhaps it's a memory leak somewhere.
If you have some code example, maybe I can have a look.