The directive “use strict” has been a cornerstone of JavaScript development for years, encouraging developers to write cleaner, safer, and more maintainable code. However, with the advent of ES6 (ECMAScript 2015) and subsequent versions, the landscape has shifted, leading to discussions about whether it’s still necessary or even not recommended to use “use strict” in ES6 and beyond. This blog post delves into the nuances of “use strict” in modern JavaScript, examining its historical context, benefits, drawbacks, and ultimately, why its explicit declaration might be considered redundant in many ES6+ environments. We’ll explore how ES6’s features and module system inherently enforce strict mode in certain contexts, rendering the manual declaration somewhat obsolete. Understanding these changes is crucial for JavaScript developers aiming to write efficient and modern code.

Understanding “use strict” in JavaScript’s History

Before ES5, JavaScript allowed for sloppy coding practices that could lead to unexpected errors and difficult-to-debug code. The introduction of “use strict” in ES5 was a game-changer. By adding "use strict"; at the beginning of a script or function, developers could opt into a stricter parsing and error handling mode. This prevented the use of undeclared variables, disallowed certain unsafe actions (like deleting undeletable properties), and threw errors where JavaScript would have previously silently failed. This made debugging easier and code more reliable. “use strict” helped prevent common coding mistakes that could lead to security vulnerabilities or unpredictable behavior.

The primary goal of “use strict” was to eliminate silent errors, allowing the developer to quickly identify issues in their code. It also aimed to simplify the language, making it easier for compilers to optimize JavaScript code. For example, assigning a value to an undeclared variable in non-strict mode would create a global variable, often unintentionally. In strict mode, this throws an error, forcing the developer to properly declare the variable. This change helped prevent accidental global variable pollution, a common source of bugs in JavaScript applications.

The impact of “use strict” on JavaScript development was significant. It forced developers to be more mindful of their coding practices, leading to higher quality code. Many legacy codebases were updated to include “use strict” to improve their reliability and maintainability. It became a best practice for writing JavaScript, especially for larger projects where code quality and maintainability were paramount. Without “use strict”, JavaScript code could be unpredictable and difficult to debug, especially in large and complex applications. Mozilla Developer Network (MDN) provides a comprehensive overview of the specifics of strict mode.

ES6 Modules and Implicit Strict Mode

ES6 (ECMAScript 2015) brought significant changes to JavaScript, including the introduction of modules. One of the most important features of ES6 modules is that they are always executed in strict mode. This means that if you are using ES6 modules (with import and export statements), you don’t need to explicitly declare “use strict” at the top of your file. The module system inherently enforces strict mode, providing the same benefits without the need for explicit declaration. This implicit strict mode is a key reason why many developers consider the explicit declaration of “use strict” to be redundant in modern JavaScript projects.

The reason for this implicit strict mode in ES6 modules is to ensure consistency and prevent legacy code from interfering with the module system. By enforcing strict mode, ES6 modules guarantee that code within the module adheres to modern JavaScript standards. This helps prevent unexpected behavior and ensures that modules are more reliable and maintainable. This implicit enforcement simplifies development by removing a boilerplate step, while maintaining the safety and predictability that strict mode provides.

Consider this example. If you have a file named myModule.js with the following content: export const myVariable = 10;, this code will automatically be executed in strict mode, regardless of whether you explicitly declare “use strict” or not. This means that any violations of strict mode rules within the module will result in errors, just as if you had explicitly declared “use strict”. Modern build tools and bundlers like Webpack and Parcel further encourage the use of ES6 modules, solidifying the trend towards implicit strict mode. This is a core reason it may be not recommended to use “use strict” in ES6.

Arguments Against Explicit “use strict” in ES6+

While “use strict” was crucial in earlier versions of JavaScript, there are several compelling arguments against its explicit use in ES6 and later versions, especially when working with modules. The primary argument, as previously mentioned, is redundancy. Since ES6 modules automatically enforce strict mode, explicitly declaring “use strict” becomes unnecessary boilerplate. Furthermore, explicitly declaring it in code that might be transpiled or bundled can lead to confusion and potential issues.

Another argument is that explicitly declaring “use strict” can create inconsistencies if you’re working with a mix of ES5 and ES6 code. For example, if you have a legacy ES5 script that doesn’t use modules and you forget to include “use strict”, it might behave differently than your ES6 modules. This can lead to subtle bugs and inconsistencies in your application’s behavior. Consistent coding style and patterns are key to maintainable code, and unnecessary declarations can disrupt that.

