search

cogentcore / core

A free and open source framework for building powerful, fast, and elegant 2D and 3D apps that run on macOS, Windows, Linux, iOS, Android, and the Web with a single pure Go codebase, allowing you to Code Once, Run Everywhere.
http://cogentcore.org/core
BSD 3-Clause "New" or "Revised" License
1.31k stars 71 forks source link

Add support for tinygo on web #974

Open kkoreilly opened 3 weeks ago

kkoreilly commented 3 weeks ago

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 commented 3 weeks ago

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

gedw99 commented 2 weeks ago

these 2 things are quite important for adoption.

Prior work where both go, tinygo and gophers compilers exist is Go-app https://go-app.dev which can run server side and client side.

tinygo can take a golang wasm from 6 mb to about 2 MB I found in general.

Also its possible to run on Cloudflare as WASM for free IF you get your WASM small. https://github.com/syumai/workers Then you have a global fast and free way to run your backend and can load up your FrontEnd from Cloudflare R3 to the Users browser.

If someone is building an internal tool they dont care. It its public then the SEO and Time to first interaction matter.

There are a few mitigations also:

Have a Markdown version of the App, with Hugo.

Have a long splash page:

kkoreilly commented 2 weeks ago

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 https://github.com/tinygo-org/tinygo/issues/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.

gedw99 commented 2 weeks ago

Hey @kkoreilly

thanks for the in depth answers.

For the tinygo issue, i suggest raising it with https://github.com/dgryski who is one of the maintainers. He helped me with a similar tinygo issue I had.

For SEO, HTML Server side rendering would be amazing. I presume that means for every widget, you're going to need a html equivalent ?

kkoreilly commented 2 weeks ago

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 commented 1 week ago

please slow...., tinygo is wonderfull, but it is still 1 core program ..., multicore is now planing, but it is still in progres https://github.com/tinygo-org/tinygo/pull/4047

kkoreilly commented 1 week ago

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 https://github.com/tinygo-org/tinygo/issues/2630.