Comment by lol768 | Hacker News Reader

Comment by lol768 | Hacker News Reader

> 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-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?) 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.

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.

I don't care too much about RAM, I do care about the carnage it wrecks on my battery life.

Maybe few extra battery packs will take care of battery issue too?

I like the way you think

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.

I agree with you but comparing VIM to Atom or IntelliJ or Visual Studio is an orange to apple comparison.

Comparing Atom to one of the native-window ports of Vim or Emacs seems pretty fair to me.

I have yet to suffer due to chrome using too much memory.

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?

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

Seems slower to me. Personal observation.

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

> Oh, there's still no build for Linux.

Check this:

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.

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.

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/dd3...

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.

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.

Reply on news.ycombinator.com