I'll add to the Electron hating bandwagon.
Not every native app is good and often the UI and design feels crappy. I mean this was the case for decades. But I will still prefer crappy looking performant app over nice looking sluggish electron app.
I really really would not want to use a "productivity" type of application that is made in Electron but I also know that many people do not mind.
This said we are again in the era where it does not matter to most of the users. If it would people would stop using Atom/VScode and others. We all know that there is not a more cost effective way of building multiplatform apps (all things considered).
We will have to cope with this as long as there is not real competition.
I just tested it agains sourceTree, which is native, and I can't see any differences. It loads as fast, navigation and selection take the exact same time to load.
The only difference, github desktop eat 200mb instead of 60mb for sourcetree.
At the end of the day I will still use the command line, except for diff. But for a git gui, I can't really see what you mean by sluggish.
Sorry but sourcetree isn't exactly the best benchmark for native performance. Quite the contrary actually. It is the worst piece software i've ever used, just staging a file can take like 10 seconds. I've experienced this on multiple computers and i'm far from the only one with these problems: https://duckduckgo.com/?q=sourcetree+slow
Such a shame because it's one of the few GUI apps for git that actually looks good and has nice workflow.
Atom and VSCode are different beasts! The team at Microsoft has done some serious performance work on Code IIRC and it runs like native on my machine, compared to Atom which is still slow.
I really like the old version better. I really dislike this "cross platform" crap that runs terrible. It's like using a javascript app. Not only that, they don't even have it for Linux, so what's the point of doing a cross platform interface...
It's built with Electron, so it's not just like using a javascript app, you are actually using one.
That said, I personally don't have a huge issue with Electron apps on face value - some of them (VSCode, for example) seem to outperform their native counterparts quite handily (in this case, VS - install time, upgrade time, cold start time, warm start time, actual usage). That tells me that the implementation choices affect performance as much as the underlying technology.
Visual Studio is a far more full-featured IDE. A more objective comparison would be VSCode vs. Sublime. There you could say VSCode is comparable at best.
agreed. If Sublime had an acceptable way to implement good debugger support, and spent more time on the plugin development ecosystem (dependencies, easy plugin testability, etc...) it would be pretty damn stellar (and lets be honest, its a great editor as is).
VSCode doesn't beat SublimeText, Vim, Emacs, or Notepad++.
Electron apps might beat other electron apps (VSCode over Atom), but we're still a long sight off from electron apps beating compiled ones in most cases.
I was replying to the performance of the application.
Debugging: Fair enough. VSCode is starting to stray toward IDE, which the others described specifically exclude. They focus on the text editing and leave the debugging for other specialized programs. VSCode would make sense to be an IDE since it's coming from a Visual Studio lineage though.
Multiple Projects per Workspace: Sublime has this as a project can have any number of folders added to it. A sublime project is equivalent to a VSCode Workspace unless I'm missing a nuance somewhere. Vim and Emacs are less useful in this regard, though they have project management plugins. Most of the time, Vim and Emacs will just save off a workspace in what they call a "session". You can load the session and be exactly where you left off (down to the cursor position). These can also be configured to happen on startup/shutdown.
I think he is referring to performance, which in my experience is true. You would have to do a really terrible job for an electron-based app to beat your native app performance-wise.
Yeah, I'll be sticking to the old Mac desktop app too. Visual bugs with the commit timeline notwithstanding, it's solid and smooth. The electron replacement is comparatively janky.
If they ever EoL the old true native Github Desktop, I'll probably switch full time to Fork, which is native Cocoa and generally great. I already use it a lot, but there are times when Github Desktop does things a little better.
Fork developer here. Could you share what features you miss so I could implement them? You can use the feedback button on the toolbar in Fork or contact me directly by email: support at git-fork.com.
Hey, already love Fork after just a few minutes. Rebase support, stashes, sub-modules, tabs... this is fantastic :)
You may actually get me to delete SourceTree, which is a high bar to clear. Despite all the major issues with SourceTree, like locking the main thread for 3 minutes, pinning the CPU to 100% just because a file was staged, and refreshing the diff view 100 times in a single minute, I haven't been able to switch away from yet.
P.S. your Cartfile is being copied into the resources folder :)
Yeah, I tried the new version a week ago and was very unhappy with it. Even ignoring the electron stuff there's a lot of issues-
* A lot of the right-click context menus have vanished from the old version to the new, which really changes the workflow.
* Integration with Atom is super buggy, to the point where it literally doesn't work for me. I used to be able to right click and open in Atom, but now if I use the shortcut to open in Atom it just gives an error claiming Atom isn't installed when it is. Opening up the old github desktop app and attempting to launch atom had no issues.
* Integration with Github itself is super flaky. Normally the "open in desktop" launches the github desktop client, but after installing the new version it literally doesn't do anything at all.
I'm honestly really surprised that this is a v1.0.0 release. Normally Github does a better job of making sure their releases, well, actually work.
wait, you mean the (originally) windows GitExtensions app? Cause that was bar none the beat git UI ive ever used. As in, im a hardcore command line git user for everything, and I still actually liked GitExtensions.
It looks like theres an osx port now. Im super excited. GitExtensions was literally the best at everything for my workflows.
They've gone to all the trouble of building an app using web technologies, but don't offer a Linux version? I develop on Linux because I deploy on Linux. I don't need a virtual assistant or animated emojis. I would quite like a nice Git UI however.
Some people have gotten it to work and they've indicated that they're interested in officially supporting it at some point. Perhaps it will get more attention now that the 1.0 release is finally done.
Seconded, probably the _best_ git UI there is, in terms of feature coverage and productivity.
Coincidentally, it's currently on Kickstarter[0]. Mind you, this is a fully functional, mature and free product - the author is just trying to fund next few years of development.
GitKraken is the best GitUI I've ever used. I highly recommend it. I use it for personal projects and at work. Professional License is really reasonable.
As much as i would like to agree with you, it should be a simple problem and there should be many comparable alternatives available, i can't because frankly all of the free clients in the wild suck in one way or another. I've been looking for years but everything i tried either looks like a cheap hack made with TkInter or lack one or two vital features. One might have a good branch viewer but lacks interactive staging, another client the opposite, etc.
I haven't tried gitkraken though, maybe it sucks equally much, my point is that there is an open market spot for good git GUI.
SmartGit - It's cross-platform and written in Java. Unlike most Java GUIs, this one looks professional, well thought out and has been quite stable as a daily driver. There is a commercial license, but the free version is quite sufficient for individual use.
Any Mac users (Windows coming soon, apparently?) wanting a native Git GUI client should check out Fork. I've been using it for a few months (switched from one of the various forks of GitX) and love it. It's not open source, but it is in a free beta. It's well designed, simple, and actually feels like a Mac app.
GitKraken is also nice. It's built using Electron so it's going to be hated here, but I've been using it for the past year on a somewhat considerable project and it held fine.
I wonder what the pricing is going to look like when it's stable. I generally don't like depending on tools when I don't know the future (like if they'll use a subscription model).
Honestly, there's very little to depend on here. There's nothing this app does that you can't do in Terminal, and it would be easy to switch to another GUI tool. This one is just really nice.
Not what I was hoping for. I use GitKraken for most of my daily Git stuff and the CLI when its needed.
I was hoping GUI for more administrative purposes. It would be cool to get desktop notifications when issues are created, code is pushed, etc. I have yet to see a tool/extension that integrated with GitHub this deeply.
It definitely seems like this could be useful for those who don't want to mess with the CLI (which is perfectly reasonable IMO).
I prefer the old app - not because of electron, but because the UX is worse now (to me, at least). The old mac app made adding a repo super obvious (there was a plus button), branches had cleaner names, and the sync button looked like... a button. Now everything looks slick, but very unintuitive. I would love to see the ease of use increased considering that advanced users would probably favor the terminal anyway.
Did you actually tried it and did it use 4GB of RAM for you? I did and it used about 120 MB of RAM, which is not tiny, but not even in the ballpark of your figure.
I know hating Electron apps is the new fad, but it would be nice to check the facts before you grab your fork.
How long did you leave it running? In my experience electronic apps tend to leak memory for some reason. Atom starts up at a couple hundred megs, and actually does end up at around 4GB. Same with Slack, although it's gotten better. I used to actually have a launchd script that killed Slack and restarted it every 30 minutes to keep the memory usage down.
I left it running when I first wrote the comment. Went back to it just now, after nearly two hours, and the memory usage didn't increase. Still at 120-130 MB.
My guess is that compared to Slack, Github app doesn't really do much when idle. Slack fetches user statuses, new messages, notifications and so on. When you have an open channel with ongoing conversations that will add up in the RAM. This app doesn't seem to do anything when idle, so the RAM usage doesn't increase.
Yeah. Built the entire business model on top of Git, a tool that Torvalds build to maintain Linux but won't release an app for Linux because they think nobody would use it.
What he meant is probably 'nobody would use it because they are comfortable using git from the command line' (I know I am). Anyway, considering it shouldn't be hard to distribute in on Linux, I'm not sure why they didn't do it. Surely it's useful to someone?
VCS existed before Torvalds. They must have a reason for not releasing a Linux version. I mean it's free what the heck do you want ? How can you even complain ?
Good job to everyone involved. I understand that people don't like Electron apps, that Linux this or that, but it's still a lot of work to maintain this app and I know for a fact that it does help lower the barrier of entry for non-experienced, budding developers around the world, so keep it up.
It makes sense (they can share code between Github Desktop standalone and their Atom-plugin, which does more or less the same thing as Github Desktop).
Electron has many benefits (lots of people know JS; CSS is better than the standard macOS tools for GUIs). But with Slack, Atom, Hyper and now Github Desktop running on Electron, the memory usage is getting painful. They all use several hundred MBs each, sometimes with multiple processes so even more in aggregate.
Hopefully with more growth of Electron, there will be more shared resources to spend on improving its memory usage.
XUL applications were never that bad? At least Firefox, thunderbird and songbird, which are the three I'm aware of using. In the case of Firefox and thunderbird, I'd argue they were for a long time superior to their native competitors (FF2 for example easily bet the pants off IE6, Safari for Windows, Konqueror, was Epihany a thing then? though I will give Opera had a much more performance UI). As for Songbird, it had very low bars to beat WMP or iTunes/Windows or whatever media player your Linux distribution included that year.
That said, I didn't use Macs during that period, so maybe they were awful on Mac or something. I assume Camino existed for a reason.
I’m still using SourceTree, not happily, but everything else I’ve tried is utter shite. It either breaks on big repos, is horribly slow or just a usability train wreck.
I find it gets slower with each update - have you tried the latest with 6-8 active repos open? It spends most of its time refreshing, even with very few changes.
I’ve also had some broken commits due to changes not being shown until I hit refresh.
At least they’ve fixed the large diff lockup’s. And yes, the line and hunk staging is brilliant.
I have been using the beta version of Github's Electron app for a while and hadn't suspected it might not be a native app. It feels very snappy and quick.
Around 80 MB of RAM with my project open in GitHub's Electron-based desktop app as well.
For comparison, gitk is about 14 MB for the same project.
Overall, GitHub's desktop app seems to have fairly stable memory use in my experience, though that stable mark seems relatively high compared to native counterparts. Not nearly as bad as some Electron apps, which seem to have no ceiling to their memory usage. Not a horrible price to pay, if you can accept the stable overhead.
Hey guys thanks for the work on this, I've been really impressed with the interaction and performance on the new Github Desktop. I have been using the Github Desktop since Github for Mac was in early versions.
It took a little getting used to, but the new version is much smoother and faster.
Two additions I would love to see ported over from github.com
* A toggle between inline and split diffs
* A summary view with all changes on the current branch, not just per file changes
I decided to install this on a new OSX given I thought newer would be better but I hope this isn't representative of consolidation of a cross-platform Desktop App as it's measurably worse than both existing GitHub Desktop for Windows and OSX.
I hope they don't discontinue their existing Windows and OSX Desktop Apps because this experiment is a value downgrade.
Funny it is based on Electron and it doesnt support Linux. Maybe they think Linux developers only live in terminal, or they just hate it when someone criticises Electron consuming too much memory
Electron, which means it's heavy and feels like a website rather than an app. But worse, the features just don't seem compelling enough to move away from their existing native app.
am i using the same clients as everyone here or do people just like complaining about electron at every opportunity?
the new client is actually much faster for me, it starts up faster (1.5s to show the gui fully loaded vs 4s to show the gui and another 3s to finish loading what's on the screen) and there's no lag when using it (unlike with the old client)
i also prefer the new ui, i find it to be clearer than the old one
GitHub desktop is designed for our non Linux users. We felt like you weren't comfortable with a command line so we targeted you. Minimum system requirements quad core CPU and 32GB of ram.
I for one always do my commiting and pull requests in the github app despite being able to use the command line. I love the way it shows me what’s changed, provides a nicer UI around selective commits (I prefer many small logically atomic commits), and then allows me to create a PR from inside (which the git client doesn’t). It’s also a nice way to view history and jump around in diffs.
Not sure why you’d bash it — the git cli is far from perfect and I for one welcome other perspectives on solving collaboration.
Now changing it to electron is another matter... I only have so much ram guys! With slack, Spotify, vscode, and a browser open on the same machine I’m screwed!
Making Git more accessible to non-developers (or people not comfortable with a command line) isn't some horrible thing like you're making it out to be.
Serious question...what use is git to a non-developer? I don't think I've ever used it for anything but code. You're not supposed to use it with huge files, so that kind of eliminates the one case I was thinking of (graphic design versioning).
Also if someone is a developer, they're only hurting themselves by not making an effort to get comfortable with the command line. Like half of my workflow wouldn't be possible without a familiarity with it.
Git-LFS lets you use it with large files, and even without Git-LFS you can still use it for smaller projects (it's not efficient at all, but for small teams and small projects you can do it).
Github is making a play to be the "Git for Everyone people". Note they call out that the new client has image diffs (great for... graphic design versioning).
They're forming a brand that could eventually compete with stuff like Perforce on a smaller scale with designers and artists if they can make them feel at home using "GitHub" (Git + creature comforts from GitHub).
And to the developer point, everyone starts somewhere. As a kid Git didn't click until I started using visual clients. And "the command line" is a huge surface to get comfortable with.
Out of curiosity I've downloaded the app and tried it, because everyone seemed to hate it. Bloated, slow, eats RAM like crazy they said. Everybody says it so it must be true, right?
No. I was expecting a disaster and instead I got a nice little Git client (not really feature packed, but the advertised features worked as expected). It starts quite quickly (compared to GitKraken for instance which takes ~10 seconds on my machine). UI is very responsive. After few minutes of usage ate 120 MB of RAM which is less than Sublime Text which I also had running in the background (and compared to more than 500 MB used by Slack, also an Electron app). At idle it uses almost 0% CPU.
I have to say, I'm a bit disappointed. I was under impression that HN was better than that - issuing judgements before actually trying the bloody app.
Edit: To clarify - I am using version 1.0.0, on macOS 10.12.
A lot of people HAVE tried the app. It's extremely noticeable and inferior in regards to UI performance. The 4GB comment also isn't an exaggeration if an electron app is left on for all day (slack, etc)
I left it running when I first wrote the comment. Went back to it just now, after nearly two hours, and the memory usage didn't increase. Still at 120-130 MB.
My guess is that compared to Slack, Github app doesn't really do much when idle. Slack fetches user statuses, new messages, notifications and so on. When you have an open channel with ongoing conversations that will add up in the RAM. This app doesn't seem to do anything when idle, so the RAM usage doesn't increase.
I think you missed the additional "Github Desktop Helper" processes that every Electron app spins up. In my case, the app eats 190MB just being there...without even adding a repo or authenticating a user.
I really really would not want to use a "productivity" type of application that is made in Electron but I also know that many people do not mind.
This said we are again in the era where it does not matter to most of the users. If it would people would stop using Atom/VScode and others. We all know that there is not a more cost effective way of building multiplatform apps (all things considered).
We will have to cope with this as long as there is not real competition.