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

Add Browser Automation #1687

Closed
wants to merge 1 commit into from
Closed

Add Browser Automation #1687

wants to merge 1 commit into from

Conversation

angrykoala
Copy link
Contributor

https://github.com/angrykoala/awesome-browser-automation#readme

Browser automation tools and resources, for web scraping, testing or simply web automation. Currently, only a Selenium-specific list exists related to this.
Some more comments related to this can be found at #1404. This PR is a follow-up of #1513 with the comments addressed as possible.

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

Requirements for your pull request

  • Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
  • You have to review at least 2 other open pull requests.
    Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
  • Added ML with Python #1514
  • Add Firebase #1515
  • Add Material-UI #1676
  • You have read and understood the instructions for creating a list.
  • This pull request has a title in the format Add Name of List.
    • Add Swift
    • Add Software Architecture
    • Update readme.md
    • Add Awesome Swift
    • Add swift
    • Adding Swift
    • Added Swift
  • Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.
    • - [iOS](…) - Mobile operating system for Apple phones and tablets.
    • - [Framer](…) - Prototyping interactive UI designs.
    • - [iOS](…) - Resources and tools for iOS development.
    • - [Framer](…)
    • - [Framer](…) - prototyping interactive UI designs
  • Your entry should be added at the bottom of the appropriate category.
  • The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

  • Has been around for at least 30 days.
    That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
  • Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
  • Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
  • Includes a succinct description of the project/theme at the top of the readme. (Example)
    • Mobile operating system for Apple phones and tablets.
    • Prototyping interactive UI designs.
    • Resources and tools for iOS development.
    • Awesome Framer packages and tools.
  • It's the result of hard work and the best I could possibly produce.
    If you have not put in considerable effort into your list, your pull request will be immediately closed.
  • The repo name of your list should be in lowercase slug format: awesome-name-of-list.
    • awesome-swift
    • awesome-web-typography
    • awesome-Swift
    • AwesomeWebTypography
  • The heading title of your list should be in title case format: # Awesome Name of List.
    • # Awesome Swift
    • # Awesome Web Typography
    • # awesome-swift
    • # AwesomeSwift
  • Non-generated Markdown file in a GitHub repo.
  • The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
  • Not a duplicate. Please search for existing submissions.
  • Only has awesome items. Awesome lists are curations of the best, not everything.
  • Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
  • Includes a project logo/illustration whenever possible.
    • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
    • The image should link to the project website or any relevant website.
    • The image should be high-DPI. Set it to maximum half the width of the original image.
  • Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
  • Includes the Awesome badge.
    • Should be placed on the right side of the readme heading.
      • Can be placed centered if the list has a centered graphics header.
    • Should link back to this list.
  • Has a Table of Contents section.
    • Should be named Contents, not Table of Contents.
    • Should be the first section in the list.
    • Should only have one level of nested lists, preferably none.
  • Has an appropriate license.
    • We strongly recommend the CC0 license, but any Creative Commons license will work.
      • Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0 (replace <user> and <repo> accordingly).
    • A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
    • Place a file named license or LICENSE in the repo root with the license text.
    • Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
    • To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.
  • Has contribution guidelines.
    • The file should be named contributing.md. Casing is up to you.
  • Has consistent formatting and proper spelling/grammar.
    • The link and description are separated by a dash.
      Example: - [AVA](…) - JavaScript test runner.
    • The description starts with an uppercase character and ends with a period.
    • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
  • Doesn't include a Travis badge.
    You can still use Travis for list linting, but the badge has no value in the readme.
  • Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

@angrykoala
Copy link
Contributor Author

unicorn

@jetli
Copy link
Contributor

jetli commented Jan 22, 2020

You'd better add a Contribute section in readme to encourage people to contribute to your list, refer to https://github.com/jetli/awesome-yew#contribute , your list seems cool besides this, thank you.

@jetli jetli mentioned this pull request Jan 22, 2020
@agucova
Copy link
Contributor

agucova commented Jan 22, 2020

It seems the list fulfills all the requirements except all items being maintained, why is such a big portion of the entries no longer maintained? Per the guidelines:

Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.

Even if you move those entries to a separate Markdown file, projects like RoboBrowser (last updated in 2015, and with no useful documentation) or DalekJS (which seems to be completely abandoned and not really finished) could be removed from the list, although that is up to your personal criterion.

Overall, great work!

As a quick note, you listed PhantomJS as unmaintained, but it was last updated 9 days ago.

@jetli
Copy link
Contributor

jetli commented Jan 22, 2020

@agucova He's already marked projects like ghost.py with a 🚫 to indicate Not Maintained, I think that's ok. Thanks for your advice.

@agucova
Copy link
Contributor

agucova commented Jan 22, 2020

