
Cross-Platform UI in GitHub Desktop - samlambert
http://githubengineering.com/cross-platform-ui-in-github-desktop/
======
lpsz
I have to say, I miss the age of native apps. I understand that it's awesome
cakes for Spotify, GitHub, etc. engineers to share JavaScript bits between
devices. But it sucks for me as the user! The Spotify app (on my Mac) has
become a resource hog over the years.

Same with Slack's Mac app. As beautiful as it is, there's just something that
doesn't feel 100% responsive/right with a web-based app.

    
    
        "With separate code bases for OS X & Windows
        converging on a single design, we knew that
        sharing code would be essential going forward. 
        Sophisticated as the graph is, implementing
        it twice would have been a significant burden."
    

How is it ever reasonable to prioritize _coding_ convenience over the end
users' experience? This team set out to solve a cool engineering problem (code
reuse) and forgot altogether that people are actually going to be using this
stuff.

~~~
gcr
Thing is, by using a cross-platform drawing library like Cairo or OpenGL, a
lot of this code could have been reused anyway.

It wouldn't have been as nice or expressive as Javascript though. But it also
wouldn't have required hacks like stitching together a giant string to be
`eval`', for example. So there's a tradeoff.

~~~
merogin
I haven't used the application (can't on Linux), but if the graph doesn't
require user interactivity, using Cairo or some other software renderer (e.g.
[http://www.antigrain.com/](http://www.antigrain.com/)) to just render the
graph into a bitmap, would do the job faster and with less resource usage.
Adding user interactivity on top of that shouldn't be a lot of work either.

------
sz4kerto
I find it horrifying that on a Haswell i7 a chat app or a text editor
STUTTERS. It's really ridiculous and sad at the same time.

~~~
zanny
For every clock your CPU gets, a developer will find a way to waste it.

Why is there so much interest in HTML + Javascript based normal applications?
They are slow, the langauges are awful, but besides Qt they are the ultimate
portability. So sacrifice all those hz gains and power efficiency to make the
developer workload minimal.

~~~
andreasklinger
I assume because developers approach it with a different mindset:

Theoretically all of this problems can and will be solved. The advantage would
persist.

But agree. Reality looks often different

------
twerkmonsta
I was wondering why the performance was so awful, and reminds me of Atom in
it's slow startup...

This answers it all.

~~~
andresmanz
Yes, that's not unusual these days. I wonder if they even care when the user
experience gets destroyed just for a bit less development time.

~~~
xorcist
Does it web tech really have lesser development time? My experience is
definitely the other way around, and I probably have put more hours in on the
web side. Web is unbeatable for things like responsive UIs, but when you want
pixel based it's hard to beat the development speed of Visual Whatever or Qt
Designer.

~~~
andresmanz
Well, at least that's what I read all the time. I couldn't confirm it, too,
but I always thought that's just because I'm perfectly fine with Qt. QML is
also pretty good for responsive UI.

Maybe these companies prefer the web stuff because most developers know it
anyway.

~~~
rhodysurf
I think its because so many devs are trying to move away from C++. Qt really
is great and its sad to me because its a much better solution than these
crappy browser apps.

~~~
pjmlp
C++ isn't the only way to write native code.

~~~
rhodysurf
Obviously. I was kinda dumbing it down to the fact that seems like many people
are moving away from native.

~~~
pjmlp
Actually it feels the other way around, with Go, D, Rust, .NET Native, Swift
and the upcoming AOT compiler on Java 10 (maybe).

~~~
rhodysurf
Thats true, Rust and Go seem to have brought the popularity up a bit which is
nice.

------
fsloth
Did I understand correctly? So they include the whole browser tech stack for a
simple graph? Am I the only one who finds it strange - rendering text and
polygons is not exactly rocket science.

~~~
currysausage
_> So they include the whole browser tech stack for a simple graph?_

And they have the balls to post it on a blog with "Engineering" in its title.

Then again, this appears to be the new standard of doing things. We consider
the browser to be today's operating system, and modern apps (Spotify, Visual
Studio Code, Atom, etc.) bring their own operating system. Fire up your editor
and jot down a quick note? Yeah, why not make coffee while it's loading. Back
to the future, I guess.

------
Cshelton
It'd be interesting to see something like Servo (browser rendering engine by
Mozilla, written in Rust lang) possibly work with web views in a "native" app.
This would enable rendering the view multi-threaded, like native rendering
engines.

~~~
htor
Agreed. Servo (or any other multi-threaded engine) will definitely be a game
changer.

I'm curious - when is Servo going to be smacked inside Firefox? We need that
lovely thing right now.

------
rogerbinns
Hopefully this means they will end up releasing the gui app for Linux too.
While the command line isn't a problem for experienced developers used on a
daily basis, it is a problem for those contributing who aren't the core
developers.

------
signal11
What are the power consumption implications of embedding a web component like
this? Will this be harder on the battery than using native drawing APIs?

~~~
kuschku
Yes. You have to start a webbrowser control, which reads the JS code and
compiles it every time it runs, additionally the added sandboxing and
abstractions (that are unnecessary in this case) also add to power usage and
lower performance.

A better solution would have been something like OpenGL.

~~~
mwg66
"better"

------
thecrumb
Cross platform would work on Linux.

------
szx
Since the app already bundles web views and resources, I'm curious to hear if
they considered making it an Electron app, and if they did - why they decided
to go with multiple native apps instead.

(I realize at least the OSX version probably predates Electron, still might
have paid off to completely rewrite.)

~~~
mdiep
That is something that we've considered. Both Mac and Windows clients predate
Electron (but maybe not the initial versions of Atom).

Rewriting from scratch in an unfamiliar environment would have taken a lot
more work. There are tradeoffs to both approaches, but using the existing
native apps let us ship a less buggy release more quickly.

------
mwcampbell
I'd like to know more about why the .NET WebBrowser control was deemed
unworkable. Is the problem with the actual WebBrowser control provided by the
IE engine, or just the .NET interface to it (presumably the one provided by
WPF)?

~~~
myoon
The WPF browser control is pretty weak. You don't have great control over
which rendering engine it will use (default is to go to IE 7 mode!) except via
writing a registry key to switch it. It provides almost no bridge between the
JS and native code as well. I haven't used CefSharp, but I have used
Awesomium, which provided pretty good JS-C# bindings, so I assume CefSharp has
at least working JS-C# bindings.

~~~
m_fayer
I've also had a great experience with awesomium which imo has a more powerful
api than cefsharp, I'm curious why they chose it over awesomium.

~~~
julionc
I guess the reason is that they (Awesomium) don't provide an Open Source
license like MIT or GPL. Instead Github Team choose CefSharp.

------
cheez
Yet another way to avoid using C++

------
wereHamster
coffeescript? I thought by now they'd switch to a more advanced language (say,
TypeScript or ES6+flow).

