15 ms·

How Four Native Developers Wrote an Electron App

119 points by joeyespo 9y ago

murukesh_s 9y ago
I think this is great, especially for the electron ecosystem as github engineers are directly involved in making production apps on the stack(other than atom) The cross platform advantage(time & maintenance effort) that electron gives is immense. The overhead is very minimal and we can build some great apps like vscode and the likes have shown.
- devwastaken 9y ago
  >The overhead is very minimal You're still using JS, unless you're compiling modules for node.js.
  - murukesh_s 9y ago
    I find node.js pretty fast. The V8 engine does compile it to native during the run time using a JIT compiler. While it is not quite up to the level of java, it is comparable. The major lacking is no thread support, but it is a boon in many cases as tracking down runtime bugs in multi threaded environments is sometimes very tough. Threads can be simulated using child processes to some extend, but its the only major drawback as far as i have encountered.
    - GRiMe2D 9y ago
      While nodejs is fast enough, Electron and apps built on it aren't fast. Electron is a mix of Chromium and nodejs. Chromium's rendering isn't meant to be used as desktop app. Especially for laptops. I have a MacBook pro mid 2010 with two GPUs. Integrated GPU uses less battery energy than discrete one. And every Chromium app switches GPU to discrete one and causes battery drain.
      - dragonwriter 9y ago
        > Chromium's rendering isn't meant to be used as desktop app. Yes, it is. That was pretty much the entire point of Google making Chrome (to make web apps have acceptable parity with desktop apps), and the entire premise of them building on Chrome with ChromeOS. Now, it may not satisfy you in that role, but it absolutely is meant for it.
        murukesh_s 9y ago
        Good point. People are bashing Electron and chromium in general. But they do forget JVM based IDEs had the same problem. Rather than bashing Electron, if we can figure out to make it more leaner and faster, it would be much better.
        LeoNatan25 9y ago
        "We"? You mean people that know C++ and low level native APIs, right? Which is decidedly not you. You are building a "hackable" "node.js" "npm" "app". The problem is, people who are indeed capable of making some improvements, including people on the V8 and WebKit teams themselves, do not believe in what these tools attempt to accomplish. (Listen to Don Melton's interviews on the subject, for example.) I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.
- stephenr 9y ago
  > The overhead is very minimal Compared to what exactly? Because compared to an app built using the platform SDK's, Electron is never "minimal" in anything, except perhaps "integration" or "accessibility".
  - gjjrfcbugxbhf 9y ago
    Minimal regard for the users' system resources? Minimal chance of being used because the user notices their laptop grinds to a halt and then runs out of power when the app is opened?
    - stephenr 9y ago
      Well played.
  - murukesh_s 9y ago
    Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 2013. I am running vscode for 100% of my development time. In the graph, I have sorted the processes by CPU Time (Not just CPU). That is the average amount of CPU used by each process over time. I have also included memory usage. While the total memory comes to around 400mb, it's still lesser than some Java based IDEs. For an app that I use as my main IDE, the resource usage (CPU) is very minimal. cpu usage https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0 https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0
    - stephenr 9y ago
      > it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).
