
Gallium – Build Desktop Applications in Go and HTML - kevinwuhoo
https://github.com/alexflint/gallium
======
Animats
_" This will fetch a 92MB framework containing a binary distribution of the
Chromium content module"_.

Go needed a GUI, but this?

~~~
sfifs
Actually I think the standardization of HTML5/CSS3/JS as the UI framework is
preferable to the extreme fragmentation that exists in the "native" UI space

I think there's opportunity in packaging this as a system installed &
independently updated dynamically linked library much like WebView is updated
on Android KitKat onwards. Eg. a single "system" Chromium component that's
installed centrally & used by multiple programs much like Microsoft Runtime
DLLs on Windows.

~~~
ravenstine
Why? Disk space is plentiful and costs peanuts, and is becoming cheaper by the
day. What's there to gain from having shared libraries other than that it's
psychologically satisfying? Having been a Linux user for 12 years, I feel like
it's of very limited benefit and has lots of drawbacks. Is there something I
am not understanding?

~~~
kuschku
My / has reached 200GB now? And that's despite /home being seperate.

That's the issue.

With this, my / will reach terabytes.

There's two things why not: cheap isn't free, and "elegancy principle": Don't
build shitty hacks, build software that's easy to maintain, as minimal as
possible, and will be used for decades.

------
pitaj
What benefits does this have over Electron?

Why why would I want to use Go on the integration side, and still have to use
JS within the webpage? Most Electron apps I've seen have a slim wrapper of
code in their main file to just initialize native things. Why is it better or
easier to do that in Go instead of in JS?

~~~
bpizzi
With Gallium the "outer layer" is compiled whereas with Electron end users can
take a look at the scripts (there's some ways to mitigate it, but still, it's
not compiled into a binary).

This can be useful if, for example, you want to deploy this as a commercial
software and do some checking against piracy...

Which leads to: there's still no licence attached to this cool project ;)

~~~
kuschku
So, you're saying, the only advantage is that instead of every high school
student being able to crack your DRM, now only every college student will be
able to crack your DRM.

Just stop it and give up on DRM.

------
dangoor
A framework like this would be awesome if it used the browser engine on the
system rather than CEF, or allowed that as an option. You'd be able to get Mac
programs that are just a couple of MB then, rather than having each of these
programs weigh 50-60MB. The runtime characteristics might not be much better,
but at least every binary is a bit smaller.

Of course, this is a minor complaint on modern systems...

~~~
falcolas
I believe the reason people don't want to use the OS-native web interface is
because of the need to support multiple frontends. It's easier to keep your
presentation layer consistent across OS when you have a shared rendering
platform.

------
adrianratnapala
So Go and JS are similar in that they are designed for heavily asynchronous
tasks. But they do it very differently: Go has hordes of green threads
"goroutines", JS has callbacks all the way down.

As annoying as callbacks can be, they do fit the model basic GUI model very
well: user clicks on something, the system calls the corresponding funciton.
And indeed I see a lot of that sort of thing in the README.

Does that mean goroutines will fade into the background in Gallium?

~~~
aikah
> So Go and JS are similar in that they are designed for heavily asynchronous
> tasks. But they do it very differently: Go has hordes of green threads
> "goroutines", JS has callbacks all the way down.

concurrent tasks =/= asynchronous tasks.

A big difference is that Go doesn't force you to write asynchronous code for
I/O operations, JS engines like nodejs do and it's a pain in the ass. Go only
says : "If you want to write concurrent code you can do that", while NodeJS or
browsers say :"Any I/O operation needs to be asynchronous and explicit".

If I call an API in Go, I don't have to care whether the computation will be
executed in the same thread or not, or in 10 different threads, provided
concurrency is encapsulated the right way. There is no amount of
async/yield/promise that can mask any I/O operation with Nodejs on the other
hand.

> As annoying as callbacks can be, they do fit the model basic GUI model very
> well:

This is a design decision. Gallium could have used channels instead of
callbacks.

~~~
sime2009
> A big difference is that Go doesn't force you to write asynchronous code for
> I/O operations, JS engines like nodejs do and it's a pain in the ass.

Node also has a full set of 'normal' synchronous I/O operations (although they
were added later after the async stuff).

------
vertex-four
Gallium is also the codename for the userspace graphics driver portion of
Mesa.

~~~
DigitalJack
It's also an element with atomic number 31.

~~~
sspiff
That's not the point. Both of the other uses are for open source projects, so
there is plenty potential for confusion.

Chromium is also an element, but if I named a third OSS project "Chromium"
(first: [1], second: [2]), I bet people would complain.

Windows and apple are common words in the English language, but I bet I
couldn't name my software project either of those.

Context is important when deciding whether a name is appropriate or not.

