4 ms·

> We've rebuilt GitHub Desktop from the ground up in Electron to create a simplified user experience focused squarely on how you use GitHub Would be really int

by lol768 9y ago

> We've rebuilt GitHub Desktop from the ground up in Electron to create a simplified user experience focused squarely on how you use GitHub Would be really interested to see some benchmarks comparing the performance of the Electron version and the previous version. Start-up time, time to perform common actions etc. Personally I think it's a bit of a shame, since I seem to remember the previous version making use of the platform's native toolkits and widgets, e.g. WPF on Windows and Cocoa on Mac. I suspect the overall UX will now suffer. I guess it's easier to develop though, and works on Linux now? Edit: Oh, there's still no build for Linux. They do detail some of the reasoning (https://githubengineering.com/how-four-native-developers-wrote-an-electron-app/? https://githubengineering.com/how-four-native-developers-wro...) behind this decision in the GitHub engineering blog and it looks like they've put a lot of work into this. But even the menu bar they've come up with (https://github.com/desktop/desktop/pull/991? https://github.com/desktop/desktop/pull/991?) for Windows is obviously not native. The decision seems to boil down to (paraphrasing) "lots of people are doing web stuff" and "now we can reuse our code" ... which is fine, but again seemingly prioritises the development over the user experience.

frogfuzion 9y ago
That's the whole point of Electron period. Cut development costs. Meanwhile end-users (including developers) will suffer, because along with their chrome instances using hundreds of MB in ram, they will have electron apps open using similar (and in many cases more) amounts.
- HalfwayToDice 9y ago
  I don't care too much about RAM, I do care about the carnage it wrecks on my battery life.
  - geodel 9y ago
    Maybe few extra battery packs will take care of battery issue too?
    - electroner 9y ago
      I like the way you think
- jackyinger 9y ago
  On top of this I found atom to be pretty unstable, especially when using a bunch of plugins. Text editors are a primary tool and instability is unacceptable. I can't remember any time vim crashed on me.
  - brogrammernot 9y ago
    I agree with you but comparing VIM to Atom or IntelliJ or Visual Studio is an orange to apple comparison.
    - clhodapp 9y ago
      Comparing Atom to one of the native-window ports of Vim or Emacs seems pretty fair to me.
- amcca029 9y ago
  I have yet to suffer due to chrome using too much memory.
grouseway 9y ago
Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed. Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform. Stepping back and looking at the state of things as a whole, I find it mildly depressing that large companies like github, facebook, google, etc... can't seem to churn out native apps despite their deep pockets. How are the rest of us supposed to manage?
- lol768 9y ago
  > Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed. Unfortunately I can't give it a relistic try, I can't find a Linux build and I wouldn't get a realistic feel for performance inside a VM. My prior experience with the performance Electron based applications comes from using software such as Atom, VS Code etc. I can't say I've experienced WPF apps being that slow when I do use unvirtualised Windows, though (I think I noticed startup time, but that's about it). > Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform. Yeah, everything I read pointed at it being a reasonably early release - which is fair enough. I'm sure they'll iterate and improve.
- philliphaydon 9y ago
  Seems slower to me. Personal observation.
tinus_hn 9y ago
Just about the only application that people use on Windows that has a native menu bar is Notepad. The vast majority has a custom menu, either a ribbon like Office or something else.
- Mister_Snuggles 9y ago
  I'm pretty sure that Microsoft uses Office, in part, as a way to develop and refine new UI elements. At some point the API got pulled out of Office and made part of Windows proper, with the Windows Ribbon Framework[0]. Built in applications, Explorer being the most visible, have now started using it. [0] https://msdn.microsoft.com/en-us/library/windows/desktop/dd316910(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...
- WorldMaker 9y ago
  Various arms of Microsoft's design efforts have definitely been trying to kill the menu bar as design pattern for many years at this point. Ribbons are superior. Fluent has its own suggestions for how to build the right affordances for a menu, which remain very similar to Ribbon principles. Ironically/sadly, Visual Studio will probably be the last bastion of classic menu bars and toolbars from Microsoft because to some extent Microsoft's designers are busy elsewhere, but that continues to set a bad example to developers. If it weren't for Visual Studio itself, I'd even argue that it was merely the cross-platform interests of keeping Mac users happy that GitHub's team might even think menus were a good idea.
Mister_Snuggles 9y ago
> But even the menu bar they've come up with [...] Menu bars are a native construct on both Windows and MacOS. They serve the same purpose but work differently on each platform. Users have expectations on how menus will behave, how they will look, and where they will be located. Using the system's menu bar construct gives the developer all of that for free. I can't understand why any developer of a native application needs to "come up with" their own menu bar.
- gumby 9y ago
  The same reason web developers come up with their own scrolling. It's all a ton of absurd masturbatatory make-work of no benefit to the end user.