relyks 9y ago
Why is Java not considered as a cross-platform solution?
- ben_jones 9y ago
  My guess is they didn't have much in-house expertise for Java and just neglected to mention it in the write-up.
  - dleslie 9y ago
    Also, Java isn't cool.
    - themihai 9y ago
      And JS is?
      - dleslie 9y ago
        Sadly, it appears so.
        Mayzie 9y ago
        :-(
        ilyaeck 9y ago
        This is so backwards.
- flukus 9y ago
  Java on the desktop died because it didn't provide a native enough look and feel and it performed too slowly. Now we just don't care about look and feel and pretend every user has 16GB of RAM like the developer machines do.
  - relyks 9y ago
flukus 9y ago
> If you’re making a native app, your tech stack choices are pretty limited. On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll use Visual Studio, C#, and WPF or UWP. I'm not sure they know what native means because c# is not native code and WPF is not a native UI. > To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time. All this meant we had twice the work, twice the bugs, and far less time to build new features. Nothing forced them not to share logic from the start, they could have done that and still had a native UI on each platform. It only doubles the work if 100% of the work is in the UI.
- pjmlp 9y ago
  C# compiles to native code since Windows 8, when targeting store applications.
- microcolonel 9y ago
  Yeah, I'm genuinely surprised that "four native developers" didn't realize that there is one native language which works great on all three platforms, and has direct bindings to all of the platform UI toolkits...
  - glandium 9y ago
    You mean several native languages with multiple multi-platform ways to create native UI.
  - flukus 9y ago
    There isn't one that I know of. A language like c++ though would compile to a native library on each platform and allow them to share logic between 3 front ends in the same or a very similar language.
    - microcolonel 9y ago
      That's mostly what I meant. I don't particularly think it's a good idea to share UI code between platforms as different as macOS and Windows. I'm sure there will be serious integration regressions with the new version.
akhatri_aus 9y ago
Can't drag and drop a repository into the app. It's often the small things & little touches that are the problem with non native apps.
- aroman 9y ago
  I mean, this is just as easy to do with electron as it is with a native app. The fact that they didn't implement doesn't mean it isn't possible :-)
  - ridiculous_fish 9y ago
    Is it actually the case that this is "just as easy to do?"
    - adnzzzzZ 9y ago
      http://ourcodeworld.com/articles/read/288/how-to-handle-drag-and-drop-file-feature-in-electron-framework http://ourcodeworld.com/articles/read/288/how-to-handle-drag... Second result I found on Google
      - ridiculous_fish 9y ago
        Based on that link, Electron drag and drop seems extremely limited compared to what native APIs provide: 1. No way to declare what drop types you accept 2. No way to validate the contents of the drop before it occurs 3. No way to provide a visual indication of the action of the drop (copy, move, link...) 4. No way to generate a file drag 5. No drag promises 6. No custom drag images This seems like the typical web development story: quick to build a low-quality implementation, impossible to build a good one.
        bhanu423 9y ago
        How to solve the issues above: Just listen to 'ondrop' event on body and store the path of the file and call event.preventDefault() to prevent the file loading. Now I think all of your issues are solved: >1: You can now filter the extensions as per your requirements >2: Now you can load the file separately and verify the content as per your satisfaction using the fs module available in electron >3: You can use: ondragover and ondragend events to facilitate ui feedback >4: Not sure what you mean by file drag, but I cannot think of anything that cannot be implemented here. >5: Not sure what do you want here. >6: Not inbuilt but can be built easily. Editors like atom and vscode have very good file-drop functionality and have image viewer apart from many other goodies. Depending on your familiarity with js, these things are more or less trivial to implement. Github team must have a different feature-set in mind that unfortunately didn't had drag and drop functionality for their first release. If anyone really wants the feature, the better way is to leave a feedback in app or open a issue (not sure if either exists).
em3rgent0rdr 9y ago
Even though they rewrote to cross-platform API, they still don't provide linux support yet... I also worry about performance and file size with Electron. Why couldn't they just use a native cross-platform toolkit from the start?
- LeoNatan25 9y ago
  Cheaper that way. Get some web "devs" to also write a "desktop" "app" in React.
imran3740 9y ago
The problem with Electron apps is that they're all running their own little Chromium-like instance, hogging up hundreds of MB of RAM, clogging up the process table with all its helper processes, using up CPU when idling. I get the easy cross-platform solution part, but this is just horrible UX. I'm reminded of this article [0], about just how bad Electron is compared to native apps. [0]: https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/
- LeoPanthera 9y ago
  I avoid Electron apps for the above reasons. On a laptop they will eat your battery dry. It reminds me of "Adobe Air", all over again.
- rpwverheij 9y ago
  is anything being done to improve this? would it be reasonable to expect this to change in the future?
  - forgotpw1123 9y ago
    No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).
    - flukus 9y ago
      Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".
      - forgotpw1123 9y ago
        The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed. Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's
