Hacker News new | ask | show | jobs
by azakai 4115 days ago
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.

1 comments

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.