Its cool. I will have a look and post back here on progress, questions etc.

:) well thanks for letting me know.

Any feelings about where the problem could be, before i start hunting for the source of the bug ?

The sqlite tool that translates c to go has now reached beta and actually works. This transpiler is a likely candidate for doing the same with hafbuzz

https://www.reddit.com/r/golang/comments/hyenjh/cgofree_sqlite_databasesql_driver_for_linuxamd64/

Here is the generator: https://gitlab.com/cznic/sqlite/-/blob/master/generator.go

This is the only working example that i could find to show tinygo being used to compile golang to WASM for browsers

Its all here:

https://github.com/vugu/vugu/blob/master/devutil/tinygo-compiler.go

• https://github.com/vugu-examples/tinygo/blob/master/devserver.go#L24 is copying the dependencies across explicitly.
• https://github.com/CosmWasm/cosmwasm/issues/448 explains why it was done this way. Basically to get around the fact that tinygo cannot handle go.mod.

Which uses: https://github.com/vugu/docker-vugu-tinygo-dev

• this does nothing special and is just a convenience.

This is the example that shows it:

https://github.com/vugu-examples/tinygo

• Calls to tinygo-compiler.go at https://github.com/vugu-examples/tinygo/blob/master/devserver.go#L16

I plan to have a go at this approach, but wanted to let others know also as they may have their own thoughts on this.

It would be cool to get this working as the WASM code will go from 8 MB to 400 KB in general for basic projects.

In the kitchen example on IOS Safari the touch events now work.

The input events dont work. For example when the user types in the "Hint" area, no virtual keyboard comes up on the mobile.

Thanks so much. I just tested the kitchen example on IOS Safari and the touch events work.

Everything seems to work pretty well. The input events dont work. For example when the user types in the "Hint" area, no virtual keyboard comes up on the mobile. I will raise an issue for this for now.

I agree that the runtime performance is not great. Getting the obvious bugs fixed will allow me and others to experiment with getting it working with Tinygo. Being able to write a GUi app in golang for web is still a huge win for gophers in many ways still.

Download size can be reduced using compression. This compresses the WASM file using brotli https://github.com/ctessum/cityaq/blob/master/gendoc.go#L34 Kitchen.wasm goes from 7 MB to about 1 MB. Not a bad win.

About tinygo. Here is the only example i could find where tinygo works for golang wasm: https://www.vugu.org/ Code: https://github.com/vugu-examples/tinygo Docker: I suspect that this is the dockerised version of Tiny go that is being used by this example.

Again thank you for the fix.

Go-Flutter and Flutter in general is very impressive. Things really work.

• Video does not work... Which is sad.
• When google changes stuff the go-flutter teams fixes things.

GIO is literally the exact same architecture and way way closer to the metal. Hence why my interest in GIO :) Not as many plugins, but way easier to develop.

Its a game of tradeoffs as always, so here goes:

The way i use them. You can code up all your plugins in go and use them for desktop, mobile and Web ( as wasm). So then the community can use them with gio and flutter. Thats my intent. Some projects need flutter some need gio and give people choice. The plugins can have a DB, Event source changes to the GUI layer to update for real time apps.

Hope this helps.

I am much more into GIO because i find using it much faster. But GIO web on mobile does not work properly, hence why i am trying to get that fixed with the Team.

thanks for the comments.

Cross device. Sometimes you need a Device ID, as well as the UserID. You basically you to know all the devices the user is logged in on.

Also you need to push over a few channels normally due to the many devices world we live in. See: https://github.com/appleboy/gorush

• Where you need to send notifications via the Apple and Google Gateway.
• Used in order to "wake up" you app if you know what i mean.

So as always we have to support native and PWA Service workers perhaps.

With the PWA situation, and the Service Worker allows Web Push Notifications. The OS "should" then allow the notifications to create OS level notifications because the Service Worker is "always on" based on the contract that PWA and Service workers guarantee. See the Gorush Features list where is says "Support Web API to send push notification." - so should work.

IOS Safari is however is a little behind the times here i think. See: https://caniuse.com/#feat=notifications.

• Lets se if Apple play ball going forward. Good chance they will i think. But you never know...

Then you need something on the Server that acts as a store and forward relay. Why ? Because User X writes a chat message to a group and then goes offline, and so the message needs to be delivery to all the others in the group. Whatever way arbor models this as data is nether here nor there - you got to sent something to the other users to tell them about the new data...

One candidate is LiftBridge. See: https://github.com/liftbridge-io/liftbridge The code is very clean and has a simple GRPC API. Its golang all the way down too and designed for HA world. Its basically Kafka but in golang. Also you need to store and forward images data too. Use case woudl be when a user adds a Picture to the chat, and then goes offline. I am currently quite impressed with SeaweedFS. See: https://github.com/chrislusf/seaweedfs/issues/1394

Hope that this is useful for Arbor...

OK i added the request for Mobile Web support: https://todo.sr.ht/~eliasnaur/gio/149

Seems Mobile Web has a few rough edges...

WheresWaldon has made a fantastic Material Drawer over at : https://git.sr.ht/~whereswaldon/materials

I was very impressed about how well these components can be build with minimal code on top of the GIO API.

But it seems GIO Mobile Web does not support touch events automatically ? Or something else is not right. I am not sure.

Just do the normal testing and you will see:

cd $(LIB_FSPATH)/example && gogio -target js $(LIB) cd $(LIB_FSPATH)/example && goexec 'http.ListenAndServe(":8080", http.FileServer(http.Dir("example")))'

I noticed something like this on the Kitchen example in the gio repo also.

I actually am not sure whats going on. It might be the Canvas Translation not matching up with the hit test and so the touch events are just not being hit... I tested on Android Chrome, but not IOS Safari. In Desktop Chrome it also fails under the "Mobile" switch view.

Could this be looked at please ? It might not be that important for some but supporting Web is somewhat important because of the reasonably big shift towards PWA and the OS and Browser vendors now having pretty decent support for Service Workers and the things that go with that.

This means no silly app store fees, no silly signing up fees to Apple, no blocking because your app does too many things and breaking the Apple rules, and the list goes on.

On Mobile and Desktop, the "Add to Desktop" works on many desktop and mobiles now. I know this because i use Flutter and it "just works" on flutter on the main mobile and desktops.

I was pleasantly surprised the OS / Browser vendors are being so nice about letting use the use our Hardware that we paid for in such a freedom loving way - sarcasm....

So the Developer and User experience becomes low friction. A User if they like what they see just clicks "Add to Home Screen" and Notification and background Service workers can do close to what a Native app can do.

It also means easy deploy onto the new Pine64 Mobiles as most apps are actually just running inside a web view and add to desktop works there too. I am playing around with this too and also the Pine64 Watch for gio native.

It would be awesome if GIO Web support was here for Mobile. Happy to help push it along in whatever way i can also.