1 of 7

The awesome manifesto

If you want your list to be included on awesome, try to only include actual awesome stuff in your list. After all, it's a curation, not a collection.

But what is awesome?

Only awesome is awesome

Research if the stuff you're including is actually awesome. Only put stuff on the list that you or another contributor can personally recommend. You should rather leave stuff out than include too much.

Awesome badge

This badge is for Awesome lists.

Add an awesome badge to the top of your list, right next to the title. . You can choose either the regular badge or the flat one.

The badges should not be modified in any way.

Awesome mentioned badge

This badge is for projects being mentioned in an Awesome list (NOT for use in Awesome lists). For example, the project could feature this badge because it's listed in . It's totally optional for projects, but it's a nice way to show they've been featured in an Awesome list. You can choose either the regular badge or the flat one.

Fill in the placeholders (Name and URL):

Example:

If you're an Awesome list maintainer, you could encourage projects in your list to add the badge.

The badges should not be modified in any way.

Comment on why something is awesome

Apart from suggesting a particular item on your list, you should also inform your readers why it's on the list and how they will benefit from it.

Make it clear what the list is about

Have a succinct description at the top of your readme. Make sure your list covers a certain scope and nothing else. Link to other awesome lists if you think they already cover a certain subject well enough.

Pay attention to grammar

Ensure your list is grammatically correct, typo-free and has no Markdown formatting errors. This should also apply to pull requests.

Choose an appropriate license

Include contribution guidelines

People who are contributing to your list should have a clear understanding of how they should do so.

Stylize your list properly

Accept other people's opinion

If you're an owner of the list, respect other people's opinion. If there are plenty of users not agreeing to your decision, give it a second thought.

Contributor Covenant Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the community
Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

The use of sexualized language or imagery and unwelcome sexual attention or advances
Trolling, insulting/derogatory comments, and personal or political attacks
Public or private harassment
Publishing others' private information, such as a physical or electronic address, without explicit permission
Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at sindresorhus@gmail.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://contributor-covenant.org/version/1/4

Contribution Guidelines

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Adding an awesome list

Please ensure your pull request adheres to the list guidelines.

Creating your own awesome list

To create your own list, check out the instructions.

Adding something to an awesome list

If you have something awesome to contribute to an awesome list, this is how you do it.

You'll need a GitHub account!

Access the awesome list's GitHub page. For example: https://github.com/sindresorhus/awesome
Click on the readme.md file:
Now click on the edit icon.
You can start editing the text of the file in the in-browser editor. Make sure you follow guidelines above. You can use GitHub Flavored Markdown.
Say why you're proposing the changes, and then click on "Propose file change".
Submit the pull request!

Updating your Pull Request

Sometimes, a maintainer of an awesome list will ask you to edit your Pull Request before it is included. This is normally due to spelling errors or because your PR didn't match the awesome-* list guidelines.

Here is a write up on how to change a Pull Request, and the different ways you can do that.

Creating Your Own List

Read the Awesome manifesto and list guidelines and ensure your list complies.
Search this list before making a new one, as yours may be a duplicate. If it is, try and contribute to the best one instead of making your own.
You might find this Yeoman generator useful.
Wait at least 30 days after creating a list before submitting it, to give it a chance to mature.
Make sure you read the list guidelines again before submitting a pull request for your list to be added here.

Thanks for being awesome! 😎

pull_request_template

[Insert URL to the list here]

[Explain what this list is about and why it should be included here]

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. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions.
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
- ❌ 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 title of your entry should be title-cased and the URL to your list should end in #readme.
- Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.
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. Instead use #2242 for incubation visibility.
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.
The default branch should be named main, not master.
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.
- Must not feature Contributing or Footnotes sections.
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=main&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, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text 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.
- It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
- The section should not appear in the Table of Contents.
All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
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 use hard-wrapping.
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.

Media

Logo

Primary color: #fc60a8
Secondary color: #494368
Font:

You are free to use and modify the logo for your Awesome list or other usage.

pull_request_template

[Insert URL to the list here]

[Explain what this list is about and why it should be included here]

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. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions.
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
- ❌ 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 title of your entry should be title-cased and the URL to your list should end in #readme.
- Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.
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. Instead use #2242 for incubation visibility.
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.
The default branch should be named main, not master.
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.
- Must not feature Contributing or Footnotes sections.
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=main&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, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text 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.
- It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
- The section should not appear in the Table of Contents.
All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
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 use hard-wrapping.
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.