pjmlp 9y ago
Thankfully I stopped using the Github app long time ago, rather using the native Tortoise one.
MarkMc 9y ago
> To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time....Now we can share our logic and UI across all platforms, which is fantastic I wonder whether they considered Java with SWT. For the past 10 years I've been developing an accounting application for Windows and Mac using SWT, and it's been a blessing to have such a simple, stable, cross-platform UI library. It's also possible to implement plaform-specific behaviour. For example, standard SWT doesn't allow a native toolbar on Mac, but with a few 'if (mac)' statements I made my application look exactly like all other Mac apps: http://imgur.com/a/l83yI http://imgur.com/a/l83yI I'd say about 95% of my UI code is platform independent.
- DaiPlusPlus 9y ago
  I haven't touched Java UIs since university - back then we were taught about AWT and Swing. I remember being unhappy with AWT because it never worked right and was inflexible - and I was equally unhappy with Swing because it never looked or felt native - and for some reason window resize redrawing was done slowly. I first heard about SWT more recently and it brought back my faith in the native desktop, but I've never used it. In your experience, how well does SWT handle the differences between platforms (fundamental things like macOS vs Windows' menu-bars, to smaller things such as the arrangement of buttons in a dialog)? What is the graphics performance like too?
  - MarkMc 9y ago
    Yes AWT/Swing was bloated, buggy and slow - Sun's poor UI implementation really doomed Java on the desktop. But then IBM came along and did it right: SWT is super fast and lightweight because it simply calls underlying native API like Cocoa or Win32. It's always been super fast even when I started 10 years ago. Layout of components on screen is straightforward and much easier than Swing. (Just use GridLayout 90% of the time). I have to specify different margins and fonts for Mac and Windows and you will need to change the order of the OK/Save and Cancel buttons, but that's not a big problem. (In fact there is a library called JFace which can do alot of this stuff for you, but it comes with a lot of baggage so you may just be better off with pure SWT). The difference in menu bars is perfectly handled by SWT, and it includes Mac-specific menu options like having the Preferences and Quit menu item in the application menu. You may notice a loss of fidelity here and there - for example, on Mac my error messages don't look exactly like a standard Mac error dialog: http://imgur.com/a/znehj http://imgur.com/a/znehj I'm sure I could fix this with 'if(mac)' and breaking out to the native OS, but in 10 years it's never been a high priority for me. -------------------------- By the way, here's a juicy story about why IBM developed SWT: http://www.mail-archive.com/jug-discussion@tucson-jug.org/msg00355.html http://www.mail-archive.com/jug-discussion@tucson-jug.org/ms... A few choice quotes: "At IBM we hated Swing from day one. Big, buggy, and looks crap" "All of the IBM developers are the same crowd who used to work with Smalltalk, and we reluctantly under management orders built our WebSphere Studio tools using Swing. It was a terrible, buggy, monster. In our initial previews when it was demo'd against Microsoft Visual Studio products all our users hated it just because of how it looked, never mind what it let you do" "Swing was so badly broken deep down in the way it reads windows events...they read their event queue in a way that can leave memory holes so we had to have our own loop polling the windows event queue to do this correctly.....We tried over and over to get Sun to fix this but Amy just didn't understand this" "Swing is like Java deciding not to do native IO using the operating system, but instead to use the disk motor arm API and read and write the disk data segments themselves."
cleeus 9y ago
> If you’re making a native app, your tech stack choices are pretty limited. On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll use Visual Studio, C#, and WPF or UWP. Or you could use C++ and Qt and suddenly have Windows,Mac and Linux support in one codebase. And the Qt mobile story is looking better with every release.
- imron 9y ago
  When I was developing the Linux version of a piece of software I make (https://www.chinesetextanalyser.com/ https://www.chinesetextanalyser.com/) I started out with Gtk but it was a massive PITA to work with. I switched to Qt and was pleasantly surprised at how nice it was to use.
ClausSualC 9y ago
I don't know what's worst these days, WannaCry ransomware or Electron apps, both makes me cry. Yet, WannaCry is native so I don't hate that as much as Electron apps.
ridiculous_fish 9y ago
GitHub calls this electron app "the new native" on https://desktop.github.com https://desktop.github.com. But the app does not look or feel native. It has an active appearance even when it's in the background, content lags the window frame during resize, menu items are enabled even when they don't apply or work, some buttons with the default appearance don't respond to return, you can't drag and drop text, many context menus are broken, rubber band scrolling doesn't work, the title bar text is absent, selection modifier keys don't work properly... If native is to mean anything, it can't mean this. Calling it "the new native" is an affront, because its UI regresses in so many places relative to real native apps.
- HappyTypist 9y ago
  It's not just UI but performance as well. For native apps, UI (hover state, clicks, etc) react in 0-1 frames. For Electron apps, these range from 3-10 frames.
  - rjeli 9y ago
    Don't worry, just wait a few years and the processors will be fast enough for native-like performance.
    - sha666sum 9y ago
      In other words, in a few years everyone will need to replace their perfectly good computers because of software bloat.
      - fludlight 9y ago
        You just summed up the history of the industry.
    - pavel_lishin 9y ago
      And by then we'll have our pick of Neutrino, Electrode, and Amber as the new, shiny, laggy way to build "native" apps.
qarioz 9y ago
> JavaScript. It’s the lingua franca of programming. I don't know how I feel about that statement. One one side I want to scream "C", but with each passing day it's getting there.
z3t4 9y ago
You can do an Electron app without electron! This is how you run different browsers in chrome-less mode: iexplore -k %URL%, firefox -chrome %URL%, chrome --app="%URL%" Launch nodejs, then launch the browser, and for the features not supported in the browser, have it talk to nodejs. You now have both a desktop app and a cloud app if you like. You could basically have the exact same code running on for example Github.com and on the desktop. There are advantages with Electron/nw.js though, like only having to support one "browser" that makes it possible to use bleeding edge features.
lucb1e 9y ago
TL;DR: "because it's easier" I'm disappointed by the article. Thought it was going to detail how Electron is actually a good choice, not how they had two separate teams for the different platforms and wanted to get rid of doubly-implementing features (not wanting double work is the obvious requirement and leading reason for going Electron). I mean, git itself is cross-platform and not Electron. How more obvious does it need to get? It even has a GUI. Telegram Desktop is a modern example that did it. And Libreoffice. And Firefox and Thunderbird. And Audacity. And FileZilla. And everything else traditionally written in the open source community. Java applications aren't great either. Due to their platform-independentness things like selecting and context menus seem to be re-implemented by every platform ifnot every project, leading to a lot of inconsistency and ugliness. But at least they aren't as sluggish as the web crap dubbed into being native that Electron is. There are lots of good options but all the engineering blog is able to give for a reason is that it was the easiest.
- roryisok 9y ago
  Anyone know what the telegram Desktop team uses?
  - mhotchen 9y ago
    C++: https://github.com/telegramdesktop/tdesktop https://github.com/telegramdesktop/tdesktop
  - tonyedgecombe 9y ago
    Qt
- joatmon-snoo 9y ago
  Git itself isn't quite cross-platform - it's very backwards-compatible on *nix, yes, but it would be a stretch to call it native Windows software. There's a reason the Git for Windows project bundles MSYS2 ;)
  - lucb1e 9y ago
    Today I learned! Thanks :)
nkkollaw 9y ago
Electron apps are made for developers, but it's users who they're built for and who have to use it. What I mean is, Electron apps make their life easier for a handful of programmers, to the detriment of thousands or in many cases million of users. As a freelance developer, I think Electron is great for the little apps I build for clients for internal use. Companies like GitHub, Spotify, etc. have the resources to do much better than that. I have no idea why they settle for lousy performance just to use web technologies.
- SomeStupidPoint 9y ago
  Short-term thinking: they save money of dev effort and assume their users will just tolerate their worse apps. It's easy to sell yourself on the idea of cutting costs and growth potential to maximize returns now when you're an entrenched market player in a dominant position (as I would argue both GitHub and Spotify are). Heck, it might even work.
  - nkkollaw 9y ago
    Sure, I know they're saving money, but unless you _have_ to use something (Spotify, Skype), many people will choose a competitor instead of your app. One such case is Atom—which from what I know is what Electron was created for: many people use Sublime Text instead. Not because of functionality, but just because Atom is super-slow in comparison, and it won't open or let you work productively with files bigger than 2-5MB. I would argue that the money they save by not going native, they lose from people using better software.
kristianp 9y ago
Sourcetree, a git/hg client, was written in c# for windows and Objective-C for Mac: https://community.atlassian.com/t5/Questions/What-technologies-are-used-to-develop-SourceTree/qaq-p/442029 https://community.atlassian.com/t5/Questions/What-technologi...
- strangerding 9y ago
  same goes for Tower (https://www.git-tower.com https://www.git-tower.com)
  - salutis 9y ago
    GitUp is awesome too. 100% native Mac app.
- vram22 9y ago
  Is C# good for writing GUI apps on Windows? I saw someone in a recent HN thread about Kotlin mention C#, and say that it works on many platforms (including for GUI's, maybe). But my question is limited to Windows.
  - WorldMaker 9y ago
    C# with XAML is your best bet for writing GUI apps on Windows. UWP is the present of Windows GUI app development and just glancing at documentation you can quickly see that C# and XAML are front and center. You can do C++ and XAML if you wish/must, but C# is generally a better idea. (UWP supports .NET Native which AOT compiles C# UWP applications.) C# and XAML can be used in WPF on versions of Windows prior to 10, if you need to support that. The C# is mostly compatible in both GUI systems, the XAML is very close, but subtly different, between the two. (At Build last week, Microsoft announced the XAML Standard initiative to better standardize XAML across platforms. They also announced desktop support for Xamarin Forms, the XAML renderer for common subset of native controls across non-Windows platforms, to support macOS, Linux Gtk, and even WPF.)
    - vram22 9y ago
codesternews 9y ago
This app has really have bad ui performance. Just check sourcetree. Atlassian has done wonder full job at creating and making it. No offense but, They now even have a chance to compete with it.
- LeoNatan25 9y ago
  Check out Tower. Best git UI software for Mac.
  - SyneRyder 9y ago
    Tower is now also available for Windows too (as a native app): https://www.git-tower.com/ https://www.git-tower.com/
  - salutis 9y ago
    Also GitUp!
IncRnd 9y ago
You are pushing the maintenance and testing from your teams onto your users. Sure, you can easily have a multiplatform app this way, but your users suffer for that. It _should_ be the other way around, instead of transferring the cost of software engineering onto users.
deleted 9y ago
[deleted]
cheez 9y ago
I don't understand... You have 4 developers. Git isn't that hard. C++ isn't that hard. Just write it in C++ and use Qt. I know, I know. It isn't cool.
wjh_ 9y ago
Okay so, as much as we all want to complain about how awful Electron is for battery life and just general efficiency, the facts are that it most likely is going to stay - at least for a little while, considering how much is being invested in it. Instead of complaining about what it does, perhaps we could be trying to make it more efficient, or make an alternative that solves the same problems (perceived or otherwise) in a better way?

119 points by joeyespo 9y ago

I think this is great, especially for the electron ecosystem as github engineers are directly involved in making production apps on the stack(other than atom) The cross platform advantage(time & maintenance effort) that electron gives is immense. The overhead is very minimal and we can build some great apps like vscode and the likes have shown.

devwastaken 9y ago
>The overhead is very minimal You're still using JS, unless you're compiling modules for node.js.
- murukesh_s 9y ago
  I find node.js pretty fast. The V8 engine does compile it to native during the run time using a JIT compiler. While it is not quite up to the level of java, it is comparable. The major lacking is no thread support, but it is a boon in many cases as tracking down runtime bugs in multi threaded environments is sometimes very tough. Threads can be simulated using child processes to some extend, but its the only major drawback as far as i have encountered.
  - GRiMe2D 9y ago
    While nodejs is fast enough, Electron and apps built on it aren't fast. Electron is a mix of Chromium and nodejs. Chromium's rendering isn't meant to be used as desktop app. Especially for laptops. I have a MacBook pro mid 2010 with two GPUs. Integrated GPU uses less battery energy than discrete one. And every Chromium app switches GPU to discrete one and causes battery drain.
    - dragonwriter 9y ago
      > Chromium's rendering isn't meant to be used as desktop app. Yes, it is. That was pretty much the entire point of Google making Chrome (to make web apps have acceptable parity with desktop apps), and the entire premise of them building on Chrome with ChromeOS. Now, it may not satisfy you in that role, but it absolutely is meant for it.
      - murukesh_s 9y ago
        Good point. People are bashing Electron and chromium in general. But they do forget JVM based IDEs had the same problem. Rather than bashing Electron, if we can figure out to make it more leaner and faster, it would be much better.
        LeoNatan25 9y ago
        "We"? You mean people that know C++ and low level native APIs, right? Which is decidedly not you. You are building a "hackable" "node.js" "npm" "app". The problem is, people who are indeed capable of making some improvements, including people on the V8 and WebKit teams themselves, do not believe in what these tools attempt to accomplish. (Listen to Don Melton's interviews on the subject, for example.) I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.
stephenr 9y ago
> The overhead is very minimal Compared to what exactly? Because compared to an app built using the platform SDK's, Electron is never "minimal" in anything, except perhaps "integration" or "accessibility".
- gjjrfcbugxbhf 9y ago
  Minimal regard for the users' system resources? Minimal chance of being used because the user notices their laptop grinds to a halt and then runs out of power when the app is opened?
  - stephenr 9y ago
    Well played.
- murukesh_s 9y ago
  Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 2013. I am running vscode for 100% of my development time. In the graph, I have sorted the processes by CPU Time (Not just CPU). That is the average amount of CPU used by each process over time. I have also included memory usage. While the total memory comes to around 400mb, it's still lesser than some Java based IDEs. For an app that I use as my main IDE, the resource usage (CPU) is very minimal. cpu usage https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0 https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0
  - stephenr 9y ago
    > it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).

relyks 9y ago

Why is Java not considered as a cross-platform solution?

ben_jones 9y ago
My guess is they didn't have much in-house expertise for Java and just neglected to mention it in the write-up.
- dleslie 9y ago
  Also, Java isn't cool.
  - themihai 9y ago
    And JS is?
    - dleslie 9y ago
      Sadly, it appears so.
      - Mayzie 9y ago
        :-(
      - ilyaeck 9y ago
        This is so backwards.
flukus 9y ago
Java on the desktop died because it didn't provide a native enough look and feel and it performed too slowly. Now we just don't care about look and feel and pretend every user has 16GB of RAM like the developer machines do.
- relyks 9y ago

flukus 9y ago

> If you’re making a native app, your tech stack choices are pretty limited. On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll use Visual Studio, C#, and WPF or UWP. I'm not sure they know what native means because c# is not native code and WPF is not a native UI. > To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time. All this meant we had twice the work, twice the bugs, and far less time to build new features. Nothing forced them not to share logic from the start, they could have done that and still had a native UI on each platform. It only doubles the work if 100% of the work is in the UI.

pjmlp 9y ago
C# compiles to native code since Windows 8, when targeting store applications.
microcolonel 9y ago
Yeah, I'm genuinely surprised that "four native developers" didn't realize that there is one native language which works great on all three platforms, and has direct bindings to all of the platform UI toolkits...
- glandium 9y ago
  You mean several native languages with multiple multi-platform ways to create native UI.
- flukus 9y ago
  There isn't one that I know of. A language like c++ though would compile to a native library on each platform and allow them to share logic between 3 front ends in the same or a very similar language.
  - microcolonel 9y ago
    That's mostly what I meant. I don't particularly think it's a good idea to share UI code between platforms as different as macOS and Windows. I'm sure there will be serious integration regressions with the new version.

akhatri_aus 9y ago

Can't drag and drop a repository into the app. It's often the small things & little touches that are the problem with non native apps.

aroman 9y ago
I mean, this is just as easy to do with electron as it is with a native app. The fact that they didn't implement doesn't mean it isn't possible :-)
- ridiculous_fish 9y ago
  Is it actually the case that this is "just as easy to do?"
  - adnzzzzZ 9y ago
    http://ourcodeworld.com/articles/read/288/how-to-handle-drag-and-drop-file-feature-in-electron-framework http://ourcodeworld.com/articles/read/288/how-to-handle-drag... Second result I found on Google
    - ridiculous_fish 9y ago
      Based on that link, Electron drag and drop seems extremely limited compared to what native APIs provide: 1. No way to declare what drop types you accept 2. No way to validate the contents of the drop before it occurs 3. No way to provide a visual indication of the action of the drop (copy, move, link...) 4. No way to generate a file drag 5. No drag promises 6. No custom drag images This seems like the typical web development story: quick to build a low-quality implementation, impossible to build a good one.
      - bhanu423 9y ago
        How to solve the issues above: Just listen to 'ondrop' event on body and store the path of the file and call event.preventDefault() to prevent the file loading. Now I think all of your issues are solved: >1: You can now filter the extensions as per your requirements >2: Now you can load the file separately and verify the content as per your satisfaction using the fs module available in electron >3: You can use: ondragover and ondragend events to facilitate ui feedback >4: Not sure what you mean by file drag, but I cannot think of anything that cannot be implemented here. >5: Not sure what do you want here. >6: Not inbuilt but can be built easily. Editors like atom and vscode have very good file-drop functionality and have image viewer apart from many other goodies. Depending on your familiarity with js, these things are more or less trivial to implement. Github team must have a different feature-set in mind that unfortunately didn't had drag and drop functionality for their first release. If anyone really wants the feature, the better way is to leave a feedback in app or open a issue (not sure if either exists).

em3rgent0rdr 9y ago

Even though they rewrote to cross-platform API, they still don't provide linux support yet... I also worry about performance and file size with Electron. Why couldn't they just use a native cross-platform toolkit from the start?

LeoNatan25 9y ago
Cheaper that way. Get some web "devs" to also write a "desktop" "app" in React.

imran3740 9y ago

The problem with Electron apps is that they're all running their own little Chromium-like instance, hogging up hundreds of MB of RAM, clogging up the process table with all its helper processes, using up CPU when idling. I get the easy cross-platform solution part, but this is just horrible UX. I'm reminded of this article [0], about just how bad Electron is compared to native apps. [0]: https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/

LeoPanthera 9y ago
I avoid Electron apps for the above reasons. On a laptop they will eat your battery dry. It reminds me of "Adobe Air", all over again.
rpwverheij 9y ago
is anything being done to improve this? would it be reasonable to expect this to change in the future?
- forgotpw1123 9y ago
  No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).
  - flukus 9y ago
    Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".
    - forgotpw1123 9y ago
      The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed. Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's

pjmlp 9y ago

Thankfully I stopped using the Github app long time ago, rather using the native Tortoise one.

MarkMc 9y ago

> To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time....Now we can share our logic and UI across all platforms, which is fantastic I wonder whether they considered Java with SWT. For the past 10 years I've been developing an accounting application for Windows and Mac using SWT, and it's been a blessing to have such a simple, stable, cross-platform UI library. It's also possible to implement plaform-specific behaviour. For example, standard SWT doesn't allow a native toolbar on Mac, but with a few 'if (mac)' statements I made my application look exactly like all other Mac apps: http://imgur.com/a/l83yI http://imgur.com/a/l83yI I'd say about 95% of my UI code is platform independent.

DaiPlusPlus 9y ago
I haven't touched Java UIs since university - back then we were taught about AWT and Swing. I remember being unhappy with AWT because it never worked right and was inflexible - and I was equally unhappy with Swing because it never looked or felt native - and for some reason window resize redrawing was done slowly. I first heard about SWT more recently and it brought back my faith in the native desktop, but I've never used it. In your experience, how well does SWT handle the differences between platforms (fundamental things like macOS vs Windows' menu-bars, to smaller things such as the arrangement of buttons in a dialog)? What is the graphics performance like too?
- MarkMc 9y ago
  Yes AWT/Swing was bloated, buggy and slow - Sun's poor UI implementation really doomed Java on the desktop. But then IBM came along and did it right: SWT is super fast and lightweight because it simply calls underlying native API like Cocoa or Win32. It's always been super fast even when I started 10 years ago. Layout of components on screen is straightforward and much easier than Swing. (Just use GridLayout 90% of the time). I have to specify different margins and fonts for Mac and Windows and you will need to change the order of the OK/Save and Cancel buttons, but that's not a big problem. (In fact there is a library called JFace which can do alot of this stuff for you, but it comes with a lot of baggage so you may just be better off with pure SWT). The difference in menu bars is perfectly handled by SWT, and it includes Mac-specific menu options like having the Preferences and Quit menu item in the application menu. You may notice a loss of fidelity here and there - for example, on Mac my error messages don't look exactly like a standard Mac error dialog: http://imgur.com/a/znehj http://imgur.com/a/znehj I'm sure I could fix this with 'if(mac)' and breaking out to the native OS, but in 10 years it's never been a high priority for me. -------------------------- By the way, here's a juicy story about why IBM developed SWT: http://www.mail-archive.com/jug-discussion@tucson-jug.org/msg00355.html http://www.mail-archive.com/jug-discussion@tucson-jug.org/ms... A few choice quotes: "At IBM we hated Swing from day one. Big, buggy, and looks crap" "All of the IBM developers are the same crowd who used to work with Smalltalk, and we reluctantly under management orders built our WebSphere Studio tools using Swing. It was a terrible, buggy, monster. In our initial previews when it was demo'd against Microsoft Visual Studio products all our users hated it just because of how it looked, never mind what it let you do" "Swing was so badly broken deep down in the way it reads windows events...they read their event queue in a way that can leave memory holes so we had to have our own loop polling the windows event queue to do this correctly.....We tried over and over to get Sun to fix this but Amy just didn't understand this" "Swing is like Java deciding not to do native IO using the operating system, but instead to use the disk motor arm API and read and write the disk data segments themselves."

cleeus 9y ago

> If you’re making a native app, your tech stack choices are pretty limited. On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll use Visual Studio, C#, and WPF or UWP. Or you could use C++ and Qt and suddenly have Windows,Mac and Linux support in one codebase. And the Qt mobile story is looking better with every release.

imron 9y ago
When I was developing the Linux version of a piece of software I make (https://www.chinesetextanalyser.com/ https://www.chinesetextanalyser.com/) I started out with Gtk but it was a massive PITA to work with. I switched to Qt and was pleasantly surprised at how nice it was to use.

ClausSualC 9y ago

I don't know what's worst these days, WannaCry ransomware or Electron apps, both makes me cry. Yet, WannaCry is native so I don't hate that as much as Electron apps.

ridiculous_fish 9y ago

GitHub calls this electron app "the new native" on https://desktop.github.com https://desktop.github.com. But the app does not look or feel native. It has an active appearance even when it's in the background, content lags the window frame during resize, menu items are enabled even when they don't apply or work, some buttons with the default appearance don't respond to return, you can't drag and drop text, many context menus are broken, rubber band scrolling doesn't work, the title bar text is absent, selection modifier keys don't work properly... If native is to mean anything, it can't mean this. Calling it "the new native" is an affront, because its UI regresses in so many places relative to real native apps.

HappyTypist 9y ago
It's not just UI but performance as well. For native apps, UI (hover state, clicks, etc) react in 0-1 frames. For Electron apps, these range from 3-10 frames.
- rjeli 9y ago
  Don't worry, just wait a few years and the processors will be fast enough for native-like performance.
  - sha666sum 9y ago
    In other words, in a few years everyone will need to replace their perfectly good computers because of software bloat.
    - fludlight 9y ago
      You just summed up the history of the industry.
  - pavel_lishin 9y ago
    And by then we'll have our pick of Neutrino, Electrode, and Amber as the new, shiny, laggy way to build "native" apps.

qarioz 9y ago

> JavaScript. It’s the lingua franca of programming. I don't know how I feel about that statement. One one side I want to scream "C", but with each passing day it's getting there.

z3t4 9y ago

You can do an Electron app without electron! This is how you run different browsers in chrome-less mode: iexplore -k %URL%, firefox -chrome %URL%, chrome --app="%URL%" Launch nodejs, then launch the browser, and for the features not supported in the browser, have it talk to nodejs. You now have both a desktop app and a cloud app if you like. You could basically have the exact same code running on for example Github.com and on the desktop. There are advantages with Electron/nw.js though, like only having to support one "browser" that makes it possible to use bleeding edge features.

lucb1e 9y ago

TL;DR: "because it's easier" I'm disappointed by the article. Thought it was going to detail how Electron is actually a good choice, not how they had two separate teams for the different platforms and wanted to get rid of doubly-implementing features (not wanting double work is the obvious requirement and leading reason for going Electron). I mean, git itself is cross-platform and not Electron. How more obvious does it need to get? It even has a GUI. Telegram Desktop is a modern example that did it. And Libreoffice. And Firefox and Thunderbird. And Audacity. And FileZilla. And everything else traditionally written in the open source community. Java applications aren't great either. Due to their platform-independentness things like selecting and context menus seem to be re-implemented by every platform ifnot every project, leading to a lot of inconsistency and ugliness. But at least they aren't as sluggish as the web crap dubbed into being native that Electron is. There are lots of good options but all the engineering blog is able to give for a reason is that it was the easiest.

roryisok 9y ago
Anyone know what the telegram Desktop team uses?
- mhotchen 9y ago
  C++: https://github.com/telegramdesktop/tdesktop https://github.com/telegramdesktop/tdesktop
- tonyedgecombe 9y ago
  Qt
joatmon-snoo 9y ago
Git itself isn't quite cross-platform - it's very backwards-compatible on *nix, yes, but it would be a stretch to call it native Windows software. There's a reason the Git for Windows project bundles MSYS2 ;)
- lucb1e 9y ago
  Today I learned! Thanks :)

nkkollaw 9y ago

Electron apps are made for developers, but it's users who they're built for and who have to use it. What I mean is, Electron apps make their life easier for a handful of programmers, to the detriment of thousands or in many cases million of users. As a freelance developer, I think Electron is great for the little apps I build for clients for internal use. Companies like GitHub, Spotify, etc. have the resources to do much better than that. I have no idea why they settle for lousy performance just to use web technologies.

SomeStupidPoint 9y ago
Short-term thinking: they save money of dev effort and assume their users will just tolerate their worse apps. It's easy to sell yourself on the idea of cutting costs and growth potential to maximize returns now when you're an entrenched market player in a dominant position (as I would argue both GitHub and Spotify are). Heck, it might even work.
- nkkollaw 9y ago
  Sure, I know they're saving money, but unless you _have_ to use something (Spotify, Skype), many people will choose a competitor instead of your app. One such case is Atom—which from what I know is what Electron was created for: many people use Sublime Text instead. Not because of functionality, but just because Atom is super-slow in comparison, and it won't open or let you work productively with files bigger than 2-5MB. I would argue that the money they save by not going native, they lose from people using better software.

kristianp 9y ago

Sourcetree, a git/hg client, was written in c# for windows and Objective-C for Mac: https://community.atlassian.com/t5/Questions/What-technologies-are-used-to-develop-SourceTree/qaq-p/442029 https://community.atlassian.com/t5/Questions/What-technologi...

strangerding 9y ago
same goes for Tower (https://www.git-tower.com https://www.git-tower.com)
- salutis 9y ago
  GitUp is awesome too. 100% native Mac app.
vram22 9y ago
Is C# good for writing GUI apps on Windows? I saw someone in a recent HN thread about Kotlin mention C#, and say that it works on many platforms (including for GUI's, maybe). But my question is limited to Windows.
- WorldMaker 9y ago
  C# with XAML is your best bet for writing GUI apps on Windows. UWP is the present of Windows GUI app development and just glancing at documentation you can quickly see that C# and XAML are front and center. You can do C++ and XAML if you wish/must, but C# is generally a better idea. (UWP supports .NET Native which AOT compiles C# UWP applications.) C# and XAML can be used in WPF on versions of Windows prior to 10, if you need to support that. The C# is mostly compatible in both GUI systems, the XAML is very close, but subtly different, between the two. (At Build last week, Microsoft announced the XAML Standard initiative to better standardize XAML across platforms. They also announced desktop support for Xamarin Forms, the XAML renderer for common subset of native controls across non-Windows platforms, to support macOS, Linux Gtk, and even WPF.)
  - vram22 9y ago

codesternews 9y ago

This app has really have bad ui performance. Just check sourcetree. Atlassian has done wonder full job at creating and making it. No offense but, They now even have a chance to compete with it.

LeoNatan25 9y ago
Check out Tower. Best git UI software for Mac.
- SyneRyder 9y ago
  Tower is now also available for Windows too (as a native app): https://www.git-tower.com/ https://www.git-tower.com/
- salutis 9y ago
  Also GitUp!

IncRnd 9y ago

You are pushing the maintenance and testing from your teams onto your users. Sure, you can easily have a multiplatform app this way, but your users suffer for that. It _should_ be the other way around, instead of transferring the cost of software engineering onto users.

deleted 9y ago

[deleted]

cheez 9y ago

I don't understand... You have 4 developers. Git isn't that hard. C++ isn't that hard. Just write it in C++ and use Qt. I know, I know. It isn't cool.

wjh_ 9y ago

Okay so, as much as we all want to complain about how awful Electron is for battery life and just general efficiency, the facts are that it most likely is going to stay - at least for a little while, considering how much is being invested in it. Instead of complaining about what it does, perhaps we could be trying to make it more efficient, or make an alternative that solves the same problems (perceived or otherwise) in a better way?