There is a lotta stuff that can be done with html and css now without javascript, but for this kind of application I think that the display side (the webkit/blink engine) has to have a websocket to the server backend to allow pushing updates to the DOM, at least refreshes. But this is not a huge chunk of code required and likely already has implementations. Basically just to be able to push new objects into existing ones on triggers from ticks or network events would be essential. But a) that could be built into a thin layer wrapping a DOM canvas implemented maybe in Go, that eliminates the limitation of not being able to use sockets instead of websockets, and one simple command 'replace object X with object Y. Whether it is a list of posts or the ongoing update of a price ticker.
If you are wanting it to integrate like Electron, however, that's a little different. Go can talk directly to local services, dbus, x, and so on, and so I think already there is enough that you can open a window in X that is 100% webkit DOM canvas that you can, through this service I am proposing, a small wrapper around a simple borderless webkit canvas, that speaks via socket to the server backend, opening the channel to implement all the things that Electron allows like system tray icons and gnome application menus and whatnot. The skinny controller service wrapped around the canvas would mainly need to be able to send window geometry and compositing requests, and webkit itself has the input queue that you could connect to goroutines for instant response. I think you can even, with gnome at least, even add the decorator/controls natively, or with fallback, to Broadway, which also wraps around a HTML/CSS/DOM, so it can coexist if you wanted it to. I am very interested in this direction of inquiry as I want to develop transparent (a la plan 9) application routing such that running a service locally, fully remote, or some mix of local and remote components cooperating. So you can have an application that will run anywhere there is Go, a modicum of support of system calls for network, storage and general IO, that can either use one or more 'windows' or be itself a window manager and desktop environment complete with interfaces to IO and system level configuration (network, display, audio, etc). Something that would allow, for example, to ad-hoc join another display from another device (let's say we have a desktop with system monitor, a mobile phone, a tablet and a laptop all arrayed around us, and they can all either directly run the back-end processing or connect to another device to do this. The phone could be decoding audio that is playing out of a HDMI connected monitor or through a bluetooth on the tablet, the desktop accessing files on the mobile and laptop at the same time in a FUSE overlay filesystem, the phone sending video to the desktop to encode for a 60hz 4k video stream from lossless frames instead of 3gp or avc encoding on the device, and windows can be dragged off one device and appear a moment later on another device's display, with processing optionally migrating or connecting via the GUI protocol (ie, push DOM changes). It's really hot subject at the moment and I think that with a language like Go and the universality and competence of Webkit and Blink soon nobody's going to care except for real issues whether it's got a bsd mach, darwin, WOW64 or CPM kernel or if webkit is running on bare metal inside kernel mode with no enforced MMU fencing by the executive... The way I see it, bare metal, static native compiled, and an inbuilt source repository system, will win out because it cannot be made any faster, and with a cheap to compile, powerful and flexible language like Go in the middle of it. Rip out ECMAscript engine from webkit, put a go compile server in its place, and your Go can run native in the background, middle or just under the surface directly controlling elements of the canvas directly. I have been studying the field of operating systems and languages for a long time and there is a long overdue need to revisit the places Plan9, NoKernel, Exokernels, bare metal builds and JiT compilation caching for a proper native binary object form for executables and libraries, and sockets everywhere! It's coming back, and I think it's just a matter of time before 'kernel' becomes more connected to firmware binary blobs for coprocessing and IO systems, and, really, do we need a pre-emptive executive when we can have goroutines instead? All this discussion about how much nicer Java is but Java does not have Goroutines. Go has the ingredients inside it already for an alternative model for parallel and concurrent processing, imagine one process per core that manages all execution via goroutines, and on some devices, like video cards, they can run their own kernel and server that ... well, I know that every hardcore gopher dreams of the 'everything is a server' world of Plan9. Anyway, so basically the issue is you may find some frameworks to connect Go to a webkit canvas, but I would think they won't be as mature as Electron. However, consider also that Go can serve progressive web apps, which is a nice half way towards a universal GUI application platform. here's a couple of projects that might get you started: https://github.com/zserge/webview https://github.com/sourcegraph/go-webkit2 https://github.com/sourcegraph/webloop https://github.com/crazy2be/gojs https://github.com/zserge/webview On Sunday, 23 September 2018 05:46:30 UTC+2, ati...@mail.ccsf.edu wrote: > > Hello, > > Is there a good active library that can serve HTML, CSS, and JS in a > desktop app without CGO? Something like electron for Go. I do not want to > programmatically create the GUI. I would rather create separate HTML. I > also do not need communication between the two, I can just run POST > requests. > > Suggestions appreciated. > Thanks! > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
