Comment by thefounder

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