“use strict”只在调试中使用吗？

Question

“use strict”只在调试中使用吗？

javascriptminifyuse-strict

7

我想知道当我完成编程并发布我的JavaScript文档供任何人查看时，是否真的需要包含"use strict"。我喜欢使用它来检查我是否以良好的方式编码。

那么，当我发布JavaScript文件供公众使用时，是应该包含还是删除"use strict"呢？

我提出这个问题的原因是为了节省JavaScript文件的空间。

- user1431627

7

“在我的JavaScript文件中节省空间” - 说真的，你的JavaScript文件有多大（即使经过压缩）？ - Tomasz Nurkiewicz

2

@TomaszNurkiewicz 这一定是几乎满了 :P - Paul

4

如果你的带宽账单如此高昂，以至于 use strict 的 10 个字节会使你破产，那么你可能需要考虑更换网络服务提供商。 - Marc B

3

@user1431627，以后永远不要再听那个“某人”的话了。永远都不要！ - gdoron

2

如果你在网站上有最小的图像，它将远远超过10K，我告诉你，那个人不知道他在说什么。你不必相信我，阅读所有其他评论和答案... - gdoron

显示剩余8条评论

4个回答

2

当然，这只是一种微小的优化，但如果您将（比如25个）JS模块连接在一起，那么突然间就会多出250个字节。如果您要部署到高流量应用程序的生产环境中，假设每分钟有1000次访问，那么一年将会有130+GB的流量可以通过构建去掉'use strict'来避免。我相信这样可以在AWS上省下不少钱...除了时间成本外，我还没有看到保留它的充分理由。也许确实不值得，但如果您已经有一个构建系统，并且具备最少的努力就能轻松搞定这个问题的知识，为什么不呢？

- Zach Lysobey

1

由于使用了gzip，它的大小将远小于250字节。 - Adria

我想知道为什么那么多JS缩小器不提供去除这个选项？ - simon

这是一个相当荒谬的论点。假设网络带宽为$1/GB（非常高），任何一家每年服务__五亿次请求__的网站所有者都不会担心130美元/年。 - Abhishek Divekar

@abhidivekar "每年五亿次请求"甚至都不算高。谷歌每天处理的请求数量达到了万亿级别。如果像uglifyJS这样的工具可以做到这一点，甚至可以减少几个字节的捆绑大小，我不认为这会是一个坏事。而且我要再说一遍，是的，这将是一种微观优化。 - Zach Lysobey

2

代码行"use strict";共占用13个字节。我建议，这不太可能接近文件大小的1%。

如果你担心带宽问题，请使用其中的一种缩小文件大小的工具，并在服务器端使用gzip压缩。手动删除13个字节是一种虚假的经济手段。

具体使用哪种缩小工具可能取决于你的代码，但这里有一些建议。

- Dancrumb

0

我目前建议您在任何用于生产环境的代码中删除"use strict"（仅在调试时使用它）。

然而，我不会删除它只是为了使文件更小。我要删除它的原因是因为当JavaScript执行时，它目前似乎对实际性能产生负面影响。希望这种情况最终会改变，但现在出于性能原因，我会省略它。

- Joe Aldrich

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- gdoron is supporting Monica · Accepted Answer

我发现有两种关于在生产环境下使用严格模式的观点：

引用一：没有理由在生产代码中使用"use strict"。没有性能增益（与V8团队和Brendan不久前验证过），而且我不需要我的用户VM也执行额外检查。仅在开发期间保留它，构建时将其剥离。这样还避免了你提到的连接问题。

引用二：可能没有性能提升，但也没有性能损失。在生产环境中，比在开发环境中更需要确保您注意到错误。尽量减少开发和生产版本代码之间的更改是快速高效地调试问题的关键。是的，在开发期间会有所帮助，但没有理由将其从生产代码中移除。

来源在底部的评论区：The source is in the comments at the bottom 当然，“use strict”的12b重量不会改变任何事情。