[1]:
[https://en.wikipedia.org/wiki/Chromium_B.S.U](https://en.wikipedia.org/wiki/Chromium_B.S.U).

[2]:
[https://en.wikipedia.org/wiki/Chromium_(web_browser)](https://en.wikipedia.org/wiki/Chromium_\(web_browser\))

~~~
freehunter
This always comes up with OSS projects, that there's another project with the
same name. But the reality is there are only a limited number of names to pick
from, and an unlimited number of projects. That's why we went to names like
Tumblr and Flickr for a while. But if you think Apple is a unique name, you
might be surprised:
[https://en.wikipedia.org/wiki/Apple_Corps_v_Apple_Computer](https://en.wikipedia.org/wiki/Apple_Corps_v_Apple_Computer)

------
smegel
A language that was not designed for desktop apps and a markup that was not
designed for complex user interfaces - what could possibly Go right?

------
infogulch
Chrome(ium) is fast but I feel like it's getting heavier over time.

Package up servo with DOM api via C ffi and you'll have my attention.

~~~
coldtea
Yeah, nothing inspires confidence in a GUI library like a prototype version of
a web engine.

~~~
Johan-bjareholt
Which seems pretty stable already and is now in testing?

Even if someone started a project like this they likely wouldn't be done until
it gets a stable release anyway.

~~~
alexflint
Author here. Yeah using servo might be workable because you could test all
your HTML ahead of time and work around any problems (unlike the any-browser
web workflow). Still I agree re stable release.

------
guessmyname
> How large are the compiled binaries?

> The executable itself is 2.2M [...] Bundle 95MB [...]

>
> [https://www.reddit.com/r/golang/comments/53tw4p/a/d7x2a91](https://www.reddit.com/r/golang/comments/53tw4p/a/d7x2a91)

People feared when many former Node.JS developers migrated to Go because they
would probably migrate the same principles from the JavaScript community _(NPM
and the dependency hell)_. Now people will fear the migration of Electron-like
applications to the Go ecosystem. I am glad that more and more web developer
are stepping forward and contributing their skills to create desktop
applications, but I still cannot wrap my head around the idea that embedding a
giant non-efficient webview in every project is a good idea. At this point, a
computer with +16GB RAM will feel like using one with only ~6GB because of the
amount of Chromium instances open in the background.

Someone reported yesterday a problem in the SublimeText3 issue tracker [1][2]
stating that after the automatic update to the latest version the software
started to consume a lot of RAM and CPU, but then he explained that _(while
using a Mac)_ he had ST open for several months, WTF!!! He should be graceful
that you could keep ST open for more than a week, try that with an Electron-
based application like Atom and you will cry. Now imagine this scenario with
the future Go+Electron-like applications in the following months.

[1]
[https://github.com/SublimeTextIssues/Core/issues/1387](https://github.com/SublimeTextIssues/Core/issues/1387)

[2] [https://forum.sublimetext.com/t/sublime-3124-eat-up-my-
cpus/...](https://forum.sublimetext.com/t/sublime-3124-eat-up-my-cpus/23016/4)

~~~
brightball
The main reason is user expectations. People expect applications to be
portable between web, desktop OS, tablet/phone OS. Developers only have so
much time and budget so currently HTML provides the best option to port
interfaces between all platforms in the shortest period of time.

It's not ideal, but everything generally comes down to cost benefit analysis
with time being a major contributor to cost. That's the entire reason that so
many startups have been using Ruby despite it's non-ideal performance. Soon as
you get a steady revenue stream from users taking the time to optimize to
something else makes sense.

Granted, Elixir is shifting that formula quite a bit now since you can get
those Ruby-like levels of productivity and time savings without the long term
expectation of refactoring headaches.

------
johnnydoebk
I wonder how good a desktop app will work if we drop the JS part altogether
and use HTTP and regular client-server architecture (i.e. every click will
have to rerender the template)? I guess something like Mozilla's servo can be
used for that instead of a full featured Chromium to improve performance.

~~~
pjmlp
Just throw away the HTML part and make a proper native application using
network protocols, e.g. the "HTTP and regular client-server architecture".

That is what I went back to doing in these last three years
(Forms/WPF/Android/iOS/WP) and couldn't be happier to have regained some
sanity away from the Web world, fad of the day with browsers bended to pretend
native UIs.

~~~
simplyinfinity
I'm a full stack dev that can't stand JS, now i started to do UWP (xaml) app,
the learning curve is a bit steep, but the UI building is SOOO much better
than html/css/js and everything behaves exactly as you would expect and
vertical positioning just works!

------
rikkus
The code looks quite pretty, except for a bit of the close-all-the-braces I
see:

    
    
              },
            },
          },
        })
      }
    

Is there a way to write this more clearly?

~~~
EdiX

        }}}})}

~~~
goatlover
Is that you Lisp?

------
ciconia
Supposing Gallium offers a similar feature set to Electron, how would it
differ? For example, how would binary sizes compare?

~~~
ahazred8ta
"install Gallium ... This will fetch a 92MB framework containing ... Chromium"

"Both Electron and Gallium use Chromium under the hood, and in fact some of
the C components for Gallium were ported from Electron."

------
hrgeek
Cool!

