Add support for GopherJS on web

[kkoreilly]

Describe the feature

Using https://github.com/tinygo-org/tinygo for web could drastically reduce binary sizes, making it much more viable to use Cogent Core for websites. I tried to do this and ran into a bunch of issues with reflect slice headers and missing os functions, but we should look at this again and try to get it working at some point.

Relevant code

No response

[kkoreilly]

We could also look into things like wasm-opt and https://github.com/gopherjs/gopherjs to reduce web binary sizes.

[kkoreilly]

Yep, I have used go-app before and our web loading mechanism is based on theirs. I definitely want to reduce binary sizes and loading times and improve SEO support, as all of those things are critical for a good user experience.

Again, as I stated above, tinygo has an incompatible reflect slice header type, which makes it untenable to use with multiple of our dependencies that we cannot easily control. See tinygo-org/tinygo#1284 and https://tinygo.org/docs/guides/compatibility/ for more information. Either we can try to convince tinygo to change their reflect slice header type for wasm, or we can try to convince our dependencies to update to the new unsafe slice type.

For SEO, we have issue #702. I am planning to implement SEO by doing a server-side pre-rendering step that builds an HTML tree representing the content which can be used for SEO purposes, similar to go-app.

I already did work on making the loading screen look nicer, but we can certainly work more on having some sort of interactive first stage. Hopefully the loading time is fast enough with tinygo and other binary size optimizations that we don't need to worry too much about that.

[kkoreilly]

I think it is unlikely that they will be receptive to this issue given that they already discussed it a lot in the issue I linked above and other issues, and decided to keep their incompatible reflect slice header type and advise people to use the compatible unsafe slice type instead. Therefore, I think our best chance is just filing issues and/or PRs for our dependencies that still use the incompatible type. I hope to be able to work on that somewhat soon, although various other issues may be higher priority.

Yes, we will need some HTML encoding for every widget. However, it hopefully shouldn't be too hard if we use a general xml marshaller in our base tree package and then implement a best-effort matching of our widget names and properties to corresponding HTML ones. Again, I am prioritizing other things that are more urgent, but I would like to work on this relatively soon.

[MatejMagat305]

please slow...., tinygo is wonderfull, but it is still 1 core program ..., multicore is now planing, but it is still in progres tinygo-org/tinygo#4047

[kkoreilly]

We are only talking about using tinygo for wasm. Go already does not support multicore on wasm, and neither does tinygo, so using tinygo should have no impact on that. See tinygo-org/tinygo#2630.

[kkoreilly]

I tried again to implement tinygo support, and I was able to get the basic example building after changing various things and commenting out all of the icons. It was 15 MB compared to 32 MB for the standard Go compilation, but when compressed, it was 5 MB, which is only slightly smaller than the compressed standard one, which is 6.4 MB. Therefore, given the various issues and limitations of tinygo and the long compile time, I think that we are unlikely to pursue this route for the time being.

[kkoreilly]

Yes, we are definitely still planning to support tinygo at some point once these issues are resolved, it is in a better state, and we have more time. I am just saying that it will not be a priority for now due to the marginal gains and the various issues.

You can look at the tinygo branch if you want; it is mainly just temporarily commenting things out so that it builds. In addition to what is committed there, you also have to replace //go:embed with // //go:embed in icons/icongen.go because of tinygo-org/tinygo#4348, which is another reason that I am not particularly excited to implement tinygo support for now.

After you do all of that, examples/basic should build, although more complicated examples such as docs result in a crash in the tinygo interpreter for some reason.

But again, I am definitely still excited to implement tinygo support later after we have finished the initial release and some of these tinygo issues are resolved.

[kkoreilly]

We are now considering gopherjs to be the better solution for this. This is because tinygo only gives marginal binary size gains when compressed, whereas gopherjs appears to give 3x reductions in size when compressed. Also, gopherjs may bypass various other wasm performance issues. Here are the sizes of the a standard wasm output and a gopherjs output for a simple markdown example:

-rw-r--r--   1 kaioreilly  staff   1.5M Jul 24 19:49 debug.js
-rw-r--r--   1 kaioreilly  staff   309K Jul 24 19:49 debug.js.gz

-rwxr-xr-x   1 kaioreilly  staff   3.1M Jul 24 19:49 app.wasm
-rwxr-xr-x   1 kaioreilly  staff   902K Jul 24 19:49 app.wasm.gz

GopherJS still needs various improvements to work for Cogent Core, which we are planning to make soon (see gopherjs/gopherjs#1334).