18 ms·

Gallium – Build Desktop Applications in Go and HTML

146 points by kevinwuhoo 10y ago

adrianratnapala 10y ago
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 10y ago
  > 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 10y ago
    > 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).
  - Klathmon 10y ago
    A bit of a nitpick, technically you can hide if a function call is async or not by `await`ing it. It will act the same when it's sync vs async. It would be a horrible idea to await everything, but it would work.
- coldtea 10y ago
  >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. Those are callbacks for event-driven programming. But there's nothing about them that makes it a great abstraction for asynchronous tasks in general, and even less so for concurrency tasks. They are a low level abstraction that should be used as an implementation detail.
- zamalek 10y ago
  > Go has hordes of green threads "goroutines" To clarify, they do not fall into the the strictest definition of green threads[1]. > [2]: As of Go 1.5, the default value of GOMAXPROCS is the number of CPUs (whatever your operating system considers to be a CPU) visible to the program at startup. Prior to 1.5, the default value was '1' but could be changed. > GUI model [...] Does that mean goroutines will fade into the background in Gallium? The main concern at the moment seems to be wrapping the underlying APIs. However, I see channels being used for great effect further down the line: var ui chan uiFunc = // ... button1Click := make(chan ClickEvent) go func() { for evt := range button1Click { ui <- func() { textBox1.setText("Button clicked!") } } }() button1.onClick(button1Click) I presume this also applies to interacting with the V8 ABI, seeing as JS is inherently single-threaded. [1]: https://golang.org/pkg/runtime/#GOMAXPROCS https://golang.org/pkg/runtime/#GOMAXPROCS [2]: http://dave.cheney.net/tag/gomaxprocs http://dave.cheney.net/tag/gomaxprocs
ciconia 10y ago
Supposing Gallium offers a similar feature set to Electron, how would it differ? For example, how would binary sizes compare?
- ahazred8ta 10y ago
  "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."
- alexflint 10y ago
  Author here. I would expect binary sizes to end up similar to Electron since they will be dominated by libchromiumcontent, unfortunately.
hrgeek 10y ago
Cool!
pitaj 10y ago
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?
- johnnydoebk 10y ago
  >> Why would I want to use Go Probably, you wouldn't. But it's not quite surprising if users of GopherJS and Go would prefer Go over JS, is it?
  - onion2k 10y ago
    Picking your technology stack based on "what you prefer working with" rather than "what works best for the application you're building" is piling on technical debt before you've even started your project. That isn't saying Gallium is necessarily the wrong choice over Electron; it's saying you should evaluate them both and use the one best suited to what you're building, even if that means learning a new language. (Obviously this is a ideological argument rather than a practical one because most projects don't have the budget for devs to do that much prep work like learning a new language, but practicality is boring. :) )
    - jalfresi 10y ago
      Isn't Electron the very definition of "Picking your technology stack based on what you prefer working with" rather than "what works best for the application you're building"?
      - Eridrus 10y ago
        I think Electron has proven to be a very powerful model for GUI customization IMO. Some of the plugins people are building are truly amazing and I can't see this happening in a non-web ecosystem.
johnnydoebk 10y ago
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.
- tonyedgecombe 10y ago
  Or even better we could use the native window API's.
  - chii 10y ago
    But isn't the point of this project write once, run anywhere?
- pjmlp 10y ago
  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 10y ago
    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!
- alexflint 10y ago
  Author here. I have been thinking about writing a react-like component system for Go, that outputs HTML. The major down side is that then you can't re-use much between your web-based app and your desktop app (which I think is a common pattern now).
Animats 10y ago
"This will fetch a 92MB framework containing a binary distribution of the Chromium content module". Go needed a GUI, but this?
- IshKebab 10y ago
  Agreed. It would be nice if the Google guys could do something like Qt with Go, but more Go-ish and in pure Go so you can still easily cross-compile. I'd even settle for a faked native look using OpenGL.
  - slimsag 10y ago
    How big are the Qt binaries?
    - sime2009 10y ago
      For a simple app which just has a QML based UI and some networking, we are talking roughly 23MB of DLLs on Win 64. 5.3M Qt5Core.dll 5.6M Qt5Gui.dll 820K Qt5Network.dll 3.2M Qt5Qml.dll 2.9M Qt5Quick.dll 307K Qt5Svg.dll 5.3M Qt5Widgets.dll (It still might be possible to strip out Gui and Widgets though.)
  - adrianratnapala 10y ago
    I know there are OpenGL packages for Go, but I don't think they are really "pure Go" (in the sense of not linking to any C libraries at all). At least not under X11. Unlike all the other X11 extensions, the GLX "protocol specification" doesn't define a network protocol. It defines C functions bolted on to Xlib for setting up GL contexts. In many use cases, there probably is no network at all -- just direct rendering. I don't know what the situation is on other platforms, but I guess it is similar: OpenGL is exposed as some C-based library.
  - creshal 10y ago
    Qt is moving to an HTML+JS based toolkit too with Qt Quick.
infogulch 10y ago
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 10y ago
  Yeah, nothing inspires confidence in a GUI library like a prototype version of a web engine.
  - Johan-bjareholt 10y ago
    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 10y ago
      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.
smegel 10y ago
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?
vertex-four 10y ago
Gallium is also the codename for the userspace graphics driver portion of Mesa.
- DigitalJack 10y ago
  It's also an element with atomic number 31.
  - sspiff 10y ago
    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 10y ago
      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
- citruscomputing 10y ago
  it's also GalliumOS[0], a distro optimized for chromebooks. [0]: https://galliumos.org/ https://galliumos.org/
rikkus 10y ago
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 10y ago
  }}}})}
  - goatlover 10y ago
    Is that you Lisp?