@jetli I think that would be fine if it was a few items (so making a new file was unnecessary), but the guidelines are quite clear in that respect.

Perhaps all the unmaintained items could be ordered so they are grouped towards the end of the list?

@jetli
Copy link
Contributor

jetli commented Jan 22, 2020

@agucova I agree, unmaintained items should be at least grouped to separate section or even separate file.

@agucova agucova mentioned this pull request Jan 22, 2020
@angrykoala
Copy link
Contributor Author

@agucova While there are a some unmaintained projects, their web, repository and overall functionality is still useful for people looking for options IMO. Although, I agree some of those may be too old/unfinished projects for this list, I'll try to remove some of the unmaintained items.

@agucova PhantomJS is listed as unmainted as despite having recent commits in the repository as the web is down with the notice: Important: PhantomJS development is suspended until further notice (see #15344 for more details). Which also exists in the Readme, also the last release is from 2016. Please correct me if I missed something.

@angrykoala
Copy link
Contributor Author

The following comments have been addressed:

  • @agucova Too many deprecated projects: I would prefer to keep the deprecated projects in the same list if possible due to the high relevance of some of them (e.g. phantomjs) as being still actively used. I've removed some of the older+less starred unmaintained projects (e.g. dalek) and removed the unmaintained signal in a couple of projects that could still be considered active for now (<6 months since last commit)

  • @jetli I though on adding a contribution section, but checking other important lists I noticed that this is not widely used (including root awesome list and node) so I decided not to add it (for now at least) as it feels a bit redundant having already the file, as GitHub already directs you to it on PRs (Following the same logic as why not to add a license section Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.)

I think I've covered all comments, please let me know if I missed anything or if you don'' agree with these changes 😃

@sindresorhus
Copy link
Owner

I would prefer to keep the deprecated projects in the same list if possible due to the high relevance of some of them (e.g. phantomjs)

Deprecated projects are not awesome. It doesn't benefit anyone to have them in your list. Awesome lists are not historical records. They're not Wikipedia. Awesome lists are meant to be a current overview of the most Awesome and relevant things on a specific topic. People go to your list to find what to use, not what people used to use.

Talking specifically about PhantomJS. Honestly, even if it was still actively maintained, it was never awesome (I have a lot of experience dealing with it).

@sindresorhus
Copy link
Owner

sindresorhus commented Feb 1, 2020

Use the correct casing for names. Jsdom= > jsdom. JQuery => jQuery, etc. Applies to names in descriptions too.

@sindresorhus
Copy link
Owner

Seeing as most things are open source, I think you should rather invert 🎉 - Open Source to mark things that are not. Currently, the emoji is quite noisy.

@angrykoala
Copy link
Contributor Author

@sindresorhus I've addressed your comments. However I'll have to insist in keeping some deprecated projects:

Despite being deprecated, most of these are still functional tools with a big enough community and people using it, being projects relevant to browser automation and important for a comprehensive list of this topic. About the reasoning behind keeping the deprecated projects:

  • PhantomJS: I'm tempted to agree with you in that this has never been awesome, but I'm afraid that would be a bit of a personal opinion, despite being deprecated, there are ~600 dependent projects and > 600k weekly downloads on npm alone. I don't think a browser automation list could be comprehensive by ignoring one of the most famous (and actively used) tool out there.

  • Nightmare: Despite deprecated, it is still pretty much usable and being an electron-based browser automation tool it is quite unique and interesting, as it doesn't use any of the typical headless browsers.

  • Zombie.js: This one I'm happy to remove as it is not as usable as others, however, being one of the few browser automation libraries with built-in assertions, it is quite unique and interesting (and it is kinda awesome in that regard)

  • I have removed Robobrowser, after adding some python-based tools it is not as relevant.

Hope this makes sense 😊
thoughts?

@sindresorhus
Copy link
Owner

You have your view on how you want your list to be and that's totally fine, but it will not be added here in its existing form. I'm not trying to be difficult. It's simply that I hold every list added to very high standards and I really don't want them to include stuff that are clearly not Awesome, even if it's commonly used. The point of Awesome lists is not to create a historical record. An Awesome list is an opinionated ever-changing view of the most Awesome resources in a community at the current time.

@angrykoala
Copy link
Contributor Author

@sindresorhus I understand your point, however I don't see how a community based project (This requirement is meant to help make the Awesome project self-sustaining) can be subjected to a personal view on what is awesome and what is not, being as objective as possible, PhantomJS currently has a huge community (arguably this is this the closest to an objective metric on awesomeness?), with most people not even knowing it is supposed to be deprecated as shown by a previous comment on this same thread (As a quick note, you listed PhantomJS as unmaintained, but it was last updated 9 days ago.). If the feedback for closing this is simply "[project] Not awesome IMO" it becomes hard to improve on this list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants