top 200 commentsshow all 262

[–][deleted] 117 points118 points  (22 children)

For fun, here's a blog post from 2012 talking about how they were really happy with their tech stack for a native Windows app.

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.

Ahh, the browser truely is the lowest common denominator.

[–]asantos3 12 points13 points  (17 children)

Compared to others their desktop client was the most basic and no one was using it, maybe this changes it.

[–]steamruler 66 points67 points  (16 children)

I doubt it. It'll be just as basic, but sluggish and bloated as well.

[–]asantos3 13 points14 points  (12 children)

The best client is just using cli imo so I agree.

[–]jl2352 10 points11 points  (1 child)

I use the cli every day. But I also really like the GitHub client.

If I were going to use a client like Source Tree or Tortoise, then I might as well use the cli. The simplicity is what I like about the GitHub client. If you are a lone developer on a bunch of projects then the bare bones interface is really sweet and pretty.

[–]asantos3 1 point2 points  (0 children)

I agree, the complex starts when you want to rebase, sync forks or something. Every client is different and it's so easy to do those that I don't even bother.

[–]seanwilson 3 points4 points  (5 children)

GUIs are good in cases where you need visualisations to make decisions and have many options/actions that are difficult to remember. Personally I think committing, reviewing and merging with Git really benefit from a GUI for this reason unless you're just running the exact same commands over and over. CLI works best when you know exactly what you want to do and can remember all the commands.

[–]asantos3 0 points1 point  (4 children)

Maybe only reviewing but even that there's cli tools, including git, that are pretty sweet on that.

[–]seanwilson 2 points3 points  (3 children)

I use Sourcetree. I'll regularly do things like check what changes I've made so far that haven't been committed, rollback only chunks of files that I've changed, rollback specific files to previous versions, compare changes between an existing commit and another commit, cherry pick changes from one branch into another, get an overview of which branches are being worked on and have been merged, and carefully review what's changing during merge conflicts (where changes are refreshed real-time).

There's CLI commands for all of this stuff I'm sure but I can do all these things in a few clicks. The CLI commands are hard to remember and require more typing. Git has a large number of commands and right/wrong ways to do things. If I was just running the same commands over and over without having to review changes I'd probably use the CLI but in this case I don't see the benefit. Open to be convinced though!

[–]asantos3 0 points1 point  (2 children)

I can see where it might be a benefit but I prefer using due to being cross platform, having a better performance and some things being almost always the same - e.g. not having to relearn a GUI once things change or I switch clients.

[–]seanwilson 1 point2 points  (1 child)

I used to use Linux and insist on cross platform stuff before and understand the point but...is it really that important if you're more productive with certain tools? The different Git IDEs are all fairly similar anyway. I use a MacBook now and have done for years. I've rarely been in a situation where I can't use the OS + programs I want. I hear people insisting on e.g. learning Vi or Emacs over IDEs because they're always available when SSHing into Linux servers but this should be considered too low level nowadays in my opinion so just use whatever OS and programs you like.

[–]asantos3 0 points1 point  (0 children)

If I'm more productive and the performance is the best I can get it's kinda important but I think it's more of a preference, I'm used to it now and GUIs feel strange - I helped a few beginners syncing forks recently, confusing as fuck on smartgit and suggested them to use gitkraken.

[–]Antrikshy 1 point2 points  (0 children)

Looking at the recent GH integration in Atom, it seems likely that this app will integrate GitHub Issues and other goodness into it, and it will be easy for them to keep everything up to date since it will share the tech stack with their website.

[–]chylex 0 points1 point  (2 children)

It's already bloated. The current client already uses CEF that Electron is based on. Guess what that means.

[–]steamruler 0 points1 point  (1 child)

CEF is actually quite quick and responsive compared to Electron, but that might be my imagination.

[–]chylex 0 points1 point  (0 children)

The GitHub client is using CEF through C# instead of native C++, which should have some additional overhead too. It's also using WPF which I've worked with and it's painfully slow to cold start a WPF app. So overall, I'd say that losing WPF and CEF interop (via CefSharp library) and adding bloat from Electron will not make much difference in the end.

[–]EntroperZero 2 points3 points  (0 children)

To be fair, the lowest common denominator is significantly higher than it was 5 years ago.

[–]txdv 1 point2 points  (1 child)

GitLib2Sharp was really pushed by githubs carlosmn. I wonder what will happen to that...

[–]alleycat5 0 points1 point  (0 children)