guessmyname 10y ago
> 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/23016/4 https://forum.sublimetext.com/t/sublime-3124-eat-up-my-cpus/...
- bryanlarsen 10y ago
  I've had my web browser open for many weeks without issue. Individual tabs may crash, but the browser stays up and memory usage doesn't get out of hand. Initial memory usage may be heavy on an Electron app, but there's no particular reason to expect unbounded growth.
- FLUX-YOU 10y ago
  How many Chromium instances does Gallium create? Why would it ever need more than one unless you need to spawn a new window? We're way beyond the old WinForms days of making new windows that often.
- brightball 10y ago
  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.
dangoor 10y ago
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 10y ago
  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.
- mmgutz 10y ago
  One can run Chrome in app mode and it will run a Chrome app from a directory. A proof of concept is here https://github.com/mgutz/chromeapp https://github.com/mgutz/chromeapp chrome app <- websockets -> go service
- etwigg 10y ago
  SWT (the eclipse widget toolkit) takes this approach. It's very difficult to maintain API compatibility with the myriad browser versions out there, not to mention having the content in those browser windows display reliably. The real killer-feature of Electron et. al. is only having one browser version to test against. I think embedding CEF is definitely the right call.
- alexflint 10y ago
  Author here. Yes this is a significant price to pay, but being able to test once and be sure that your users' experience will match your testing is worth a lot. It should be possible to have an updater that avoids downloading the main chromium dylib on most updates. This is actually not based on CEF, btw, but on libchromiumcontent (the Electron alternative to CEF).

146 points by kevinwuhoo 10y ago

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 10y ago
> 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 10y ago
  > 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).
- Klathmon 10y ago
  A bit of a nitpick, technically you can hide if a function call is async or not by `await`ing it. It will act the same when it's sync vs async. It would be a horrible idea to await everything, but it would work.
coldtea 10y ago
>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. Those are callbacks for event-driven programming. But there's nothing about them that makes it a great abstraction for asynchronous tasks in general, and even less so for concurrency tasks. They are a low level abstraction that should be used as an implementation detail.
zamalek 10y ago
> Go has hordes of green threads "goroutines" To clarify, they do not fall into the the strictest definition of green threads[1]. > [2]: As of Go 1.5, the default value of GOMAXPROCS is the number of CPUs (whatever your operating system considers to be a CPU) visible to the program at startup. Prior to 1.5, the default value was '1' but could be changed. > GUI model [...] Does that mean goroutines will fade into the background in Gallium? The main concern at the moment seems to be wrapping the underlying APIs. However, I see channels being used for great effect further down the line: var ui chan uiFunc = // ... button1Click := make(chan ClickEvent) go func() { for evt := range button1Click { ui <- func() { textBox1.setText("Button clicked!") } } }() button1.onClick(button1Click) I presume this also applies to interacting with the V8 ABI, seeing as JS is inherently single-threaded. [1]: https://golang.org/pkg/runtime/#GOMAXPROCS https://golang.org/pkg/runtime/#GOMAXPROCS [2]: http://dave.cheney.net/tag/gomaxprocs http://dave.cheney.net/tag/gomaxprocs

ciconia 10y ago

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

ahazred8ta 10y ago
"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."
alexflint 10y ago
Author here. I would expect binary sizes to end up similar to Electron since they will be dominated by libchromiumcontent, unfortunately.

hrgeek 10y ago

Cool!

pitaj 10y ago

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?

