1. The Suicidal Statement
2. Strict Mode → Runtime Errors → The Worst Ones!
3. Unnecessary Strict Mode Errors Flagged by ESLint Beforehand
4. Implied Globals
5. Non-writable Variables
6. Unique Object Literal Property Names
7. Unique Function Parameter Names
8. A Small Win of Strict Mode Turned Into a Loss
9. Octal Issues
10. Setting Properties on Primitive Values
11. Strict Mode Slows Down Your Code
12. Strict Does Not Simplify Variable Usage
13. Deleting Plain Names
15. What Is Meant by “Securing”?
16. Referencing the Global Object in Functions
17. Walking the Stack
18. Strict Mode Could Impact the Future-Proofness of Your Work
19. There Can Be Issues Mixing Both Modes
20. Reserved Words
21. Function Statements
Then comes the question: Why do we have to use strict mode anyway, when we have tools like ESLint?
However, this is an individual decision to be made. So, if you prefer to work in strict mode, then do it. But if you and your project are better when not – here are 21 reasons why you are right to think so.