> Any program running “correctly” in strong mode should run unchanged as ordinary JS. Thus, strong mode programs can be executed on all VMs that can handle ES6, even ones that don’t recognise the mode.
This worries me. If it's running "correctly", then sure, it will run elsewhere. But if it hits something that Strong Mode considers "incorrect", then things diverge, and other browsers will execute something different.
This can be avoided if Strong Mode just issues warnings, not errors. Which seems sufficient, if the goal is to inform people about stuff they should optimize.
For those that want more rigorous checking, browsers could add a developer mode, in which those warnings become errors. This way, there is no risk of production code working differently on different browsers.
We have seen "use strict" cause errors in production. Avoiding that with "use strong" seems like a safer path, with no significant downsides that I can see.
The point of "use strong" is to enable optimizations that wouldn't be possible otherwise, among other things. If you remove it in production, you won't get the optimizations.
"use strict" is used in production all the time. Google and Facebook use it. The Babel transpiler (formerly 6to5) adds it to your code by default.
It's one thing to get JS programmers to write their code in a certain way, but if the VM knows they are doing so, it's even more powerful.
I think there are 2 points - the one you said, to enable optimizations, and the other, to guide people to writing code that is easy to optimize.
I guess the question is, how much better can you do, over easy-to-optimize code. Or in other words, once something is valid in Strong Mode, how much do extra Strong Mode optimizations get you.
Such code should already be quite fast in current JS engines. The big, big difference is between the engine getting hard-to-optimize vs easy-to-optimize code. So I would bet that the bigger deal is the devtool aspect here. But, these are empirical questions.
This attitude really surprises me. I've been deploying 'use strict' code to live environments since 2012 and genuinely can't recall a single occasion where it has caused us a problem.
We lint, unit-test and acceptance-test aggressively (including legacy browsers), and the strict directive itself is of course scoped to our own IIFE. Perhaps that explains why I've not witnessed the hurt you mention.
The mechanics of strict mode are very clearly defined too, so I've not seen any cases were developer confusion caused unwanted side-effect (although I have heard straw-man arguments made where people predict it would).
The benefits, on the other hand, are real and tangible. Errors that might otherwise be difficult to diagnose fail hard and obviously. Browsers are better able to optimise strict code than non-strict. And culturally, I suspect that a use-strict policy has forced everyone to be more clinical in their approach.
Hand on heart, I would never go back to deploying non-strict code, so would be really interested to hear from anyone else in the opposite camp.
Could you expand on how it could hurt you? All I was able to find was this [0]
> I found two opinions about using strict mode in production:
> > There is no reason to ship “use strict” in your production code. There is no performance gain (verified with V8 team and Brendan a while ago) and I don’t need my users’ VMs doing the extra checks as well. Keep it development only, strip it out during build. This way you also avoid the concatenation issue you reference.
> And:
> > There may not be a performance gain, but there’s also not a performance loss. In production, even more than in development, is where you want to be sure you’re noticing errors. Minimizing the changes between the development and production versions of the code is key to being able to debug issues quickly and efficiently. Yes it helps during development, but there’s no reason to pull it out of production code.
> The source is in the comments at the bottom [1]
> And of course those 12b weight of "use strict" won't change a thing.
In practice there have definitely been perf losses from "use strict" (emscripten used to emit it until we noticed that). "use strict" sounds easier to optimize - it's stricter - but in practice, JS engines didn't get around to optimizing it, at least that was the case a few years ago.
There have also been breakage issues. "use strict" changes semantics. Before all browsers implemented "use strict", some had it and some didn't, which meant scripts with "use strict" ran differently in different browsers.
I remember when it was generally suggested to avoid "use strict", because there wasn't great browser support. You could write "strict" code that would work at the time (due to browsers not actually enforcing strict mode), but in the future the same code might break in conformant releases of those browsers.
That said, these days it's invaluable. Getting errors early saves time and prevents subtle bugs. It's become a widely accepted best practice, as noted by other posters.
I definitely share your concerns about mode switches, but as long as there's a conformant implementation to test against, it seems like strong mode could move the language forward without too much of the "use strict" early adoption pain. Strict mode wasn't completely smooth sailing, but I think in the long run it helped.
The biggest potential problem is using a file/global-scoped "use strict" directive in a .js file that gets concatenated and minified with other files that are not strict mode compliant, thus unintentionally modifying the behavior of any code that's concatenated after the strict mode script.
This issue bit Amazon in the ass a while back and gave rise to JSHint checking for function-level strict mode declarations only and the general rule-of-thumb to not use strict mode in production code.
Won't keeping the pragma be a useful signal for the compiler to know it can use the more efficient language subset? Those that don't support it can just ignore the pragma and go with standard Javascript.
I agree that you shouldn't. But sometimes people will make the mistake and do it, if it doesn't cause a problem on their dev machines. Then it could break on the open web.
Not changing JS semantics would avoid this. All the developer benefits are still possible without semantic changes.
isn't it like why you would remove asserts? the only thing an assert will do is fail (or do nothing) - why do you want to fail for users? (when you could not fail, or at least not on that line) - so they can see that you messed up?
It's kind of like protocols: be strict in what you send out but lenient in what you accept. be strict in the javascript you write but then lenient when your users are actually running it.
A failed assertion means the program no longer has any idea what's happening. If it continues past that point it can either get lucky or start to do lots of damage. Whether that's an acceptable risk depends a lot on what type of program it is.
What if you're writing HFT software and an error causes you to spend millions of dollars on the wrong thing? If you had that assert in there then the program would have just crashed instead of bankrupting your company.
Similar problems could easily arise in JS with e-commerce type applications, failing is sometimes a good thing.
This worries me. If it's running "correctly", then sure, it will run elsewhere. But if it hits something that Strong Mode considers "incorrect", then things diverge, and other browsers will execute something different.
This can be avoided if Strong Mode just issues warnings, not errors. Which seems sufficient, if the goal is to inform people about stuff they should optimize.
For those that want more rigorous checking, browsers could add a developer mode, in which those warnings become errors. This way, there is no risk of production code working differently on different browsers.
We have seen "use strict" cause errors in production. Avoiding that with "use strong" seems like a safer path, with no significant downsides that I can see.