Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Electron wrapper apps #368

Merged
merged 11 commits into from
Oct 5, 2016
Merged

Remove Electron wrapper apps #368

merged 11 commits into from
Oct 5, 2016

Conversation

herrbischoff
Copy link
Collaborator

@herrbischoff herrbischoff commented Sep 27, 2016

To discuss the merits of those applications despite the fact that they are basically web apps.

Seeing the final list of removals, I'd vote to just merge the whole PR, thereby extinguishing all traces of Electron and Chromium wrappers. Contrary to my former statement that Atom should be included, I feel that the performance gain alone of native apps like Sublime Text or even Vim justify that. In my view, none of the apps in this pull request are outstanding applications without equal or better native alternatives. Case in point: Caret vs. Typora, Atom vs. Sublime Text.

Still, I'm quite surprised to see practically all so-called "modern" editors are built using Electron. I understand the popularity and appeal. However, on a macOS awesome list, none of those should have a place.

Having said that, I would of course be open to also remove any cross-platform applications with no clean implementation of the Apple Human Interface Guidelines, meaning: which may be free but look like crap.

@knpwrs
Copy link
Contributor

knpwrs commented Sep 27, 2016

FWIW, this won't should not automatically apply to all Electron apps in the future. I'm currently working on an Electron app that uses native macOS APIs -- Electron is just providing the user interface.

@herrbischoff
Copy link
Collaborator Author

@knpwrs: This is a good contribution to the discussion. As the base assumption here is to judge the applications based on merit (despite my own views), this is very likely to happen. I don't like those apps as I prefer to use snappy, native and consistent applications. The current fad of app-ifying everything does not sit right with me as the create-once-run-everywhere fad did years before. The best experience was, is and will always be a native application with familiar UI elements for the respective platform, be it macOS, iOS, Android, Windows, Linux (well...), whatever. There's a reason Apple dropped skeudomorphism in favour of a clean, elegant and meaningful UI. My view about UI appears to be quite at odds with yours — for me, there is no such thing as "just the user interface". As far as the user is concerned, the interface is the application.

@iCHAIT
Copy link
Owner

iCHAIT commented Sep 27, 2016

@dkhamsing @dufferzafar Your thoughts on this PR?

@knpwrs
Copy link
Contributor

knpwrs commented Sep 27, 2016

@herrbischoff Just curious, what would you say about applications such as Audacity or Blender (both on this list)? Audacity is WX, so it uses native widgets, but it hardly fits in with other apps (visually). Blender uses its own UI toolkit and AFAIK doesn't implement any macOS-specific functionality.

@dufferzafar
Copy link
Collaborator

Considering this list is for macOS, I agree with @herrbischoff 👍

@akz92
Copy link

akz92 commented Sep 27, 2016

I don't think that this should be a list of the apps that have the most Apple-like UI and UX. In my opinion this should be a list of the best software available for the platform. To use text editors as an example, yes Sublime is native and performs better than Atom but Atom is still a good text editor and as such should have it's place on this list. The same applies to a bunch of 'Electron wrapper apps'.

I believe that there's a difference between web-apps wrapped as a desktop app (Slack i.e.) and apps built on Electron (Atom i.e.).

@knpwrs
Copy link
Contributor

knpwrs commented Sep 27, 2016

@akz92 You could argue that Slack actually does use native features not available in the web app. Two examples:

  1. You can close the window and still get notifications and messages and whatnot.
  2. The Electron app uses notification features that aren't available in web notifications, e.g., being able to reply directly in a notification.

Other than that, yeah, Slack is primarily a web app -- it functions almost the same in a browser whereas Atom will not function outside of Electron.

@iCHAIT
Copy link
Owner

iCHAIT commented Sep 27, 2016

@herrbischoff Since you have got a +1 from one of the list maintainers (@dufferzafar), feel free to merge this PR, though you may want to add a line about the policy that we are going to follow for electron wrapped apps in contributing.md so that its a bit easier for us to reject a PR for such apps in the future and settle this argument one and for all.

@zarembas
Copy link

Atom is slow, but for me it's the best editor I can get on macOS, and I've tried them all. Also Slack has got a huge thumbs up from the tech community. I agree with not having web-wrappers in this list, but banning software just because it uses a certain technology seems a bit extreme.

@dkhamsing
Copy link
Collaborator

Of all these, I actually use Atom and Slack so I would vote to keep em 😅

Can't quite articulate why though.. just habit?

  • Atom is visually very pleasing and fast enough for my use
  • Slack works great and I believe the app has more native shortcuts vs the web version

@dkhamsing
Copy link
Collaborator

If you prefer to have a blanket ban of electron apps, I am ok with that

@lordgiotto
Copy link

I'm really sad about this PR :(
Any app should, in my opinion, be judged on it's quality and features, not on the technology behind its implementation. The technology is only the tool, but are shape and functionality that make an app awesome.
My 2 cents ;)

@dkhamsing
Copy link
Collaborator

should we put this to a vote, whats the status

@knpwrs
Copy link
Contributor

knpwrs commented Oct 5, 2016

My opinion:

There is an Awesome Electron list. Things on this list would be best to show a specific strength of macOS. But that doesn't only apply to Electron Apps -- as I've mentioned earlier, Audacity and Blender on are this list but hardly show off anything about the platform or fit in with the rest of macOS. Those (and a number of Electron apps) would probably be better off on an Awesome Crossplatform list.

Maybe another section (or even another file) in this same repository would be appropriate? Awesome stuff that is available on macOS that isn't specifically awesome because of macOS?

@iCHAIT
Copy link
Owner

iCHAIT commented Oct 5, 2016

@knpwrs Thanks for the idea mate.

@herrbischoff @dkhamsing Merging this, and for future lets encourage contributors to target their electron wrapped software suggestions to awesome electron list rather than platform specific one.

@iCHAIT iCHAIT merged commit ada4881 into master Oct 5, 2016
@dkhamsing dkhamsing deleted the electron branch October 5, 2016 19:50
@knpwrs
Copy link
Contributor

knpwrs commented Oct 6, 2016

@iCHAIT What would you say about the latter part of my comment? Non-Electron apps that aren't really great fits for the macOS ecosystem?

@iCHAIT
Copy link
Owner

iCHAIT commented Oct 6, 2016

@knpwrs

Awesome stuff that is available on macOS that isn't specifically awesome because of macOS

I am not entirely sure to be honest, I think it is inevitable that such apps should fall in a some awesome list because they are awesome at the end of the day, maybe/maybe not this list.

Though, I don't think having a separate section for such apps in this list itself would harm anyone,

What say @herrbischoff @dkhamsing ?

@dkhamsing
Copy link
Collaborator

Seems simpler for now to not allow Electron apps

If we have missed any, feel free to open a pull request

@knpwrs
Copy link
Contributor

knpwrs commented Oct 6, 2016

I was more referring to things like Blender or Audacity. Do they belong on this list?

@dkhamsing
Copy link
Collaborator

@herrbischoff can you take a look

@iCHAIT
Copy link
Owner

iCHAIT commented Oct 6, 2016

@knpwrs if you feel they should not be on the list, I would suggest you to open a PR removing them so that it is easier to scrutinize :)

@herrbischoff
Copy link
Collaborator Author

@dkhamsing: I will check them out.

@herrbischoff
Copy link
Collaborator Author

Please see #372.

@stackptr stackptr mentioned this pull request Mar 21, 2018
@ajnsit ajnsit mentioned this pull request Dec 2, 2018
Repository owner deleted a comment from huabin Jul 24, 2020
Repository owner locked as resolved and limited conversation to collaborators Jul 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants