explore https://gioui.org/ as UI

[cbrake]

@gedw99 lets start a new issue for this exploration

https://gioui.org/

Discussion of nats.go/wasm: nats-io/nats.go#831

[cbrake]

yeah, I don't know enough about either web sockets or SSE to have a strong opinion.

With SSE, would you also have to proxy at both the frontend and the backend?

Another consideration is AuthZ/N -- I'm looking at leveraging NATS to handle all the Auth issues, so would need to consider all that if we proxy anything.

[cbrake]

Here is the brainstorming on Auth: #268

[cbrake]

interesting stuff. I tried to build pointstart:

[cbrake@ceres pointstar]$ make
go build -o pointstar-server ./server
go: downloading nhooyr.io/websocket v1.8.4
go: downloading github.com/klauspost/compress v1.10.0
go build -o pointstar ./client
go: downloading gioui.org v0.0.0-20200510064036-c2cbcee78de0
go: downloading golang.org/x/image v0.0.0-20190802002840-cff245a6509b
go: downloading golang.org/x/sys v0.0.0-20200124204421-9fbb57f87de9
# gioui.org/app/internal/egl
/home/cbrake/go/pkg/mod/gioui.org@v0.0.0-20200510064036-c2cbcee78de0/app/internal/egl/egl_unix.go:39:3: cannot use nil as type _Ctype_EGLConfig in return argument
make: *** [makefile:12: client] Error 2

Looking at code:

I then tried a gio kitchen example, that runs fine:

[cbrake]

I'm on Arch Linux. I assume since the gio demo works, I have needed dependencies.

[cbrake]

This illustrates one fundamental truth -- any time you get C dependencies involved, you are up against build problems. May not be your build, but someone will hit build problems. I've spent the last decade trying to tame embedded Linux build problems with mostly C code:

https://github.com/YoeDistro/yoe-distro/graphs/contributors

It has provided a good living (no one else wants to do this kind of stuff), but I'm convinced there is a better way. We don't fix problems by piling on layer after layer of complexity. From this perspective, pure Go is the development experience I've been looking for, and I feel is the best path forward for anybody developing embedded Linux apps (my customers).

There are tradeoffs -- gioui may be compelling enough to live with the CGO build issues. Maybe WASM will be CGO free. I feel that the future (at least for industrial embedded Linux apps) is browser based UIs in some form or another.

[cbrake]

That is great gio wasm is CGO free -- certainly holds promise.

I really like Elm for the following reasons:

• has the same values as Go -- simplicity
• functional programming is neat
• produces very high quality results (no run time exceptions in the browser)
• community is great, friendly, helpful, etc
• elm-ui is amazing
• reasonably popular: https://github.com/jah2488/elm-companies
• the hard work is done (rending node tree, etc). Adding new features at this point is relatively easy.
• asset size is tiny (https://community.tmpdir.org/t/comparison-of-asset-sizes-for-various-front-end-technologies/213/3) -- feel free to contribute to this tread if you have go/wasm info.

That said, there are some disadvantages of Elm:

• its not Go
• its functional and Go is not
• learning curve is much steeper than Go

So I realize for OSS adoption, Elm is likely a hindrance on this project.

Exploring alternatives is a good idea. SIOT can certainly have two or more UIs. The architecture (everything is done through NATs) makes it easy to bolt on additional modules/UIs that are not part of the core application. For example, you could write a machine learning module in python that connects via NATs and processes data and generates new data.

So I'm all for exploring alternatives -- just want to make sure we discuss tradeoffs, project goals, etc.

Can you help understand how gio is CGO free? In the go/pkg/mod/gioui.org@v0.0.0-20200510064036-c2cbcee78de0/app/internal/egl/egl_unix.go file above, it seems there is CGO stuff.

[cbrake]

I'm interesting in seeing how the GIO use case might work out. Would probably be simplest to start with a desktop app and see if you can connect via NATS and display a node tree, or some useful demo. Looking forward to seeing how it works out!

first I've heard of centrifuge -- you are a library of OSS technology! -- looks neat, but I'd need to understand what specific things it will do that we can't do with NATS. Again, my approach is solve real-world problems and add/change technology as I go -- not add in boatloads of dependencies at the start. A simple single binary deployment is also very important to me (especially at the edge). The symmetry of running the same SIOT apps at the edge and in the cloud is also a very powerful. However, it also requires a focus on simplicity because resources at the edge (embedded Linux systems) is limited.

[cbrake]

yeah, GIO does look pretty neat -- immediate mode UI programming is interesting.

The point is that the web socket layer is stateless . That is the most important aspect.

Can you explain this a little more? It seems NATs direct connect or NATS over WS is about the same.