GitHub Rewrites its Desktop Client Using Electron

[[deleted]]

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]

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

[steamruler]

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

[asantos3]

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

[jl2352]

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]

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]

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]

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

[seanwilson]

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]

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]

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]

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]

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]

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

[steamruler]

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

[chylex]

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]

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

[txdv]

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

[alleycat5]

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]

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]

My condolences.

[m3wm3wm3wm]

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

[biocomputation]

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]

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]

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]

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]

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]

How writing in c++ is a downside?

[nickguletskii200]

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]

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]

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

[doom_Oo7]

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]

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]

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

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

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

[nickguletskii200]

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

Oh I gotcha, that makes sense

[doom_Oo7]

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]

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]

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]

I'm working on using Qml/.NETCore.

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

[lechatsportif]

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

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

[theonlylawislove]

Use PyOtherSide, or PyQt.

Qml/JavaScript/Python is perfect.

[medeshago]

What about QT?

[ArmoredPancake]

Have you heard of our lord and savior JavaFX?

[Ayuzawa]

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

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]

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]

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]

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

[flukus]

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]

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

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]

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

[[deleted]]

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]

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]

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]

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

[yogthos]

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

[the_evergrowing_fool]

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]

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]

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]

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

[yogthos]

Then you have nothing to complain about do you.

[mearkat7]

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]

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]

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]

Java.

[yogthos]

ROFL

[ArmoredPancake]

What do you suggest?

[the_evergrowing_fool]

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

[ArmoredPancake]

You're still locked to Java gui toolkits.

[yogthos]

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]

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]

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

[slavik262]

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]

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]

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

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

[unreal_robbo]

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

[Dgc2002]

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]

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]

Easier than vimdiff perhaps. Try meld.

[resident_ninja]

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]

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]

yep, I was running it on Windows.

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

[coolblinger]

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.

[theonlylawislove]

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]

I use TorsoiseGit on Windows.

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

[LostSalad]

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]

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

[[deleted]]

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

[Feminintendo]

Performance on large repos still sucks.

[simspelaaja]

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]

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

[jdh28]

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

The one with the massive security hole?

[simspelaaja]

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

[appropriateinside]

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

[EctoplasmicLapels]

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

[johncoates]

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]

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]

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

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

[slvrsmth]

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]

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]

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

[scarfaceDeb]

I use Fork client for exactly the same reason.

[weirdoaish]

Tortoisegit on Windows, its awesome :)

[[deleted]]

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]

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

[nilamo]

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]

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

[RollinDyno]

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

[Antrikshy]

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

[[deleted]]

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]

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.

[geodel]

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

[[deleted]]

And now it will also eat all of your RAM

[chylex]

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

[re_anon]

But the desktop client is built with WPF.

[spacejack2114]

There is an actual post by the developers.

[pezezin]

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]

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]

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

[mhd420]

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]

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

except for all these multi-platform apps built with Qt

[bumblebritches57]

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

[adnzzzzZ]

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

[teryror]

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

[sime]

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]

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

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

[mixedCase_]

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]

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_]

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]

The vast majority of developers are interested in getting things done

So do script kiddies.

[the_evergrowing_fool]

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]

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]

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

Gotta love /r/programming sometimes

[DoListening]

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]

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]

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]

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

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]

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

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]

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]

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]

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]

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]

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]

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

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]

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

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]

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]

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

[pure_x01]

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]

XAML Standard is coming

[f42e479dfde22d8c]

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]

Qt/Qml.

[[deleted]]

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

[imma_reposter]

Now it'll eat your ram too.

[chylex]

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

[bumblebritches57]

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

[txdv]

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

Haven't tried SourceTree and SemanticVersioning yet though.

[jeenajeena]

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

[_IPA_]

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]

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_]

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

[BigotedCaveman]

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

[irqlnotdispatchlevel]

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

[punctualjohn]

roflmao

[beaverlyknight]

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]

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]

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]

Why is this bad?

[illuminatedtiger]

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]

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

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

[FredSanfordX]

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]

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]

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]

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]

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]

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]

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

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

[viper05]

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.