> We've rebuilt GitHub Desktop from the ground up in Electron to create a simplified user experience focused squarely on how you use GitHub
Would be really interested to see some benchmarks comparing the performance of the Electron version and the previous version. Start-up time, time to perform common actions etc.
Personally I think it's a bit of a shame, since I seem to remember the previous version making use of the platform's native toolkits and widgets, e.g. WPF on Windows and Cocoa on Mac. I suspect the overall UX will now suffer. I guess it's easier to develop though, and works on Linux now?
Edit: Oh, there's still no build for Linux.
They do detail some of the reasoning (https://githubengineering.com/how-four-native-developers-wro...) behind this decision in the GitHub engineering blog and it looks like they've put a lot of work into this. But even the menu bar they've come up with (https://github.com/desktop/desktop/pull/991?) for Windows is obviously not native. The decision seems to boil down to (paraphrasing) "lots of people are doing web stuff" and "now we can reuse our code" ... which is fine, but again seemingly prioritises the development over the user experience.
That's the whole point of Electron period. Cut development costs. Meanwhile end-users (including developers) will suffer, because along with their chrome instances using hundreds of MB in ram, they will have electron apps open using similar (and in many cases more) amounts.
Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed.
Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform.
Stepping back and looking at the state of things as a whole, I find it mildly depressing that large companies like github, facebook, google, etc... can't seem to churn out native apps despite their deep pockets. How are the rest of us supposed to manage?
> Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed.
Unfortunately I can't give it a relistic try, I can't find a Linux build and I wouldn't get a realistic feel for performance inside a VM. My prior experience with the performance Electron based applications comes from using software such as Atom, VS Code etc. I can't say I've experienced WPF apps being that slow when I do use unvirtualised Windows, though (I think I noticed startup time, but that's about it).
> Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform.
Yeah, everything I read pointed at it being a reasonably early release - which is fair enough. I'm sure they'll iterate and improve.
> But even the menu bar they've come up with [...]
Menu bars are a native construct on both Windows and MacOS. They serve the same purpose but work differently on each platform. Users have expectations on how menus will behave, how they will look, and where they will be located. Using the system's menu bar construct gives the developer all of that for free.
I can't understand why any developer of a native application needs to "come up with" their own menu bar.
Just about the only application that people use on Windows that has a native menu bar is Notepad. The vast majority has a custom menu, either a ribbon like Office or something else.
Various arms of Microsoft's design efforts have definitely been trying to kill the menu bar as design pattern for many years at this point. Ribbons are superior. Fluent has its own suggestions for how to build the right affordances for a menu, which remain very similar to Ribbon principles.
Ironically/sadly, Visual Studio will probably be the last bastion of classic menu bars and toolbars from Microsoft because to some extent Microsoft's designers are busy elsewhere, but that continues to set a bad example to developers.
If it weren't for Visual Studio itself, I'd even argue that it was merely the cross-platform interests of keeping Mac users happy that GitHub's team might even think menus were a good idea.
I'm pretty sure that Microsoft uses Office, in part, as a way to develop and refine new UI elements.
At some point the API got pulled out of Office and made part of Windows proper, with the Windows Ribbon Framework[0]. Built in applications, Explorer being the most visible, have now started using it.
All complaints on HN are mostly valid in technical point of view. But from business point, reducing the costs also make sense just like moving some parts to be made in China.
A _design_ which is a generic term of thinking of human interaction shouldn't be tied to tools/toolkits. On desktop application, I lack of bad experience using web-tech wrapped apps so I haven't seen significant suffer from interacting with these (I'm using Atom, Github Desktop)
I don't know why these kinds of applications aren't developed in far better performing frameworks and languages. Github desktop has to process a lot of textual information. With the current version, I've frozen it and crashed it many times due to large files. I actually can't use it anymore due to that. Make it in c++ with QT or some other native toolkits, like every other gilded application of old has. It will 'Just work', which is what developers need. Not fancy UI's
I assume that with 'just works' the OP actually meant to say 'just works without too much hassle/overhead'. For example: staging lines/hunks on the commandline does 'just work', no denying that, but in most UI's it's way more efficient and pleasant.
Just like how you want a nice UI for staging individual lines, some of us want a nice UI in general, and few of us have low enough standards to consider qt to be "beautiful"
What about qt isn't 'beautiful'? It's very close to native for most widgets, and the cool thing about QT is that you have the perfect ability to make your own widgets and theming. The comparison here is electron, which certainly is not going to look like anything native, and QT can be themed almost the same. Not the same css support, certainly, but I don't think Github desktop would be too problematic in that regard.
Slack, Atom and Github combined is fine(fire) on my 2GB of RAM (operated by El Capitan). It's just like RAM no longer hold data as a cache (less cache hits) and has to write to disk frequently although SSD is much slower than RAM. Not too bad until .. I have to do videography editing, these dev tools have to be closed! All of them!
I've been having a lot of performance issues with sourcetree so honestly, I don't care how much ram this uses as long as it manages to push a commit to my medium-sized repo in less than 30 seconds...
>We specifically made the decision to write each application in a language native to the platform, and this has turned out to be hugely beneficial to us. Because of this separation we've been free to tackle the problems that are most pressing for each platform and work in the best possible tools instead of being constrained to the lowest common denominator.
2017: GitHub discovers software development is hard, falls back on lowest common denominator.
EDIT:
80MB installer. Automatically unzips into %ROAMING%. 140 MB of RAM used with a single repo loaded. Yep, sounds like Electron.
Oh, also, it doesn't even list any of my repos after logging in.
> We specifically made the decision to write each application in a language native to the platform
Except for Linux - of course.
Now - at least with an Electron app, we might actually finally get a Linux port. In fact, while not official, the current version has been forked and made to work (somewhat) in Linux by someone (I posted a link to it earlier).
Sure - they could have done this with Qt or something else - but they didn't, and almost no other company does, either. It's like when they say "cross platform" what they mean is "everything but Linux - because they don't count, amirite?"
Uh... As far as I know, installers work well. Sorry for wanting to choose where I install my stuff. Spoiler: It's not on C:\. Chrome started that trend of install-less installs, and I've hated it ever since.
>wow, that would be alot in the 90s
Indeed, let's see which processes I have running that take up less than 140MB, shall we?
* Battle.net. Full app launcher, with patching capabilities, okay.
* OpenHardwareMonitor. Does a shitton more than GitHub.
* Mumble. Does a shitton more than GitHub.
* Windows Explorer. Does a hell of a shitton more.
* Steam. Finding a pattern there?
* Origin. Skype. Task Monitor. Intel XTU. The list goes on and on. All doing infinitely more than what amounts to little more than an UI on git.exe
Thing is, sometimes I actually need that RAM. To run games, Photoshop, or Atom, depending on how much I hate myself right now.
But hey, it's okay, as a developer, you can choose to disrespect your users, that's your choice, not mine :>
So they went from a subpar native application to an even more subpar application on Electron. I think I'll stick with SourceTree. At least that won't take 10 seconds to boot up.
I've never used Github Desktop but SourceTree has its own set of glaring problems from interface to functionality. I stick with the command line these days.
SourceTree just became worse and worse with every release, to the point of unbearable. I am using an old version of SourceTree (1.5.2) and it works great.
There seem to be a lot of repositories taken down from Github.com [1] -- over 30 in the past week alone. I am not sure if they've removed repositories from local PCs ever, but presumably with control over the client they could, similar to what Amazon can do with the Kindle [2].
Sometimes i think Electron is literally the worst thing that happened to desktop apps. Fuck these bloated, +10 seconds startup on a i7 + SSD , non native looking "desktop applications".
Yeah, it's a "fad" that I hope ends reasonably soon. I guess a lot of businesses just care moreso that using Electron reduces costs and the user experience and performance isn't a priority.
Will the native versions also be open sourced when they're retired?
I'd be willing to volunteer some time to bring the Windows one back up to speed. All I wanted in a new version was for it to respect my system accent color and switch to using system webviews internally (neither of which this new version does either).
One thing that worrying to me is that you include an 'undo' button that rewrites history. This is bad, as it could affect everyone downstream of you. That button should be turned into a 'revert' button.
I use git and github regularly for my hobby/side projects and even for contributing patches to some open source projects hosted on github. My typically workflow is using git command line for commits and the usual things and then a git push to my remote github repo and use their website to submit PRs, respond to reviews etc...
I am curious, how people use desktop app for github and what value it adds when compared to just using github website.
From personal experience, GitHub Desktop is great for teaching people new to Git about how it works /prior/ to them being comfortable with Git on the command line. It's not something I'd use on a daily basis, but it does make it very easy to make your first commits and PRs - and visually see where you are, what changes you have staged etc.
If my browser had the capability to set watch on multiple different directories for a service worker, you could have an almost desktop like experience without a different software.
With service workers, this would be pretty much do everything that the Dropbox or Github clients can do.
I use VSCode now days, as my primary git commit interface. Some improvement are required in diff / merge, but it is very clean interface and never caused any ambiguity.
It is also an Electron application, but taking 1/2 battery then Slack, so reasonably efficient.
Between git command line, gitk, and git gui I don't really see the need to try tools like SourceTree or this new GitHub Desktop Beta. Is there a compelling reason I'm missing?
In this thread you'll find many native app developers who are dismissing Electron because they feel threatened.
Cross platform apps are the future. Each day I run at least three Electron apps simultaneously and have no problem whatsoever. You have to be paying close attention to notice, and the reality is that most people do not care.
In fact, I was so intrigued by Electron, that I started developing my own app. So far the experience has been pure bliss.
> In this thread you'll find many native app developers who are dismissing Electron because they feel threatened.
That's an interesting claim to make, what makes you think that a lot of those who are upset by this decision are not just users who have tried Electron applications and found the UX poor? Why are they feeling 'threatened' and not just frustrated with this growing trend?
I'm not a native app developer in the slightest sense, I do mostly web work (server-side MVC mostly, but also a lot of frontend work) and enjoy working on security related to that.
Poor UX is an implementation problem, not an Electron problem. The popularity of well-built apps like Slack, Atom, and VSCode would seem to indicate many, many people have no problem with the UX.
> You have to be paying close attention to notice, and the reality is that most people do not care.
You're right, most people don't care. But this app isn't targeted at "most people" it's targeted at developers. Developers do care about things like CPU's running at 100% while idle, memory pressure and apps crashing because they can't open a 1GB file.
I think its a generational thing. Im 26 years old. Portability is extremely valuable to me, I use different operating systems constantly. Older devs may see portability as being less important if they spent most of their working lives in one environment. That being said, im still trying to learn, so there are valid points to take away from on both sides of the issue.
> the Electron apps take huge amounts of memory and CPU to perform the simplest tasks.
I'm not going to dispute this, as I've seen it myself; Electron apps can be huge hogs.
So - why not fix them? What is the problem with Electron that causes this? What is the problem with the apps themselves that cause this? Is there an underlying API or something causing all the problems, or is it a death by a thousand cuts kind of issue? Is it the underlying browser instance?
Whatever it is, whether one thing or many, those are the things needing fixed. Don't like them? Then fix them where you can; it's open source after all. Find the problem, fix it, submit a pull request.
I understand (myself included) - "I don't have the time!" - nobody really does, I guess - so maybe we need to make the time? Even if it is just to isolate the issue, that could go a long way towards the solution.
Instead of bitching about this issue, let's help fix the problem. Where Electon seems to shine, above and beyond say, "C++/QT" - is that it has real traction. It's a single ecosystem that leverages stuff a lot of people already know. More people know web technologies than know C++/Qt (ok - citation needed and all that - but I'm pretty certain it's true). It's also (probably?) cheaper to higher them. So companies do that.
While it would be great if our web ecosystem were composed of C++, Qt, etc - it isn't, and it isn't likely to change. Companies want stuff fast, they want stuff cheap. Most people don't care if things are bloated or slow, or what they are written in, as long as they work (this has been the truth forever, of course).
So we might as well get used to it - and try to make it better. In the long run, it will only help us.
I didn't know 'open source project shill' was an occupation. I'm feeling audacious, I'll bite.
You run three electron apps simultaneously and don't care, but your users are not running on heptacore 16GB RAM machines. They care, a hell of a lot.
Hell, even I with an heptacore and 16GB RAM care when Electron apps appropriate two full cores to render shit a CPU from 15 years ago could have done with native technologies.
I run the following browser-based apps, concurrently, every day:
Atom (electron), Discord (electron), Spotify (electron-like), App Store (webkit), Steam (webkit), Safari, Chrome.
I have all of these running, without a single problem. Performance is great. I don't need a "heptacore 16GB RAM machine" to do it - I run all of this on a 2016 Retina MacBook. The 8GB RAM, 1.2GHz dual core Intel M5, passively cooled ultrabook.
Would be really interested to see some benchmarks comparing the performance of the Electron version and the previous version. Start-up time, time to perform common actions etc.
Personally I think it's a bit of a shame, since I seem to remember the previous version making use of the platform's native toolkits and widgets, e.g. WPF on Windows and Cocoa on Mac. I suspect the overall UX will now suffer. I guess it's easier to develop though, and works on Linux now?
Edit: Oh, there's still no build for Linux.
They do detail some of the reasoning (https://githubengineering.com/how-four-native-developers-wro...) behind this decision in the GitHub engineering blog and it looks like they've put a lot of work into this. But even the menu bar they've come up with (https://github.com/desktop/desktop/pull/991?) for Windows is obviously not native. The decision seems to boil down to (paraphrasing) "lots of people are doing web stuff" and "now we can reuse our code" ... which is fine, but again seemingly prioritises the development over the user experience.