javascript中的沙箱并非传统意义上的沙箱，只是一种语法上的hack写法而已，javascript中处理模块依赖关系的闭包被称之为沙箱，和 ajax一样，这种sandbox coding风格是一种现象，而不是本质，本身并无对错之分，要看你怎么用，因此，理解并合理运用才是我们对“js沙箱”的一个正确的基本态度，“沙箱无用论”是很业余的观点。
——沙箱是一个工具。就和键盘和鼠标一样，我们需要他，但更要看我们怎么用他。
目前来看，js沙箱的优势在于代码的组织并向“应用”提供架构支持，js沙箱解决不了全局变量污染，多版本库的融合等基本问题，很多人对js沙箱抱有太高奢望，也是不对的。
—— 沙箱是一把利器。就像AK是巷战之王，可还是有人硬要拿它打飞机。
js沙箱已经开始影响B端开发，而且在前后端融合方面具有更多前瞻性的优势。
——沙箱是一把钥匙。ajax的流行改变了B端开发模式，我们有理由期待js沙箱在企业级开发中的表现。
当JavaScript第一次发布的时候，有一个可以理解的忧虑，那就是打开一个页面可能会直接在机器上执行一段代码。如果JavaScript中含有一些有害的代码，比如删除所有Word文档，或者更糟的是，向脚本的编写者复制这些Word文档，那该怎么办呢？
为了防止这种情况发生，同时也为了让浏览器的用户放心，JavaScript构建为只在沙箱中运行。沙箱是一个受保护的环境，在这个环境中，脚本不能访问浏览器所在的计算机资源。
另外，浏览器所实现的安全条件高出并超过了JavaScript语言所建立的最低条件。这些都定义在一个与浏览器相关的安全策略中，它决定了脚本能做什么不能做什么。例如，一个这样的安全策略规定脚本不能与脚本所来源的域以外的页面通信。大多数浏览器还提供了定制这一策略的方式，这可以使脚本所运行的环境限制变得更严或更松。
不幸的是，即便是有了JavaScript沙箱和浏览器安全策略，JavaScript还是经过了一段难熬的时光，黑客已经发现并充分利用了JavaScript的一些错误，有些错误与浏览器无关，有些错误与浏览器有关。较严重的一个是跨站脚本（cross-site scripting，XSS）。这实际上是一类安全破坏（其中一些通过JavaScript，另一些通过浏览器的漏洞，还有一些通过服务器），它能够导致 cookie dao qie、暴露客户端或网站的数据，或导致许多其他的严重问题。
从语言学的角度上来说，允许代码无节制地使用全局变量，是最错误的选择之一。而更可怕的，就是一个变量"可能"成为全局的（在未知的时间与地点）。但是这两项，却伴随JavaScript这门语言成功地走到了现在。