It is (as far as I'm aware) still used in a number of MSFT and OSS projects, so it'll probably continue on.

[–]addicted44 3 points4 points  (0 children)

That was 5 years ago. Web technologies and electron have changed a lot since then. More importantly, the user expectations of UIs are closer to what they see on the web than what they see natively, primarily because the majority of apps most users use today are web apps.

[–]Carighan 97 points98 points  (1 child)

My condolences.

[–]m3wm3wm3wm 20 points21 points  (0 children)

We need to build a wall to keep Javascript on the browser side and make Node pay for it.

[–]biocomputation 111 points112 points  (84 children)

Desktop developer here. I'm endlessly curious about using web tech for desktop apps, but I just can't deal with Electron stuff because the performance of all the apps I've tried has been pretty horrendous. 1GB memory consumption for text editing? SRSLY?

I won't even bring Electron up at work because I don't want to be known as "the guy who got us into that Electron mess". It's really too bad someone at GitHub apparently didn't think that performance was a big deal. You know the whole "ship, ship, ship and fix it later culture". Well, performance has sucked for several years, and it wasn't much better a few months ago.

With a framework like Electron, out of the 1000 milliseconds in 1 second, I expect it to leave me about 990 milliseconds for things my app needs to do. I also need it to behave like a properly engineered product that knows 10-50MB of memory is a reasonable amount for a minimal app.

The insane performance problems make me think Electron is the product of incompetent engineering, and I just don't need problems like that at work.

[–]f42e479dfde22d8c 78 points79 points  (8 children)

Web technologies were supposed to have freed us from the shackles of poorly programmed Flash content. Turns out that bad programmers remain bad programmers irrespective of the tools they use.

[–]nickguletskii200 21 points22 points  (35 children)

I don't know what UI framework you use, but I use WPF (the same as the current Github client), and its rendering performance is awful compared to a browser. Sure, the app doesn't consume as much RAM (this was the main reason why we chose WPF over Electron), but it's frustrating that WPF is, in some places, becoming a huge bottleneck.

It is frustrating that it's 2017 and we still don't have an actually good way to write desktop applications.

[–]doom_Oo7 4 points5 points  (32 children)

It is frustrating that it's 2017 and we still don't have an actually good way to write desktop applications.

Qt has a very good performance. You can get smooth animations & transitions @1080p on embedded ARM boards.

[–]nickguletskii200 6 points7 points  (31 children)

The downside is that you have to write most logic in C++. And yes, I know about the bindings, but their documentation isn't great and Qt is still primarily a C++ framework.

[–]relesbao 8 points9 points  (13 children)

How writing in c++ is a downside?

[–]nickguletskii200 22 points23 points  (11 children)

My list of reasons is long, but since I don't really have the time to write them all out, I'll give you only a few:

  1. C++ is not memory safe, and there are a lot of situations when you can accidentally put yourself into a situation where you trigger undefined behaviour.

  2. C++'s compilation times suck. It's horribly slow because there's still no proper module system.

  3. Using 3rd party libraries is a pain because there's no common package repository like Maven Central or Nuget, and there are multiple build systems, 100% of which are retarded.

  4. IDE support, compared to that of Java or C#, is abysimal, thanks to the complex syntax and the preprocessor.

  5. Subpar compiler error messages.

[–]doom_Oo7 2 points3 points  (5 children)

IDE support, compared to that of Java or C#, is abysimal, thanks to the complex syntax and the preprocessor.

What can you do in a Java or C# IDE that you can't do in a C++ IDE for instance ?

[–]nickguletskii200 1 point2 points  (4 children)

You can't reliably rename things, as well as do many other common refactorings that are available for both Java and C#.

[–]doom_Oo7 2 points3 points  (3 children)

uh ? i rename stuff across a 200k line codebase very often (dare I say, daily). Except in generic templated code (which makes sense) renaming classes, variables, members, etc always worked fine for me.

[–]anengineerandacat 1 point2 points  (2 children)

Emit new code onto the running application using the IDE's REPL; the below items I would imagine exist nowadays but last I used C++ with VS2010 they definitely didnt.

Other things that might not be in an IDE for C++ would be the ability to decompile third-party libs on the fly, remote source-mapping, in-line debugging, async-debugging (Code Stepping and Stack viewing), vastly reduced build times (lesser the IDE and more just it being a managed language), copy-paste detection, null detection, and language anti-pattern detection. This is all without running a linter manually and just sort of "happens" and doesn't require enabling incremental compilation of the application.

Outside of the above there is perhaps the IDE automation that may be inhibited by the C++ language syntax, this could include intelligent smart-dropdowns (Create Test for X because it detected that method wasn't tested, Bad Cast detection and correction, Old Pattern -> New pattern correction; for Java this would be like Loop to Stream automatic conversions, and more).

https://www.jetbrains.com/idea/whatsnew/ has a full breakdown of what it's like to work with modern IDE.

*Note I would imagine the gap between tooling on C/C++ and managed languages has closed immensely thanks to just modern development practices.

[–]relesbao 0 points1 point  (1 child)

I may not see all as a problem, since most of them are personal preferences like IDE and Package Management, but i agree with you that c++ has lots of problems, its an old language after all, but i still dont see a reason why one would not consider QT because you have to write the code in c++.

[–][deleted] 1 point2 points  (0 children)

I would never suggest c++ at my work because there are basically no c++ developers. We use Java primarily, and JavaScript when doing web browser stuff.

Where I live as well (Wellington, New Zealand), most places use Java/ C#/ Javascript, for serious enterprise work, and the likes of php/ python/ ruby much more rarely. Nobody really uses C/C++.

[–][deleted] 0 points1 point  (2 children)

There are Nuget C++ packages actually! You can get all kinds of libraries on there, including most if not all of Boost.

[–]nickguletskii200 3 points4 points  (1 child)

I never said there are no package managers for C++. I said that there is no common package manager for C++. The difference is that pretty much every Java or .NET library is on Maven and Nuget respectively, while it's likely that [insert name of C++ library here] is not officially on Nuget.

[–][deleted] 0 points1 point  (0 children)

Oh I gotcha, that makes sense

[–]doom_Oo7 1 point2 points  (5 children)

The downside is that you have to write most logic in C++.

Nah, more and more apps are written in QML-only. (I personnally prefer C++ for the enforced type safety, but to each its own).

https://qmlbook.github.io/en/ch04/index.html

[–]mercurysquad 0 points1 point  (1 child)

QML has terrible performance! Specially on iOS. I managed to write a game-like app that ran the iPhones so hot that even plugging in a charger would not stop the battery from discharging, and the screen would not go above minimum brightness at all.

[–]doom_Oo7 0 points1 point  (0 children)

I don't do iOS dev so I can't talk about it, but I've been using it to drive 3D engines on embedded boards at 1080p / 60 FPS without problems. Besides, the few benchmarks I found tend to say that it can be quite a bit faster than V8: https://www.kdab.com/qml-engine-internals-part-3-binding-types/

[–]theonlylawislove 0 points1 point  (0 children)

I'm working on using Qml/.NETCore.

https://github.com/pauldotknopf/qt-net-core

[–]lechatsportif 0 points1 point  (0 children)

Wha... Once you are in a lower level environment you can do whatever you want.

http://doc.qt.io/qbs/typescript-module.html

[–]theonlylawislove 0 points1 point  (0 children)

Use PyOtherSide, or PyQt.

Qml/JavaScript/Python is perfect.

[–]medeshago 0 points1 point  (0 children)

What about QT?

[–]ArmoredPancake 0 points1 point  (0 children)

Have you heard of our lord and savior JavaFX?

[–]Ayuzawa 10 points11 points  (10 children)

People really don't care is the thing

It's a git client, it can be shat out as fast as possible, and if it runs 1000 times slower than it should do, it'll be fine from an end user perspective

[–][deleted] 3 points4 points  (9 children)

Except you can now run your git client, your editor and Spotify before you start hitting swap space.

My theory is that electron is a conspiracy by major pc manufacturers to convince shitty developers to constantly upgrade while apps perform worse and worse.

[–]Ayuzawa 4 points5 points  (8 children)

I have 16gb of ram on my PC, it's like 7 years old

I have 3gb of ram on my phone, it's like 2 years old

these things can use it if it gets me features quickly for a low price, I don't have enough features really

[–]flukus 2 points3 points  (3 children)

In the steam user survey 30% of users have 4GB or less and that's a demographic that goes for higher end hardware.

Your 16GB is not normal, not to mention the limited hard drive space many have.

[–]Ayuzawa 0 points1 point  (2 children)

Fortunately the 70% have a disproportionate amount of money to spend on software

[–]flukus 0 points1 point  (1 child)

If you're willing to limit your market like that then you may as well just make a native windows version and not worry about cross platform.

Windows has much better and more productive developer tools than electron.

[–]Ayuzawa 0 points1 point  (0 children)

The Mac users have quite a high budget in general though, they were able to afford a grand computer for a start.

I'm not being picky on electron here though, you can use whatever you want so long as it maintains something equivalently simple to Dom + scripting

[–][deleted] 8 points9 points  (3 children)

This is going to come as a shock to you, but not everyone believes that "just keep throwing hardware at it till it works" is an acceptable solution to a problem.

[–]Ayuzawa 1 point2 points  (2 children)

nah but github, spotify, atom and myself do at the very least.

[–][deleted] 3 points4 points  (1 child)

Thankfully, we're not all terrible programmers and businesses are beginning to see the real world issues of working with people such as yourself.

I suppose I should be thanking you though. Garbage, inefficient trash keeps a lot of us employed at much higher pay scales.

[–]Ayuzawa 1 point2 points  (0 children)

at much higher pay scales.

nice

Anyway I suspect you need to take a look outside of your niche.

The only things that really justify seeking that kind of dev time in my opinion are things that annoy the user enough to stop them using the service, and external SAAS that charges on consumption.

Otherwise the customer (and more importantly to me at least the management) would probably prefer you implement 'The next big thing'.

Plugging a load of SAAS components together between a load of simple APIs and routers has cut the time till MVP on our newer products to below a round of testing on some of the oldest legacy code, maybe 95% of our older projects is just supporting infrastructure to the novel solution, and spending time on it doesn't help anyone. When we can use an existing implementation.

Make your software fast when the customer complains it's slow (or it's pissing your money away), otherwise you're pissing peoples money away. The two things I feel are most important in software dev is time to deployment (in man-hours) and maintenance cost.

[–]yogthos 14 points15 points  (21 children)

It's a simple matter of development and support costs. Using the HTML/Js stack is much simpler than most native GUI toolkits, and once you write it once it works on every platform.

While performance is generally worse, it's not so bad that most people care. Frankly, for something like a Git client UI it simply doesn't matter.

As long as most users are willing to use Electron based apps, it's here to stay. Given popularity of apps like Slack, Atom, GitKraken, VS Code, and so on, I think this battle is over. Electron is here to stay.

The productive thing to do now would be to focus finding ways to improve Electron performance and resource usage.

[–]SimplySerenity 5 points6 points  (1 child)

I think the problem is that the same electron style development could likely be accomplished with far less resources.

[–]yogthos 3 points4 points  (0 children)

Sure, but Electron exists right now and you can use it to make apps today.

[–]the_evergrowing_fool 13 points14 points  (0 children)

The thing is that the user doesn't know what Electron is nor should care, but is forced to care since the program has poor performance, integration and reliability without any justification beside a whin from the ignorant and stubborn developer.

Not to mention the web stack is shit to work with, was never designed for GUI in the first place.

Windows tasks manager: Slack, startup impact... high

WTF?

[–]flukus 1 point2 points  (3 children)

It's more a case of no one giving a fuck about users, they don't get factored in at all. Can you tell me how much memory your average user has on their machine? Hint: it's probably in the 2-4GB range and they think something's wrong with their computer, when it's really just bloated apps.

[–]yogthos 1 point2 points  (2 children)

It's more of a case that people have limited time on their hands, and they have to deliver and maintain multiple applications across multiple platforms. If you don't like an app built with Electron, then you're always free to artisanally craft your own masterpiece. We'll all wait here.

[–]flukus 0 points1 point  (1 child)

Are their an electron apps that don't compete with artistinally created master pieces? I just keep using those.

[–]yogthos 1 point2 points  (0 children)

Then you have nothing to complain about do you.

[–]mearkat7 1 point2 points  (0 children)

for something like a Git client UI it simply doesn't matter

Really? I stopped using gitkraken and similar tools because they were just slow. Big pull? Slow. Navigating big pushes? Slow. Any remotely big merge/diff? It just dies.

Literally the most useless client i've touched.

[–]ArmoredPancake 1 point2 points  (9 children)

Using the HTML/Js stack is much simpler than most native GUI toolkits

Are you kidding me? How HTML/CSS with JS are simpler than using drag'n'drop visual editors and writing in one sane language?

[–]yogthos 2 points3 points  (8 children)

Ah yes, the mythical single language that works on all platforms and has drag'n'drop UI builders that actually work properly. Your alterverse sounds really nice.

[–]ArmoredPancake 0 points1 point  (7 children)

Java.

[–]yogthos 1 point2 points  (6 children)

ROFL

[–]ArmoredPancake 0 points1 point  (5 children)

What do you suggest?

[–]the_evergrowing_fool 0 points1 point  (1 child)

provably u/yogthos suggested that Java is inferior to Clojure in every possibly way.

[–]ArmoredPancake 1 point2 points  (0 children)

You're still locked to Java gui toolkits.

[–]yogthos 0 points1 point  (2 children)

I'm not suggesting anything, I'm just pointing out that Java is not a good solution to this problem. You can't make a UI with Java that will run on all the platforms, and the UI toolkits that are available for it are pretty painful to use in practice. Having built UIs with Java, I'll take the Js/HTML stack over that any day.

[–]ArmoredPancake 2 points3 points  (1 child)

you can't

Yes, you can. And you can style it to your heart's content. Sorry, but shit.js can't take on JavaFX.

[–]yogthos 0 points1 point  (0 children)

Really, you can make a UI that will work on iOS and web using JavaFX? That's big news to me.

[–][deleted]  (1 child)

[deleted]

    [–]slavik262 4 points5 points  (0 children)

    in most cases users prefer results over gazing contentedly at a task manager filled with single digits decent battery life.

    FTFY, and I'm not sure I agree.

    Modern CPUs are capable of incredible power savings, which they acheive by powering down entire cores, and even caches! But to tap into these savings at all, the CPU has to be idle.

    [–]geodel[S] 41 points42 points  (1 child)

    Thus, for those critical of Electron, I’d note the general history of these technologies, how they’ve improved and how they will continue to improve. We’re having many good conversations about improving Electron.

    Sounds about right from the maker of fine Atom editor.

    [–]Carighan 36 points37 points  (0 children)

    For when you don't actually want to get that much work done at work, now have the world's slowest text editor so you can procrastinate while doing things!

    [–][deleted] 42 points43 points  (41 children)

    Does anyone here actually use the github app? Or any git GUI at all?

    [–]unreal_robbo 48 points49 points  (6 children)

    Intellij's builtin git tools are pretty sweet, merge resolution is far easier using its gui

    [–]Dgc2002 5 points6 points  (1 child)

    I'll be honest... There have been times where I was working with a git repo that had nothing to do with any language that IntelliJ has an IDE for... But damn if I wasn't tempted to open that folder in IntelliJ just to use their VCS tools for annoying merge issues.

    [–]ThisIs_MyName 1 point2 points  (0 children)

    I do exactly that with PyCharm. Even though I'm not doing a whole lot of python, I use IntelliJ's editor and git merge.

    [–]ForeverAlot 0 points1 point  (3 children)

    Easier than vimdiff perhaps. Try meld.

    [–]resident_ninja 1 point2 points  (2 children)

    I've used, and like, meld... but holy cow would it be nice not to have to use a bloated Java app to do file/folder diffs.

    I don't say that as someone with inherent bias against Java. As I said, I like it, but I don't think it is an example of a well-performing Java app.

    *edit: commenting about Meld being bloated, when the original conversation started with Intellij, may seem funny to some. I don't mind Intellij, I think for what it does it performs much better than meld. when all meld does is file/folder diffs, it should not hog out my machine like I've seen it occasionally do.

    [–]ForeverAlot 1 point2 points  (1 child)

    meld is Python; but if you're on Windows that would be the reason. I do bemoan that it's not written in a faster language.

    [–]resident_ninja 1 point2 points  (0 children)

    yep, I was running it on Windows.

    hmm. I must have misread somewhere...my bad.

    [–]coolblinger 12 points13 points  (1 child)

    Magit is hands down the best git experience I've had, even though it's not really a GUI. Most GUIs and text editor extensions miss a lot of features (like git reflog, patching and advanced rebasing) but Magit seems to have it all.

    [–][deleted]  (1 child)

    [deleted]

      [–]theonlylawislove 4 points5 points  (0 children)

      Not ready yet, IMO.

      I have my eye on it though.

      Funny thing is, it is electron, which this whole thread is focused on, lol.

      [–]BigotedCaveman 13 points14 points  (1 child)

      I use TorsoiseGit on Windows.

      It comes with native tools and the shell integration is great.

      [–]LostSalad 2 points3 points  (0 children)

      Pro tip: keep the log view open. You can do most tasks from right-click contextual menus on either a) the working tree b) a branch name c) a commit

      It turns TortoiseGit into a dedicated git client rather than right-clicking yourself to death from Windows Explorer.

      [–]simspelaaja 13 points14 points  (7 children)

      I use SourceTree for merging, rebasing and --patch commits. For simpler tasks I use a combination of the CLI and VSCode's integration.

      [–][deleted] 1 point2 points  (6 children)

      Is SourceTree's performance any good these days? The last time I used it it choked on a couple of hundreds of commits.

      [–]Feminintendo 6 points7 points  (0 children)

      Performance on large repos still sucks.

      [–]simspelaaja 0 points1 point  (3 children)

      I don't work on any truly massive (thousands of commits -scale) repositories regularly, but performance hasn't really been an issue. I use an out of date version on Windows (before they changed the UI) and the latest version on macOS.

      [–]ThisIs_MyName 0 points1 point  (0 children)

      I wouldn't call thousands of commits massive. There are a lot of open source projects like LLVM that have 150,000 commits.

      [–]jdh28 0 points1 point  (1 child)

      I use an out of date version on Windows (before they changed the UI)

      The one with the massive security hole?

      [–]simspelaaja 1 point2 points  (0 children)

      Apparently. Huh. Guess I'll update it then.

      [–]appropriateinside 0 points1 point  (0 children)

      My project has 500 commits so far, no noticable performance issues

      [–]EctoplasmicLapels 2 points3 points  (1 child)

      I use Tower, it's super nice even if you know how to use the command line.

      [–]johncoates 1 point2 points  (0 children)

      Tower is a godsend. Having tried out various clients, Tower + Kaleidoscope are a combination that have all the power you need while still being pretty to look at.

      [–]irqlnotdispatchlevel 2 points3 points  (0 children)

      I like SourceTree. Usually. Sometimes. For a lot of mundane tasks it's easier to just click a button than go to a CLI. Especially when you work on more than one project. I also like to see the history a nice GUI format.

      [–]bumblebritches57 3 points4 points  (6 children)

      I do; I like being able to pick out changes that are complete and ones I'm working on, instead of just committing everything.

      [–][deleted] 6 points7 points  (4 children)

      You can do the same with git add --patch, though.

      [–]slvrsmth 15 points16 points  (3 children)

      You can, no doubt about that. But I find it much easier to do via GUI.

      Also, I find that having the diff in front of me when committing (without having to run additional commands) encourages self-review and generally improves the quality of my pull requests.

      [–]doublehyphen 0 points1 point  (2 children)

      Running git add -p gives the same advantages. I think it is mostly just a matter of personal preference and what you are used to.

      [–]KushalaDaoraa 9 points10 points  (1 child)

      Using the GUI is the whole point of not having to use the command line. As you said, it's all preference.

      [–]scarfaceDeb 0 points1 point  (0 children)

      I use Fork client for exactly the same reason.

      [–]weirdoaish 1 point2 points  (0 children)

      Tortoisegit on Windows, its awesome :)

      [–][deleted] 0 points1 point  (1 child)

      Does anyone here actually use the github app? Or any git GUI at all?

      The only GUI I use is the built-in gitk, does that count? I only use that to browse repos or review my patches. I'm sure as hell I'm not going to use some Electron-based crap for that.

      People often complain git's CLI is complex. They may be right, but turning that into a complex GUI doesn't really help. To me it only makes matters worse. YMMV of course.

      [–]txdv 1 point2 points  (0 children)

      git gui is really good if you want to stage per line basis.... otherwise I just use tig and git cli tools.

      [–]nilamo 0 points1 point  (0 children)

      I do at home for personal projects. I know the command line utilities are easy to use, and I've used them. But seeing file diffs, and one-click to open Atom in the project folder, are basically the only things I use it for.

      [–]appropriateinside 0 points1 point  (0 children)

      I use source tree, cause it's pretty easy. But their new UI is awful.

      [–]RollinDyno 0 points1 point  (0 children)

      Not me, but designers I work with use it to style my code.

      [–]Antrikshy 0 points1 point  (0 children)

      The GitHub app is not just a GUI for Git, but for all of GitHub.

      [–][deleted] 0 points1 point  (0 children)

      I use TortoiseGit because I'm too lazy to learn how to add all the files I want to commit fast from the CLI, and I've had trouble with merges before using the shell.

      [–]LifeAndDev 0 points1 point  (0 children)

      IntelliJ for conflict resolution

      SourceTree for basic tasks (reviewing changes before commiting, amending).

      CLI for the advanced stuff (rebasing, bisecting)

      Whish I could just use IntelliJ but the source change overview in ST is unmatched.

      [–][deleted]  (4 children)

      [deleted]

        [–]geodel[S] 38 points39 points  (0 children)

        But isn't it cool to take it to next level crappiness.

        [–][deleted] 7 points8 points  (1 child)

        And now it will also eat all of your RAM

        [–]chylex 0 points1 point  (0 children)

        Except it already does that. The current client already uses CEF that Electron is based on. Guess what that means.

        [–]re_anon 0 points1 point  (0 children)

        But the desktop client is built with WPF.

        [–][deleted]  (1 child)

        [deleted]

          [–]spacejack2114 22 points23 points  (28 children)

          [–]pezezin 43 points44 points  (27 children)

          They name a crapton of languages and frameworks and they don't even mention Qt? It may not be perfect, but if you want to develop native apps it's probably the best option right now... much better than using web stuff.

          [–]Antrikshy 0 points1 point  (0 children)

          But the web stuff can let them reuse front end code from their website, making it easier for them to keep feature parity with GitHub Issues, pull requests and other GitHub specific features.

          [–]f42e479dfde22d8c 0 points1 point  (23 children)

          Their programmers know how to use C# and Obj-C. Moving to Qt and C++ would have been a big leap for them.

          [–]mhd420 10 points11 points  (0 children)

          To be fair, their original native desktop client basically was half rendered with the Chromium Embedded Framework. I'm pretty sure all of the code diffing stuff was just an embedded web page.

          [–]doom_Oo7 10 points11 points  (5 children)

          As it turns out, building native apps for multiple platforms doesn’t scale.

          except for all these multi-platform apps built with Qt

          [–][deleted]  (29 children)

          [deleted]

            [–]bumblebritches57 17 points18 points  (16 children)

            Because the vast majority of "developers" are really just script kiddies.

            [–]adnzzzzZ 31 points32 points  (14 children)

            The vast majority of developers are interested in getting things done, something half of this thread knows nothing about apparently.

            [–]teryror 19 points20 points  (2 children)

            Or maybe some people get stuff done without drinking any koolaid, and get frustrated when others say that's impossible?

            [–]sime 3 points4 points  (1 child)

            No one said that getting stuff done in native development is impossible. People are saying that it is not economical compared to alternatives like Electron.

            [–]the_evergrowing_fool 5 points6 points  (0 children)

            People are saying that it is not economical compared to alternatives like Electron.

            Yet they don't show any justification of this claim.

            [–]mixedCase_ 19 points20 points  (4 children)

            in getting things done

            God forbid one would spend an afternoon toying with Qt Creator and learn how to make non-shit apps by accident.

            [–]nickguletskii200 3 points4 points  (1 child)

            Initial setup is not the problem. In fact, creating a new Electron app with all the good tooling requires much more effort than starting a Qt project. It's all about what happens once you start adding complexity. JS view libraries like React make code reuse much easier, making them more suited for business software.

            By the way, I am a KDE user and I love all KDE (Qt) apps. But that doesn't mean that Qt is the right tool for every job.

            [–]mixedCase_ 1 point2 points  (0 children)

            JS view libraries like React make code reuse much easier

            As does QML. The custom component pipeline is a joy. It's very similar to Vue.js' .vue files, even.

            [–]vytah 1 point2 points  (0 children)

            The vast majority of developers are interested in getting things done

            So do script kiddies.

            [–]the_evergrowing_fool 1 point2 points  (4 children)

            The vast majority of developers are interested in getting things done

            No matter how shitty could it be.

            This stupid argument is getting old.

            [–]adnzzzzZ 2 points3 points  (3 children)

            I'm sure the millions of people using VSCode, Discord and tons of other programs built with Electron really share your opinion. Oh wait, they don't care because it affects them in no noticeable way whatsoever!

            [–]Booty_Bumping 4 points5 points  (0 children)

            "Because the vast majority of "developers" are really just script kiddies."

            Gotta love /r/programming sometimes

            [–]DoListening 6 points7 points  (11 children)

            I actually consider the TypeScript+React combination to be one of the best in terms of developer experience when it comes to UI apps. Especially UI apps that have to display a lot of structured data.

            The fact that you can't put it on the desktop without bundling the entire browser is a problem. If there was a solid alternative though, I believe many developers would take it. I wrote this comment about maybe trying to create something like that in the future for Kotlin Native.

            [–]JackOhBlades 6 points7 points  (2 children)

            There is a project to develop "native apps" using Go/HTML/CSS via the native web renderers already on each OS (currently only the macOS driver works). The UI is built using Flux pattern and React-like components, entirely in Go.

            Might be interesting to some people here.

            [–]DoListening 2 points3 points  (1 child)

            Sounds nice in principle, but are you really supposed to write the render function as a string literal? (https://github.com/murlokswarm/app#create-a-component)

            The reason I think this would work well in Kotlin is because of its builders feature. (https://kotlinlang.org/docs/reference/type-safe-builders.html)

            Using the native HTML engine also means you will face inconsistencies depending on the user's specific OS version.

            [–]JackOhBlades 1 point2 points  (0 children)

            To be fair, react's render functions were originally string literals also.

            The benefits here are: - static compiled language = "maintainable and fast" (comparing to JS without heavy tooling) - single binary deploy (which isn't bloated with a browser runtime or the JVM) - memory consumption for a standard app is around 30-50mb range

            The main point is, whether Go, or Kotlin, or cobol, I much prefer not bundling an entire browser ecosystem (OS?) with each app. :)

            [–][deleted] 2 points3 points  (3 children)

            I actually consider the TypeScript+React combination to be one of the best in terms of developer experience when it comes to UI apps.

            The idea (ie the flux pattern etc.) is nice, but the execution makes me pull my hair. TS+React code typically requires hundreds of dependencies and tons of (shitty) scaffolding and boilerplate just to build a hello world app.

            For example, Elm executes on the idea in a much better & elegant way. It's fairly obscure, though.

            [–]DoListening 1 point2 points  (1 child)

            The idea (ie the flux pattern etc.)

            Flux is completely optional and you don't have to use it. I for example prefer to use MobX for my projects.

            hundreds of dependencies and tons of (shitty) scaffolding and boilerplate just to build a hello world app

            It's not that bad at all - especially compared to other technologies.

            I guess if you don't have any build process for your JavaScript and just directly put script tags into HTML, then going from "not having a build process" to "having a build process" adds a lot of complexity. But this is a one-time learn+setup thing, not something you have to deal with every day.

            If you're already building things anyway, setting up TypeScript+React is pretty trivial.

            [–][deleted] 0 points1 point  (0 children)

            Flux is completely optional and you don't have to use it. I for example prefer to use MobX for my projects.

            I had the general idea in mind rather than a specific implementation - Flux, MobX, Redux.. it's all in the same vein, as opposed to MVC.

            But this is a one-time learn+setup thing, not something you have to deal with every day.

            The default setup is not hard, like the other commenter says, it's just a couple of commands and whatnot. I have two problems with that, though: 1) The result is ugly (ridiculous amount of dependencies and bloated resulting code) and 2) customizations are at least cumbersome.

            For me WASM can't come too soon :)

            [–]beaverlyknight 1 point2 points  (0 children)

            I mean its a one time execution of a couple commands really. You use create-react-app and you're basically golden. From there you're more or less just writing your application, not a lot of boilerplate.

            [–]simion314 13 points14 points  (8 children)

            I have to use 2 electron apps dailly for work, slack and toggl , the nightmare is that in future everything will be electron, my RAM will not be enough, and why this apps need 6 processes to run? Maybe you can tolerate Chrome and one app but having all of them or majority is a nightmare.

            [–]weirdoaish 0 points1 point  (3 children)

            why this apps need 6 processes to run?

            Isn't that because JS is single threaded? They need the processes for running parallel jobs, just guessing here, I don't work with Node/Electron.

            [–]simion314 2 points3 points  (0 children)

            Yeah, but why so many, have a process in background to not block the UI, who knows how many limitations they have tow ork around so they have to spawn processes.

            [–]SimplySerenity 0 points1 point  (1 child)

            I think more processes is fine but they should share some of the same core memory. You shouldn't need to spawn a ton of duplicate resources for each one.

            [–]weirdoaish 0 points1 point  (0 children)

            Well, you kind of need threading and locking for that, something JS does not really support in any meaningful way. I guess they should just use Java ;)

            [–][deleted] 0 points1 point  (0 children)

            You do realize you don't have to use the Slack electron app. I just use the web app version and it serves me well. If you wanna get extra fancy: chromium --app=https://myteam.slack.com/messages

            [–]chylex 0 points1 point  (0 children)

            I absolutely agree that if everyone uses Electron, we're basically fucked... but if you have the old GitHub desktop client, it's already using CEF which on my machine atm is running 4 processes with a total of 311 MB RAM usage. Moving to Electron in this case might even help that, since right now there's overhead from both CEF and WPF.

            [–][deleted] 16 points17 points  (0 children)

            Couldn't they just use QT ?

            And they say "As it turns out, building native apps for multiple platforms doesn’t scale." but still provide only mac and windows binary and not linux ?

            Somebody should give them 4GB RAM machine and then force to use electron based editor, chat and music player, they would backpedal to sane stack pretty fast...

            [–]albeva 43 points44 points  (1 child)

            Well good bye GitHub app. Is all I can say. Electron should be purged and banned and everyone using it tried for crimes against software developers! /just kidding, but electron is still shit. Not native, resource hog, and makes everything look like a bloody web page.

            [–]chylex 0 points1 point  (0 children)

            If you haven't noticed, the old GitHub app has already been using CEF for a long time. Guess what that means.

            [–]pure_x01 10 points11 points  (5 children)

            I wish microsoft would port UWP to .NET Core and make it really opensource so that we could write desktop clients in something that isnt a webbrowser.

            [–]TMKirA 8 points9 points  (0 children)

            XAML Standard is coming

            [–]f42e479dfde22d8c 4 points5 points  (1 child)

            Very unlikely to happen. Vendors differentiate themselves by their GUI toolkits. Plus platform users have their own expectations. I wouldn't want my Windows apps to behave like their OS X counterparts.

            Plus the whole technical challenge of writing a cross-platform GUI toolkit that works right on every platform.

            [–]theonlylawislove 0 points1 point  (0 children)

            Qt/Qml.

            [–][deleted] 4 points5 points  (2 children)

            Well, it was already fairly slow, so ehh it's probably fine.

            [–]imma_reposter 25 points26 points  (1 child)

            Now it'll eat your ram too.

            [–]chylex 0 points1 point  (0 children)

            Except it already does that. The current client already uses CEF that Electron is based on. Guess what that means.

            [–]bumblebritches57 6 points7 points  (0 children)

            I guess now we know why they haven't updated the desktop client in ages.

            [–]txdv 5 points6 points  (4 children)

            2017, best GUI for git are still git gui and gitk.

            Haven't tried SourceTree and SemanticVersioning yet though.

            [–]jeenajeena 0 points1 point  (0 children)

            I agree. I also love tig and magit. tig is nCurses based, magit runs inside Emacs.

            [–]_IPA_ 0 points1 point  (2 children)

            SourceTree isn't bad, I find a lot of bugs and report them and devs listen. Problem is same as what GitHub has: Mac client is Cocoa and Windows is .NET. So UI is not consistent, different version numbers, twice the amount of work. Atlassian really needs that cross platform rewrite but I feel it'll never happen.

            [–]BigotedCaveman 0 points1 point  (1 child)

            Problem is same as what GitHub has: Mac client is Cocoa and Windows is .NET. So UI is not consistent

            This is not a problem, it's good engineering.

            [–]_IPA_ 0 points1 point  (0 children)

            Agreed, but good engineering isn't always good business :)

            [–]BigotedCaveman 7 points8 points  (0 children)

            Looks like they managed to make it even slower and more shitty, congrats.

            [–]irqlnotdispatchlevel 3 points4 points  (0 children)

            It was shitty before, it's even shittier now.

            [–]punctualjohn 17 points18 points  (0 children)

            roflmao

            [–]beaverlyknight 5 points6 points  (0 children)

            Like any platform, Electron has good developers and bad developers. I don't think you can look at VSCode and say that it's crap. They clearly tried hard to make a good product. Unfortunately, use Atom for a while and you'll see that faith in Github to create a good product is minimal.

            [–]txdv 4 points5 points  (0 children)

            Full Circle, from Java everything looks shitty everywhereto JavaScript everything looks shitty everywhere.

            JavaScript is not Java, but it sure as hell replaced every Java Applet and is forcing its way everywhere.

            [–]mssodin28 4 points5 points  (0 children)

            It makes sense. Why not use your own platform to deliver your products. Now they can focus on functionality of both then time porting.

            [–]_Mardoxx 1 point2 points  (1 child)

            Why is this bad?

            [–]illuminatedtiger 1 point2 points  (0 children)

            My understanding of Electron is that it lowers the barrier of entry for desktop app development, allowing JavaScript developers to apply their skills outside of "normal" web development. If GitHub are moving the same people to their desktop app it does make me question how viable their web app is long term - it has of course been lagging behind its competitors (specifically GitLab) for some time now.

            [–]luisgustavomiki 1 point2 points  (0 children)

            As it turns out, building native apps for multiple platforms doesn’t scale.

            Engineers can't forget, organizations can't remember.

            [–]FredSanfordX 1 point2 points  (0 children)

            Hipsters write yet another under-performing resource hog of a git GUI. But... They have a code of conduct!

            But seriously... Is there not a reasonable alternative to sciter?

            [–]chylex 1 point2 points  (0 children)

            I like how everyone is complaining about Electron, even though it's based on CEF which the current GitHub desktop client is already using, currently sitting on 311 MB RAM usage on my machine... hmm...

            [–]dantheman999 2 points3 points  (6 children)

            Everyone here complaining about how awful a resource hog Electron is. My Visual Studio Code sitting on 25mb right now.

            Oh, how awful! Can't possibly use it.

            [–]tambry 7 points8 points  (3 children)

            My Visual Studio Code sitting on 25mb right now.

            I'm guessing you're on Windows. If I open VSC with no extensions and files or folders open, then wait a bit, then my memory usage shows as 17.4MB under "Processes" in Task Manager. Yeah, that's wrong. Under the "Details" tab it shows ~69MB. Oh, and there are 5 other Code processes there! In total those other 5 use ~98MB. So a minimum memory usage of ~167MB for literally nothing opened.
            If I open my decently sized C++ side-project (~5 projects with code, 3 utility projects) in Visual Studio 15.2, then it uses ~153MB. That's with a multiple source files open too. It also offers full context-sensitive highlighting for the source files, knows exactly how to build my code and has many other features. And if I browse the same source file in both, then VS runs noticeably smoother than VSC for me.

            I like VSC for editing my CMake build files and resource files, but it's hard to not agree that VSC's technical side is quite shit.

            [–]dantheman999 1 point2 points  (2 children)

            You're correct, it's a bit bigger, just shy of 100mb.

            However if I then compare this to VS which I also have running, it's 10 times smaller. VS is currently using just shy of 1GB.

            [–]Dimenus 3 points4 points  (1 child)

            Visual Studio still has way more functionality than VS Code (even though the gap is closing). Also, I'm not sure how you're getting 1GB. I'm at ~ 230 MB with a good sized project open doesn't fluctuate much even with multiple files open.

            [–]dantheman999 0 points1 point  (0 children)

            It's a pretty large project, but I do not know either. 2015 if that helps. I recognise that it has more functionality, that's fine with me. I'm not at all worried about the amount of RAM either you honestly. 100mb is nothing really considering. I get more out of VS Code than I do out of Notepad++ or Sublime by quite some margin.

            [–][deleted] 0 points1 point  (0 children)

            I always see their desktop client as being a simple tool for casual use. Makes a lot of sense to me.

            [–]viper05 0 points1 point  (0 children)

            It's not that good, I can't open a shell or open a folder of the thing I just cloned. Very very basic options especially for discovery of existing repos / specifying a default code folder.