awesome-list

Special thanks to:

Follow the for updates on new list additions.

Just type to go here. Check out my and follow me on .

Platforms

- Async non-blocking event-driven JavaScript runtime built on Chrome's V8 JavaScript engine.
- - Writing cross-platform code on Node.js.
- Mobile operating system for Apple phones and tablets.
- Mobile operating system developed by Google.
- Cross-platform native desktop apps using JavaScript/HTML/CSS.
- JavaScript API for hybrid apps.
- JavaScript framework for writing natively rendering mobile apps for iOS and Android.
- Mobile app development IDE, testing, and distribution.
- - Virtual machine that allows you to write more efficient and powerful tracing and monitoring for Linux systems.
- - Linux distributions and projects based on Arch Linux.
- - Package apps in a single file that works on various mainstream Linux distributions.
macOS - Operating system for Apple's Mac computers.
- Operating system for the Apple Watch.
- P2P hypermedia protocol.
- Mobile development tools.
- Cloud platform as a service.
- Credit card-sized computer aimed at teaching kids programming, but capable of a lot more.
- Cross-platform GUI app framework.
- Cross-browser extension system.
- Create apps for different TV platforms.
- Simple and distraction-free desktop environment for Linux.
- A free software community dedicated to creating an open and user-friendly computing experience.
- - Open-source compilers and code analysis APIs for C# and VB.NET languages.
- Virtual home assistant.
- Cloud computing platform designed for developers.
- Google's mobile SDK for building native iOS and Android apps from a single codebase written in Dart.
- Open source home automation that puts local control and privacy first.
- Cloud platform for developers and companies.
- App development platform built on Google Cloud Platform.
- Set of software libraries and tools that help you build robot apps.
- Visualize and store data from any device.
- CDN, DNS, DDoS protection, and security for your site.
- Developer platform for Google Assistant.
- Low-cost microcontrollers with WiFi and broad IoT applications.
- A secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.
- Operating system for x86-based personal computers that was popular during the 1980s and early 1990s.
- Package manager for Linux and other Unix systems that makes package management reliable and reproducible.
- Linking together different IT systems (components) to functionally cooperate as a whole.
- A programming tool for wiring together hardware devices, APIs, and online services.
- Allowing business professionals to address their needs on their own with little to no coding skills.
- Cross-platform open source runtime for building Web Native apps.
- Mapping and location analysis platform for developers.

Programming Languages

- - Style guide and linter.
- - Impossible sounding projects that exist.
- - For npm packages.
- - Package manager.
- - Test runner.
- - Linter.
- - Task runner.
- - Code snippets you can understand in 30 seconds.
- - Like polyfills but without overriding native APIs.
- Apple's compiled programming language that is secure, modern, programmer-friendly, and fast.
- General-purpose programming language designed for readability.
- - Asynchronous I/O in Python 3.
- - Scientific research in audio/music.
- - A version of Python for microcontrollers.
- - Data analysis and machine learning.
- - Optional static typing for Python.
- - A lean and efficient implementation of Python 3 for microcontrollers.
- - Optimizing ahead-of-time compiler for Scala based on LLVM.
- High-level dynamic programming language designed to address the needs of high-performance numerical analysis and computational science.
- General-purpose language with a bias toward system programming and embedded, resource-constrained software.
- Functional programming language and environment for statistical computing and graphics.
- Powerful dynamic multiparadigm language that facilitates iterative and interactive development.
- Popular secure object-oriented language designed for flexibility to "write once, run anywhere".
- Server-side scripting language.
- - Package manager.
- Haskell for the JVM.
- Build, test, and package software.
- Object-oriented language targeting Adobe AIR.
- Functional programming language for the JVM.
- General purpose pure functional programming language with dependent types influenced by Haskell and ML.
- Modern programming language designed for large, long-lived apps where reliability and efficiency are essential.
- Domain-specific programming language used for expressing quantum algorithms.
- Programming language inspired by Ruby and Python and compiles to performant JavaScript.
- Programming language designed to take full advantage of the GLib and GNOME ecosystems, while preserving the speed of C code.
- Formal language and environment for programming and specification which facilitates interactive development of machine-checked proofs.
- Simple, fast, safe, compiled language for developing maintainable software.
- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Front-End Development

