Cross-Platform UI in GitHub Desktop | Hacker News Reader

Cross-Platform UI in GitHub Desktop

githubengineering.com

61 pointssamlambert55 comments

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.

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.

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/) 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.

Yep. They could also use some shared C/C++ bits to generate various drawing metadata ("the model") and delegate the rendering/input handling to whatever platform-specific APIs.

It may be more work, but if you're not going to build an actual native app, why bother? These apps are built as a sales point ("look, we have a Mac app!"), without the customer in mind.

What we've done with GitHub Desktop is very different than the write-an-entire-app-in-JS approach that a lot of apps have taken. There's a small piece of custom UI that's built with HTML, JS, and CSS; but even it is controlled by native code. GitHub Desktop is still mostly native code on both platforms.

Fully agree.

What alternative real native GUI clients are there for Git on Windows?

I use this on Mac, it looks like there's a Windows version as well: https://www.sourcetreeapp.com/

Thanks, looks quite nice.

I rather use tools that embrace the native platforms.

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.

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.

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

Besides Qt, JavaFX, wxWidgets, Xwt, even Gtk offer a better native experience than a browser widget.

Script kiddies are cheaper than C++ developers.

Hear, hear. http://handmadehero.org is almost therapy for me in that regard: Casey looks at assembly output from the compiler all the time.

Yeah, it's amazing. We've had decades of improvements in hardware performance, only to end up with software that's slower than anything that came before it. Yet apart from a small minority, nobody seems to bat an eye.

Oh, the people do care.

Even my mum complains every day about it. "Can’t be that a 4 year old smartphone can’t run a chat app like whatsapp fluently"

But she refuses to buy a new phone, because that would just fuel this even more.

Or rather, the new phone would burn jet fuel even more.. That's the main problem, we shouldn't be coding for saturation of resources. It's ridiculous how wasteful apps are these days.

Yes, that is the exact issue. Upgrading just costs money and does not really improve anything.

I see it myself, upgraded from Huawei Ideos X3 (2.3.7) to Motorola Moto G (5.0), and it’s just as slow as the old phone was. Despite being twice as expensive.

There's plenty of us (game developers) that do our best to push the hardware!

I'll always remember fondly coding in my 486 days with the Borland Turbo C++ IDE; we had no keystroke latency at all back then.

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

This answers it all.

This actually has nothing to do with our startup performance, at least on OS X. The comparison graph doesn't have a substantial impact on it. :)

Also, any similarities to Atom are superficial at best on OS X. We use WebKit (where Electron/Atom use Chromium) and most of the app is native code.

I'm less knowledgable about the Windows side, so I can't comment on it.

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.

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.

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.

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.

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

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

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

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

Same in my experience. Often times (and yes, this is anecdotal), using a web framework for desktop - or mobile apps - greatly extends development time, when you take all of the littles thing that it takes to build a production-ready system into account.

I'm more annoyed by their (apparent?) removal of simple synching of a single branch.

That was already the only thing I used GitHub for Windows for, and that's only because Visual Studio doesn't speak SSH.

> that's only because Visual Studio doesn't speak SSH.

External tools is how you access things like SSH or the developer console in visual studio.

http://stackoverflow.com/questions/21476588/where-is-develop...

  From VS2013 Menu Select "Tools", then Select "External Tools". Enter as below: 
 
  Title: "VS2013 Native Tools-Command Prompt" would be good 
  Command: C:\Windows\System32\cmd.exe 
  Arguments: /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat" 
  Initial Directory: Select as suits your needs.

And that works with the Git integration? If so, there's about 50 sources that disagree with you.

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.

> 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.

If done in HTML, it is rocket science. When I started reading and they mentioned that only a graph is cross-platform, I was thinking - "oh, they probably used OpenGL". Little did I know...

It is called canvas and 2D drawing hardly rocket science.

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.

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.

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.

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?

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.

"better"

Cross platform would work on Linux.

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.)

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.

http://www.joelonsoftware.com/articles/fog0000000069.html

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)?

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.

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.

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

My key problem, working with it, is you're stuck with whatever IE the user has installed on their machine.

With CEF (which I've used, as have many other big companies - search your Windows PC for the dlls if you don't believe me), you're guaranteed every user has the same version of Chromium.

Yet another way to avoid using C++

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

Reply on news.ycombinator.com