Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/springernature/frontend-playbook
The Frontend Playbook
https://github.com/springernature/frontend-playbook
best-practices css discussion frontend html javascript playbook
Last synced: 2 days ago
JSON representation
The Frontend Playbook
- Host: GitHub
- URL: https://github.com/springernature/frontend-playbook
- Owner: springernature
- License: other
- Created: 2016-03-10T16:23:05.000Z (almost 9 years ago)
- Default Branch: main
- Last Pushed: 2025-01-06T17:25:34.000Z (15 days ago)
- Last Synced: 2025-01-12T02:12:38.974Z (9 days ago)
- Topics: best-practices, css, discussion, frontend, html, javascript, playbook
- Homepage:
- Size: 2.74 MB
- Stars: 467
- Watchers: 197
- Forks: 46
- Open Issues: 14
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Security: security/README.md
Awesome Lists containing this project
README
# The Frontend Playbook
This repo contains The Frontend Playbook. It details how we run software development and how we make web and mobile products together. It's filled with things we've learned based on our own experience and study of others' experiences.
The main motivator for this playbook is not to document a list of guidelines, but rather to create an opportunity to collaborate on them, and to gain consensus.
This is a living document that we contribute to in a _public_ GitHub repo. Reasons for doing this in the open include (but are not limited to):
1. Interacting with and learning from others. Receiving contributions from people who don't work here can help us, providing learning opportunities that we would not receive otherwise - for example, see [this contribution](https://github.com/springernature/frontend-playbook/pull/48#issuecomment-236139605) from @rowanmanning.
1. Providing a showcase for our work/ethics. This is _really_ useful when hiring people (for both parties). We've had very positive feedback from interviewees - it's a great recruiting tool. It also means that people are quickly up and running when they join.
See "[Changing the laws of engineering with pull requests](https://www.youtube.com/watch?v=YIpNpptGX6Q)" for an in depth explanation of how developing a playbook like this is of benefit.
## Sections
There's no particular order to which you should read the playbook, but the [Practices section](practices/README.md) is probably a good starting point.
* [Accessibility](accessibility/README.md)
* [CSS](css/README.md)
* [Git](git/README.md)
* [JavaScript](javascript/README.md)
* [Markup](markup/README.md)
* [Performance](performance/README.md)
* [Practices](practices/README.md)
* [Security](security/README.md)
* [Writing](writing/README.md)## Contributing
To contribute please clone the repo (or fork it if you're an external contributor), create a new branch for your changes, then create a pull request to merge your changes in.
Please keep discussion inside the issues and pull requests, avoiding Slack, hallway conversations etc. Remember that this repo is public, and the discussions we have can be of benefit to people apart from us.
[Read the full contributor guide](CONTRIBUTING.md).
## Key words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP (Best Current Practice) 14](https://www.rfc-editor.org/info/bcp14) ([RFC 2119](https://tools.ietf.org/html/rfc2119), [RFC8174](https://tools.ietf.org/html/rfc8174)) when, and only when, they appear in all capitals, as shown here.
## License
The Frontend Playbook is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
You should have received a copy of the license along with this work. If not, see [Creative Commons BY-NC-SA 4.0 license](http://creativecommons.org/licenses/by-nc-sa/4.0/).