Desktop application using unix domain sockets and electron/webkit

<p>I don&#39;t know how stupid this idea it. Just occurred to me. I know electron is avalable. Also this might be available already.</p> <p>Idea is running a server listening on a domain socket and a web view is the client.</p> <p><a href="https://github.com/aki237/up" rel="nofollow">https://github.com/aki237/up</a></p> <hr/>**评论：**<br/><br/>mixedCase_: <pre><p>Just use a desktop toolkit.</p> <p>I&#39;m currently using lime-text&#39;s fork of go-qml, it&#39;s working fine for my usecase.</p> <p>There are other options as well, like andlabs/ui for native widgets, therecipe/qt for Qt bindings, golang-ui/nuklear or aarzilli/nucular for nuklear bindings/reimplementation respectively... and these aren&#39;t the only ones.</p></pre>aki237: <pre><p>Thanks. But at some point, the go runtime clashes with C function calls. I happen to experience that with gotk3. I haven&#39;t tried go-qml. I tried lime text. Not happy with the performance.</p></pre>mixedCase_: <pre><p>What do you mean by clashes? Naturally, most of these things use lots of cgo, although Nucular is pure Go outside of its dependencies (gomobile and OpenGL interaction, although the former doesn&#39;t affect desktop apps).</p> <p>Lime text&#39;s QML frontend (if I understood correcty from a quick glance to their code) seems to do a lot of the UI logic in the Go code. This is a bad QML practice even if you&#39;re using C++ due to the big call overhead.</p> <p>In my case I keep communications to a minimum and it works fine. But then again, I don&#39;t have much going on yet, I might hit a performance roadblock at some point. For the moment, it laughs in the face of Electron performance-wise.</p></pre>cjbprime: <pre><p>It works, some Electron apps already use it.</p> <p>It&#39;s a little complicated since only the main thread can access the UNIX socket, not the renderer (window) threads.</p></pre>