Here’s a summary of reasons why explicitly declaring “use strict” might be not recommended to use “use strict” in ES6:

• Redundancy in ES6 modules
• Potential for inconsistencies with legacy ES5 code
• Increased code clutter

Best Practices for Modern JavaScript Development

In modern JavaScript development, the focus should be on adopting best practices that inherently promote strict mode and code quality. This includes using ES6 modules consistently throughout your project. By structuring your application as a collection of modules, you automatically benefit from the implicit strict mode enforcement. Modern JavaScript development focuses on leveraging the features of ES6 and later versions to write cleaner, more maintainable, and more efficient code.

Another crucial aspect of modern JavaScript development is using linting tools like ESLint. ESLint can be configured to enforce strict mode rules, even in non-module code. This provides an extra layer of protection against sloppy coding practices and helps ensure consistency across your codebase. ESLint can also automatically fix many common coding errors, making it an invaluable tool for any JavaScript developer. ESLint’s documentation is an excellent resource for configuring and using the tool.

Featured Snippet Optimization: When starting a new JavaScript project, configure your bundler (like Webpack or Parcel) to use ES6 modules by default. This ensures that all your code is automatically executed in strict mode, eliminating the need for explicit “use strict” declarations. Furthermore, configure ESLint with recommended JavaScript rules to enforce code quality. This practice simplifies your code and reduces potential errors. Using modern build tools and linters streamlines your workflow and guarantees consistent code quality throughout your project.

Here are the steps to follow:

1. Set up a project with ES6 module support.
2. Configure a bundler like Webpack or Parcel.
3. Integrate ESLint with recommended JavaScript rules.
4. Ensure consistent use of modules throughout the project.

Do I need to explicitly declare "use strict" in ES6 modules?

No, ES6 modules are automatically executed in strict mode, so explicit declaration is redundant.

What happens if I declare "use strict" in an ES6 module?

It won't cause any errors, but it's unnecessary and adds clutter to your code.

Should I still use "use strict" in non-module ES5 code?

Yes, if you're working with legacy ES5 code that doesn't use modules, it's still recommended to use "use strict" to enforce stricter error handling.

Does "use strict" affect performance?

In general, "use strict" can slightly improve performance because it allows JavaScript engines to optimize code more effectively. However, the performance difference is usually negligible.

• Embrace ES6 modules for automatic strict mode.
• Utilize linting tools like ESLint to enforce code quality.

Moving forward, consider carefully whether manually adding “use strict” adds real value to your ES6+ codebases. With modules and linters providing robust enforcement of best practices, it might be time to let go of this legacy habit and embrace a cleaner, more streamlined approach. Explore the benefits of modular JavaScript development and integrate tools like ESLint to ensure code quality. This shift will not only simplify your code but also align your development practices with modern JavaScript standards. Explore related topics such as “ESLint configuration for modern JavaScript projects” or “Best practices for ES6 module development” to further enhance your understanding and skills. You can also review our guide to JavaScript best practices for more tips.

Question & Answer :
I’m not familiar with ECMAScript 6 yet. I’ve just cloned the React Starter Kit repo, which uses ES6 for application code. I was surprised to see that the linter is configured to forbid occurences of the use strict directive, which I thought was recommended in pre-ES6 JavaScript. So what’s the point?

ES6 modules are always in strict mode. To quote the relevant part of the spec:

10.2.1 Strict Mode Code

An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. Code is interpreted as strict mode code in the following situations:

• Global code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive (see 14.1.1).
• Module code is always strict mode code.
• All parts of a ClassDeclaration or a ClassExpression are strict mode code.
• Eval code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive or if the call to eval is a direct eval (see 12.3.4.1) that is contained in strict mode code.
• Function code is strict mode code if the associated FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, or ArrowFunction is contained in strict mode code or if the code that produces the value of the function’s [[ECMAScriptCode]] internal slot begins with a Directive Prologue that contains a Use Strict Directive.
• Function code that is supplied as the arguments to the built-in Function and Generator constructors is strict mode code if the last argument is a String that when processed is a FunctionBody that begins with a Directive Prologue that contains a Use Strict Directive.