- Style sheet language that specifies how HTML elements are displayed on screen.
- JavaScript library for building user interfaces.
- - Framework for building data-driven React apps.
- - Lets you use state and other React features without writing a class.
- JavaScript library to develop Web Components.
- App framework.
- App framework.
- Markup language used for websites & web apps.
- XML-based vector image format.
- JavaScript library.
- JavaScript toolkit.
- App framework.
- Library for producing dynamic, interactive data visualizations.
- Easy to use JavaScript library for DOM manipulation.
- Functional and reactive JavaScript framework.
- App framework.
- App framework.
- App framework.
- CSS tool.
- Rich text editor framework for React.
- App framework.
- State container for JavaScript apps.
- Module bundler.
- CSS preprocessor.
- Enterprise-class UI design language.
- CSS preprocessor.
- JavaScript API for rendering 3D graphics.
- App framework.
- Framework for server-rendered React apps.
- Library for building web components with a declarative template system.
- Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt markup.
- Web development technology stack with WordPress as a back end and Gatsby as a front end.
- Creating a great mobile web experience.
- Development environment for UI components.
- .NET web framework using C#/Razor and HTML that runs in the browser with WebAssembly.
- Metrics to help understand page speed and user experience.
- Utility-first CSS framework for rapid UI development.
- Rust framework for creating web apps running in WebAssembly.
- Techniques to ensure certain performance metrics for a website.
- Animations in the browser with JavaScript, CSS, SVG, etc.
- Rust framework inspired by Elm and React for creating multi-threaded frontend web apps with WebAssembly.
- Material Design React components for faster and easier web development.
- Standalone features to be integrated into web apps.
- App framework.
- Collection of reusable components, guided by rules that ensure consistency and speed.
- Make single-page apps without building an API.
- Templates, layouts, components, and widgets to rapidly build websites.

Back-End Development

- Python framework.
- Automation virtual machine environment.
- Python framework.
- PHP framework.
- PHP framework.
- PHP framework.
- - Full-stack development solution featuring libraries built by the Laravel community.
- Web app framework for Ruby.
- - Packages.
- PHP framework.
- Web server.
- Java framework.
- Open-source platform that automates Linux container operations.
- PHP micro-framework.
- Serverless computing and serverless architectures.
- Java web app framework.
- Toolkit for building reactive apps on the JVM.
- Tool for building, changing, and versioning infrastructure.
- Server-side development in Swift.
- Python web app framework.
- Python web app framework.
- Open-source software development framework for defining cloud infrastructure in code.
- User accounts, authentication and authorization.
- PHP framework.
- Web framework built on top of Fasthttp, the fastest HTTP engine for Go.

Computer Science

- - Learning, implementing, and applying Machine Learning using Ruby.
- - Models for Apple's machine learning framework.
- - Open source distributed machine learning platform written in Java with APIs in R, Python, and Scala.
- - From experiment to production-level machine learning.
- - Solving problems in finance with machine learning.

The awesome manifesto

Only awesome is awesome

Awesome badge

Awesome mentioned badge

Comment on why something is awesome

Make it clear what the list is about

Pay attention to grammar

Choose an appropriate license

Include contribution guidelines

Stylize your list properly

Accept other people's opinion

Contributor Covenant Code of Conduct

Our Pledge

Our Standards

Our Responsibilities

Scope

Enforcement

Attribution

Contribution Guidelines

Adding an awesome list

Creating your own awesome list

Adding something to an awesome list

Updating your Pull Request

Creating Your Own List

pull_request_template

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

Requirements for your pull request

Requirements for your Awesome list

Media

Logo

Contribution Guidelines

Adding an awesome list

Creating your own awesome list

Adding something to an awesome list

Updating your Pull Request

Creating Your Own List

Contributor Covenant Code of Conduct

Our Pledge

Our Standards

Our Responsibilities

Scope

Enforcement

Attribution

pull_request_template

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

Requirements for your pull request

Requirements for your Awesome list

Media

Logo

awesome-list

Contents

Platforms

Programming Languages

Front-End Development

Back-End Development

Computer Science

Big Data

Theory

Books

Editors

Gaming

Development Environment

Entertainment

Databases

Media

Learn

Security

Content Management Systems

Hardware

Business

Work

Networking

Decentralized Systems

Higher Education

Events

Testing

Miscellaneous

Related

The awesome manifesto

Only awesome is awesome