johnnydoebk 10y ago
>> Why would I want to use Go Probably, you wouldn't. But it's not quite surprising if users of GopherJS and Go would prefer Go over JS, is it?
- onion2k 10y ago
  Picking your technology stack based on "what you prefer working with" rather than "what works best for the application you're building" is piling on technical debt before you've even started your project. That isn't saying Gallium is necessarily the wrong choice over Electron; it's saying you should evaluate them both and use the one best suited to what you're building, even if that means learning a new language. (Obviously this is a ideological argument rather than a practical one because most projects don't have the budget for devs to do that much prep work like learning a new language, but practicality is boring. :) )
  - jalfresi 10y ago
    Isn't Electron the very definition of "Picking your technology stack based on what you prefer working with" rather than "what works best for the application you're building"?
    - Eridrus 10y ago
      I think Electron has proven to be a very powerful model for GUI customization IMO. Some of the plugins people are building are truly amazing and I can't see this happening in a non-web ecosystem.

johnnydoebk 10y ago

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.

tonyedgecombe 10y ago
Or even better we could use the native window API's.
- chii 10y ago
  But isn't the point of this project write once, run anywhere?
pjmlp 10y ago
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 10y ago
  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!
alexflint 10y ago
Author here. I have been thinking about writing a react-like component system for Go, that outputs HTML. The major down side is that then you can't re-use much between your web-based app and your desktop app (which I think is a common pattern now).

Animats 10y ago

"This will fetch a 92MB framework containing a binary distribution of the Chromium content module". Go needed a GUI, but this?

IshKebab 10y ago
Agreed. It would be nice if the Google guys could do something like Qt with Go, but more Go-ish and in pure Go so you can still easily cross-compile. I'd even settle for a faked native look using OpenGL.
- slimsag 10y ago
  How big are the Qt binaries?
  - sime2009 10y ago
    For a simple app which just has a QML based UI and some networking, we are talking roughly 23MB of DLLs on Win 64. 5.3M Qt5Core.dll 5.6M Qt5Gui.dll 820K Qt5Network.dll 3.2M Qt5Qml.dll 2.9M Qt5Quick.dll 307K Qt5Svg.dll 5.3M Qt5Widgets.dll (It still might be possible to strip out Gui and Widgets though.)
- adrianratnapala 10y ago
  I know there are OpenGL packages for Go, but I don't think they are really "pure Go" (in the sense of not linking to any C libraries at all). At least not under X11. Unlike all the other X11 extensions, the GLX "protocol specification" doesn't define a network protocol. It defines C functions bolted on to Xlib for setting up GL contexts. In many use cases, there probably is no network at all -- just direct rendering. I don't know what the situation is on other platforms, but I guess it is similar: OpenGL is exposed as some C-based library.
- creshal 10y ago
  Qt is moving to an HTML+JS based toolkit too with Qt Quick.

infogulch 10y ago

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 10y ago
Yeah, nothing inspires confidence in a GUI library like a prototype version of a web engine.
- Johan-bjareholt 10y ago
  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 10y ago
    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.

smegel 10y ago

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?

vertex-four 10y ago

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

DigitalJack 10y ago
It's also an element with atomic number 31.
- sspiff 10y ago
  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 10y ago
    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
citruscomputing 10y ago
it's also GalliumOS[0], a distro optimized for chromebooks. [0]: https://galliumos.org/ https://galliumos.org/

rikkus 10y ago

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 10y ago
}}}})}
- goatlover 10y ago
  Is that you Lisp?

guessmyname 10y ago

> 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/23016/4 https://forum.sublimetext.com/t/sublime-3124-eat-up-my-cpus/...

bryanlarsen 10y ago
I've had my web browser open for many weeks without issue. Individual tabs may crash, but the browser stays up and memory usage doesn't get out of hand. Initial memory usage may be heavy on an Electron app, but there's no particular reason to expect unbounded growth.
FLUX-YOU 10y ago
How many Chromium instances does Gallium create? Why would it ever need more than one unless you need to spawn a new window? We're way beyond the old WinForms days of making new windows that often.
brightball 10y ago
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.

dangoor 10y ago

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 10y ago
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.
mmgutz 10y ago
One can run Chrome in app mode and it will run a Chrome app from a directory. A proof of concept is here https://github.com/mgutz/chromeapp https://github.com/mgutz/chromeapp chrome app <- websockets -> go service
etwigg 10y ago
SWT (the eclipse widget toolkit) takes this approach. It's very difficult to maintain API compatibility with the myriad browser versions out there, not to mention having the content in those browser windows display reliably. The real killer-feature of Electron et. al. is only having one browser version to test against. I think embedding CEF is definitely the right call.
alexflint 10y ago
Author here. Yes this is a significant price to pay, but being able to test once and be sure that your users' experience will match your testing is worth a lot. It should be possible to have an updater that avoids downloading the main chromium dylib on most updates. This is actually not based on CEF, btw, but on libchromiumcontent (the Electron alternative to CEF).