Existenceblinks 9y ago
All complaints on HN are mostly valid in technical point of view. But from business point, reducing the costs also make sense just like moving some parts to be made in China. A _design_ which is a generic term of thinking of human interaction shouldn't be tied to tools/toolkits. On desktop application, I lack of bad experience using web-tech wrapped apps so I haven't seen significant suffer from interacting with these (I'm using Atom, Github Desktop) Anyway, I'm not against good performance.
cr0sh 9y ago
> Oh, there's still no build for Linux. Check this: https://github.com/desktop/desktop/issues/1525#issuecomment-302146153 https://github.com/desktop/desktop/issues/1525#issuecomment-... At least one person forked it and made it (somewhat?) work on Debian...so you might check that out.

by lol768 9y ago

frogfuzion 9y ago

That's the whole point of Electron period. Cut development costs. Meanwhile end-users (including developers) will suffer, because along with their chrome instances using hundreds of MB in ram, they will have electron apps open using similar (and in many cases more) amounts.

HalfwayToDice 9y ago
I don't care too much about RAM, I do care about the carnage it wrecks on my battery life.
- geodel 9y ago
  Maybe few extra battery packs will take care of battery issue too?
  - electroner 9y ago
    I like the way you think
jackyinger 9y ago
On top of this I found atom to be pretty unstable, especially when using a bunch of plugins. Text editors are a primary tool and instability is unacceptable. I can't remember any time vim crashed on me.
- brogrammernot 9y ago
  I agree with you but comparing VIM to Atom or IntelliJ or Visual Studio is an orange to apple comparison.
  - clhodapp 9y ago
    Comparing Atom to one of the native-window ports of Vim or Emacs seems pretty fair to me.
amcca029 9y ago
I have yet to suffer due to chrome using too much memory.

grouseway 9y ago

Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed. Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform. Stepping back and looking at the state of things as a whole, I find it mildly depressing that large companies like github, facebook, google, etc... can't seem to churn out native apps despite their deep pockets. How are the rest of us supposed to manage?

lol768 9y ago
> Give it a try. Surprisingly it seems faster than than the .net version - perhaps because WPF and WinForms apps never feel fast. I'm impressed. Unfortunately I can't give it a relistic try, I can't find a Linux build and I wouldn't get a realistic feel for performance inside a VM. My prior experience with the performance Electron based applications comes from using software such as Atom, VS Code etc. I can't say I've experienced WPF apps being that slow when I do use unvirtualised Windows, though (I think I noticed startup time, but that's about it). > Feature wise it still seems kind of anemic - you couldn't use it exclusively. Hopefully they will be able to improve on that now that they have twice the manpower to work on one platform. Yeah, everything I read pointed at it being a reasonably early release - which is fair enough. I'm sure they'll iterate and improve.
philliphaydon 9y ago
Seems slower to me. Personal observation.

tinus_hn 9y ago

Just about the only application that people use on Windows that has a native menu bar is Notepad. The vast majority has a custom menu, either a ribbon like Office or something else.

Mister_Snuggles 9y ago
I'm pretty sure that Microsoft uses Office, in part, as a way to develop and refine new UI elements. At some point the API got pulled out of Office and made part of Windows proper, with the Windows Ribbon Framework[0]. Built in applications, Explorer being the most visible, have now started using it. [0] https://msdn.microsoft.com/en-us/library/windows/desktop/dd316910(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...
WorldMaker 9y ago
Various arms of Microsoft's design efforts have definitely been trying to kill the menu bar as design pattern for many years at this point. Ribbons are superior. Fluent has its own suggestions for how to build the right affordances for a menu, which remain very similar to Ribbon principles. Ironically/sadly, Visual Studio will probably be the last bastion of classic menu bars and toolbars from Microsoft because to some extent Microsoft's designers are busy elsewhere, but that continues to set a bad example to developers. If it weren't for Visual Studio itself, I'd even argue that it was merely the cross-platform interests of keeping Mac users happy that GitHub's team might even think menus were a good idea.

Mister_Snuggles 9y ago

> But even the menu bar they've come up with [...] Menu bars are a native construct on both Windows and MacOS. They serve the same purpose but work differently on each platform. Users have expectations on how menus will behave, how they will look, and where they will be located. Using the system's menu bar construct gives the developer all of that for free. I can't understand why any developer of a native application needs to "come up with" their own menu bar.

gumby 9y ago
The same reason web developers come up with their own scrolling. It's all a ton of absurd masturbatatory make-work of no benefit to the end user.

Existenceblinks 9y ago

All complaints on HN are mostly valid in technical point of view. But from business point, reducing the costs also make sense just like moving some parts to be made in China. A _design_ which is a generic term of thinking of human interaction shouldn't be tied to tools/toolkits. On desktop application, I lack of bad experience using web-tech wrapped apps so I haven't seen significant suffer from interacting with these (I'm using Atom, Github Desktop) Anyway, I'm not against good performance.

cr0sh 9y ago

> Oh, there's still no build for Linux. Check this: https://github.com/desktop/desktop/issues/1525#issuecomment-302146153 https://github.com/desktop/desktop/issues/1525#issuecomment-... At least one person forked it and made it (somewhat?) work on Debian...so you might check that out.