This is the source repository for Frontend Engineering Playbook by Frontend community contributors. This book will list down all the best strategies being used in Frontend for example Image Handling or Semantic HTML etc. Content is welcomed from various online resources but credit and copyright information should be there and referenced. P.S. It is open sourced and ready for contribution for Hactoberfest as a valid project.
Please note that for now, producing a better book is the primary goal. All other things being equal, an easier to build book is better than a harder to build book, but, for example, a better illustration that relies on a new tool is better than a worse illustration.
Built and maintained by our Steering Committe, Maintainers and Collaborators
- 01 Getting Started
- 02 FE Architecture Principles
- 03 Writing semantic HTML
- 04 Cost of styling
- 05 Cost of scripts
- 06 Reliable renderings
- CSR
- SSR
- Hybrid
- 07 Making it fast
- Loading Techniques
- Image Optimization
- Scripts
- Compressions
- 08 Where to store
- Cookies
- Storage
- Handling Secrets
- 09 Catch errors early
- JavaScript Linters
- CSS Linters
- 10 Making things accessible
- 11 Making things secure
- Common Attack Vectors
- XSS
- CSRF
- Click Jacking
- Add Ons and Browser related exploits
- Social Engineering
- Session & Cookie jacking
- RegEx related exploits
- 12 Frontend Dashboard
- 13 Caching strategies
- 14 Making things searchable
- 15 Packers and Bundlers
- 16 Libraries you can use
- 17 NPM Modules you can use
- 18 Continuous Integration
- 19 Release It
- 20 Tools and Technologies
- 21 Credit and References
- 22 Contributors
Waiting for sterring committe members for the guidance and right direction.
Thanks to all maintainers!🙏
 Anoop Gupta |
Thank you to all our collaborators! 🙏
Our collaborators are members who are contributing to the repository on a reguar basis, through suggesting the chapters and content for the book, triaging issues, reviewing pull requests and more. If you are interested in helping us publish this engineering book, please read our contributor guidelines 🎉
 Gopal Saini |
 Sudhanshu Srivastava |
We appreciate any contribution, from a single word fix to a new chapter.
A successfull PR gives you a ⭐, be the first to collect it.
Contributors should be recognised as soon as the contribution is discovered to help ensure their efforts are not overlooked when the list gets updated at a later date. This can be difficult for contributions that are not the result of a commit to the repository but do your best to minimise the time between the contribution and updating the list.
Pro tip: If your project is configured for the @all-contributors bot 🤖 simply write a comment on an issue or pull request to recognise their contribution. For example:
@all-contributors please add @tbenning for design ✨
Being the owner or a maintainer of the repository does not mean you are solely responsible for keeping the list of contributors up to date. You should encourage contributors to add themselves to the list as much as possible. This can be in the form of a comment on the issue, blog or answer, or through more direct forms of communication where appropriate.
Many contributors may not realise that their efforts are sufficient for recognition in the contributors list. This might be because they have not read or understood the definition of a contributor as set out in this specification, or because they do not feel like it is significant enough. In these cases, you should still encourage them to add themselves, but it may be necessary for you to add the contributor yourself (though it's a good idea to do so in the form of a pull request to make sure they're ok with being added).
In the end, there are no hard and fast rules for when a contribution has to be added to the list, just do your best to be fair and to ensure all contributors are recognised.