大家好，今天来为大家解答Deno：探索代码在浏览器中的新天地这个问题的一些问题点，包括也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~
前言
2018 年 5 月，Ry 公开 Deno 的原型后不久我就开始参与这个项目了。对于 Deno，人们最常问的一个问题是“包管理器跑哪儿去了？”很多时候这都算不上问题，而只是一种吐槽。他们会说“我知道 Deno 很重视安全性，可是从互联网下载资源是不安全的。”或“没有管理器我该怎么管理依赖项啊？”
Deno相关知识优质文章：
「干货」通俗易懂的Deno 入门教程
「干货」了不起的 Deno 实战教程
「干货」Deno TCP Echo Server 是怎么运行的？
「实践」Deno bytes 模块全解析
手把手教你Node.js和Deno之前有何区别，以及分别讲述之间的特性
手把手教你从Node.js快速迁移到Deno
在我看来，我们应该改变自己的思维模式。因为包管理器和中心化代码库随处可见，所以很多人把它们当成了理所当然的需求。问题在于它们的流行并不是它们不可或缺的证明。这些事物之所以会出现，是因为它们以某种方式解决了问题，可大家就觉得这是解决问题的唯一途径了。我认为这种看法是不对的。
浏览器
想象一下这样的场景：在发布网站时，我们不是登录到一个谷歌中心服务器上，而是将我们的网站上传到一个存储库中。然后当有人想查看我们的网站时，他们要使用命令行工具，在我们本地计算机上的 browser.json 文件中添加一个条目，再访问并获取整个网站；另外还要获取链接到我们本地 websites 目录的其他所有网站，获取完毕后才能启动浏览器开始浏览。这也太疯狂了不是吗？那么为什么跑代码的时候就非得用这种模式呢？
我们了解代码所需的一切信息都可以由 HTTP 协议提供，并且 Deno 试着充分利用这种协议，这样就用不着发明新的了。
代码发现
首先要认识一点：就像浏览器一样，Deno CLI 不想对你运行的代码有任何意见（opinion）。它列出了如何获取代码，以及如何在计算机中使用沙箱运行代码的规则。我认为运行时应该表达的意见就到此为止才对。
在 Node.js/npm 生态系统中，我们将本地计算机上的代码管理与中心化代码存储库结合在了一起，从而帮助开发人员更方便地发现代码。我认为它们两者都有非常严重的缺陷。
在互联网的早期，我们就尝试过 npm 这一类的代码发现模式。你可以将你的网站添加到 Yahoo! 网站正确的分类下，然后人们就会来浏览；他们可能也会使用搜索功能，但所有这些都是基于内容提供者的观点来构建的，却并没有真正针对消费者的需求而优化。后来谷歌诞生了。为什么谷歌成为了赢家？因为它很好用。它将搜索词与满足需求的最相关网页匹配起来，用这种方式来索引网站；索引过程考虑了多种因素，内容提供商提供的元数据只是其中之一。
虽然我们还没有把这套模型纳入 Deno，但它是可行的方案。此外，我们之所以使用谷歌是因为它为我们解决了问题，而不是有人说“你必须使用谷歌”；而且谷歌还有其他可行的替代方案。
可重复构建
在 npm 生态系统中这是一个问题。由于严重依赖语义版本控制，并且复杂的依赖图往往来自 Node.js/npm 生态系统，因此想要让构建可重复就成了一个挑战。Yarn 引入了锁定文件的概念，npm 也跟上了脚步。
我个人感觉这有点像是在拆东墙，补西墙：生态系统中开发人员的行为造成了一个问题，然后为了解决它又开发出了一个不完善的解决方案。常年和生态系统打交道的人都知道，很多问题的解决办法就是 rm -rf node_modules package-lock.json && npm install。
而 Deno 为这个问题提供了两种解决方案。首先是 Deno 缓存模块。它可以将缓存 check in 到源代码版本控制中，使用 --cached-only 标志就不会检索远程模块。DENO_DIR 环境变量可用于指定高速缓存的位置，以提供更大的灵活性。
其次，Deno 支持锁定文件。--lock lock.json --lock-write 将使用给定负载所有依赖项的哈希值写出一个锁定文件。当使用 --lock lock.json 时，这将用于验证将来的运行。
还有一些命令可以管理可重复的构建。deno cache 将解析所提供模块的所有依赖项，并填充 Deno 缓存。deno bundle 可用于生成负载的单个文件“构建”，所有依赖项都已解析并包含在该文件中，因此将来的 deno run 命令只需要这一个文件即可。
信任规则
我认为这是另一个需要打破固有思维的领域。无论出于何种原因，我们都无条件地信任中心化存储库中的代码。我们甚至都没有考虑过这种信任是不是合理。不仅如此，我们相信其中的代码已完全审查了所有依赖项，进而信任这些依赖项。我们打开快速搜索框，输入 npm install some-random-package，然后就觉得万事大吉了。我认为丰富的 npm 软件包生态系统把人们惯坏了。
为了应对这种松懈和自满带来的风险，我们在工具链中加入了安全监视软件，用来分析我们的依赖项和数不清的代码，告诉我们哪些代码可能存在安全隐患。一些公司会开发自己的私有存储库，上面托管的软件包接受的审核可能比那个公共存储库中的更严格一些。
这就好像是房间中的那头大象。最佳策略是我们不应该信任任何代码。只要我们建立了这种认识，那么正视那头大象就会变得容易一些。但是，如果我们认为包管理器和中心化存储库可以解决这个问题，或者哪怕是帮助缓解了这个问题，其实我们就是在自欺欺人。实际上，我认为它们的流行让我们的警惕性下降了。“反正它是放在 npm 上，如果它有什么隐患，肯定会有人把它撤下去的。”
Deno 在这方面的工作还不尽如人意，但它起码有一个好的开始。它在启动时是零信任的，并提供了相当精细的权限调整。我个人不喜欢的一件事是 -A 标志，它基本上是在说“好的，那就允许一切权限”。焦头烂额的开发人员很难经得住它的诱惑，而不会去弄清楚自己真正需要的是哪些权限。
收回这些授权也是很困难的事情，要指明“这段代码可以做这件事，但这里的另一段代码就不行”，或者当代码提示自己要提升权限时，搞清楚这些代码是从哪儿来的——这些都是很麻烦的操作。希望我们能找到一种易用的机制，并结合一些在运行时好用且高效的方法来解决这些挑战。
不过，最近的一个变化在我看来是很不错的，那就是 Deno 不再允许你降级 imports。如果从 https:// 导入了某些内容，那么这些内容只能从其他 https:// 位置导入。这和禁止降级传输的浏览器模型是一致的。不过我还是认为从长远来看，最好取消所有未通过 https:// 进行的远程导入，就像服务 Workers 需要 HTTPS 一样。对此我们将拭目以待。
依赖管理
我认为我们需要坦率地谈谈 npm 生态系统中的依赖项。老实说，这个生态是有问题的。在这个生态系统中，这区区 5 行代码每周会下载 3 千万次：
https://github.com/juliangruber/isarray/blob/master/index.js
https://www.npmjs.com/package/isarray
可是过去 9 年来所有浏览器都有这些代码，Node.js 根本用不着它们——这样的生态系统是不正常的。在这个例子中，实际的代码只有 132 个字节，但打完包就变成了 3.4kb。可运行代码只占包大小的 3.8％。“这样也行！”
我觉得这种现状背后有几点成因。其中很重要的一点是我们走反了方向，用的是颠倒过来的模型。问题在于，这种倒退的模式已经改变了我们创建网站的方式。尽管没有中央存储库，但是在构建网站时，我们将下载所有依赖的代码，并将它们烘焙到服务器上加载的内容中，然后用户将一堆代码下载到他们的本地计算机上。一些证据表明，所下载的代码中只有大约 10％是所访问的站点或 Web 应用程序独有的，剩下的那些是我们下载到开发工作站并打包起来的代码。Snowpack 等解决方案就想要解决这种因为走错方向而导致的问题。
另一个重要的问题是我们的依赖项没有与我们的代码耦合起来。我们将依赖项放入 package.json，但我们的代码是不是会真的使用这些依赖项呢？另一方面，虽然我们的代码表示我们正在使用其他一段代码中的内容，但它与后者的版本之间并没有紧密的耦合关系。问题是另外这段代码会直接影响我们正在编写的代码，因为它们之间的确存在依赖关系。
综上所述，你仍然可能需要将远程（或本地）依赖项“重新映射”到代码中表达的内容上。在这种情况下，可以使用 import-maps 的一个不稳定实现。这是一个 W3C 提案规范。它允许提供一个映射，该映射会将代码中的特定依赖项映射到另一个源，可以是本地文件抑或远程模块。
https://github.com/WICG/import-maps
我们曾在 Deno 中实现了它很长一段时间，因为我们真的希望它会被广泛采用。遗憾的是，这只是 Chrome 的一项实验，尚未得到更广泛的采用。于是我们决定在 Deno 1.0 中将它放在 --unstable 标志后面。我个人认为它还是很有可能走向死胡同，应该避免使用它。
但是，但是，但是...
我想还是会有很多人对 Deno 的模型提出异议。我认为 Deno 尝试采取的策略（我非常赞同）是在出现实际问题时再做处理。我听到的很多反对意见来自刚入门 Deno 的新手，他们从未与 Deno 项目合作过，也没有试图理解不同的可能性。
话虽如此，如果我们都遇到了同一个问题，并且迫切需要在 Deno CLI 中进行某些更改，我相信 Deno 会去做的。但是很多所谓的问题根本就不存在，或者还有其他解决方法，用不着你的运行时操心那么多事情，或与外部程序耦合来管理代码。
因此，我希望大家尝试一下不用包管理器或中心化的包存储库，看看这样下来会有怎样的结果。你可能再也不会回头了！
推荐JavaScript经典实例学习资料文章
《前端存储除了 localStorage 还有啥？》
《Javascript 多线程编程的前世今生》
《微前端方案 qiankun（实践及总结）》
《「图文」V8 垃圾回收原来这么简单？》
《Webpack 5模块联邦引发微前端的革命？》
《基于 Web 端的人脸识别身份验证「实践」》
《「前端进阶」高性能渲染十万条数据(时间分片)》
《「前端进阶」高性能渲染十万条数据(虚拟列表)》
《图解 Promise 实现原理（一）：基础实现》
《图解 Promise 实现原理（二）：Promise 链式调用》
《图解 Promise 实现原理（三）：Promise 原型方法实现》
《图解 Promise 实现原理（四）：Promise 静态方法实现》
《实践教你从零构建前端 Lint 工作流「干货」》
《高性能多级多选级联组件开发「JS篇」》
《深入浅出讲解Node.js CLI 工具最佳实战》
《延迟加载图像以提高Web网站性能的五种方法「实践」》
《比较 JavaScript 对象的四种方式「实践」》
《使用Service Worker让你的 Web 应用如虎添翼（上）「干货」》
《使用Service Worker让你的 Web 应用如虎添翼（中）「干货」》
《使用Service Worker让你的 Web 应用如虎添翼（下）「干货」》
《前端如何一次性处理10万条数据「进阶篇」》
《推荐三款正则可视化工具「JS篇」》
《如何让用户选择是否离开当前页面？「JS篇」》
《JavaScript开发人员更喜欢Deno的五大原因》
《仅用18行JavaScript实现一个倒数计时器》
《图文细说JavaScript 的运行机制》
《一个轻量级 JavaScript 全文搜索库，轻松实现站内离线搜索》
《推荐Web程序员常用的15个源代码编辑器》
《10个实用的JS技巧「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（一）「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（二）「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（三）「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（四）「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（五）「值得收藏」》
《细品269个JavaScript小函数，让你少加班熬夜（六）「值得收藏」》
《深入JavaScript教你内存泄漏如何防范》
《手把手教你7个有趣的JavaScript 项目-上「附源码」》
《手把手教你7个有趣的JavaScript 项目-下「附源码」》
《JavaScript 使用 mediaDevices API 访问摄像头自拍》
《手把手教你前端代码如何做错误上报「JS篇」》
《一文让你彻底搞懂移动前端和Web 前端区别在哪里》
《提高你的 JavaScript 技能10 个问答题》
《JavaScript图表库的5个首选》
《一文彻底搞懂JavaScript 中Object.freeze与Object.seal的用法》
《可视化的 JS：动态图演示 - 事件循环 Event Loop的过程》
《教你如何用动态规划和贪心算法实现前端瀑布流布局「实践」》
《可视化的 js：动态图演示 Promises & Async/Await 的过程》
《原生JS封装拖动验证滑块你会吗？「实践」》
《如何实现高性能的在线 PDF 预览》
《细说使用字体库加密数据-仿58同城》
《Node.js要完了吗？》
《Pug 3.0.0正式发布，不再支持 Node.js 6/8》
《纯JS手写轮播图（代码逻辑清晰，通俗易懂）》
《JavaScript 20 年 中文版之创立标准》
《值得收藏的前端常用60余种工具方法「JS篇」》
《箭头函数和常规函数之间的 5 个区别》
《通过发布/订阅的设计模式搞懂 Node.js 核心模块 Events》
《「前端篇」不再为正则烦恼》
《「速围」Node.js V14.3.0 发布支持顶级 Await 和 REPL 增强功能》
《深入细品浏览器原理「流程图」》
《JavaScript 已进入第三个时代，未来将何去何从？》
《前端上传前预览文件 image、text、json、video、audio「实践」》
《深入细品 EventLoop 和浏览器渲染、帧动画、空闲回调的关系》
《推荐13个有用的JavaScript数组技巧「值得收藏」》
《前端必备基础知识：window.location 详解》
《不要再依赖CommonJS了》
《犀牛书作者：最该忘记的JavaScript特性》
《36个工作中常用的JavaScript函数片段「值得收藏」》
《Node + H5 实现大文件分片上传、断点续传》
《一文了解文件上传全过程（1.8w字深度解析）「前端进阶必备」》
《【实践总结】关于小程序挣脱枷锁实现批量上传》
《手把手教你前端的各种文件上传攻略和大文件断点续传》
《字节跳动面试官：请你实现一个大文件上传和断点续传》
《谈谈前端关于文件上传下载那些事【实践】》
《手把手教你如何编写一个前端图片压缩、方向纠正、预览、上传插件》
《最全的 JavaScript 模块化方案和工具》
《「前端进阶」JS中的内存管理》
《JavaScript正则深入以及10个非常有意思的正则实战》
《前端面试者经常忽视的一道JavaScript 面试题》
《一行JS代码实现一个简单的模板字符串替换「实践」》
《JS代码是如何被压缩的「前端高级进阶」》
《前端开发规范：命名规范、html规范、css规范、js规范》
《【规范篇】前端团队代码规范最佳实践》
《100个原生JavaScript代码片段知识点详细汇总【实践】》
《关于前端174道 JavaScript知识点汇总（一）》
《关于前端174道 JavaScript知识点汇总（二）》
《关于前端174道 JavaScript知识点汇总（三）》
《几个非常有意思的javascript知识点总结【实践】》
《都2020年了，你还不会JavaScript 装饰器？》
《JavaScript实现图片合成下载》
《70个JavaScript知识点详细总结（上）【实践】》
《70个JavaScript知识点详细总结（下）【实践】》
《开源了一个 JavaScript 版敏感词过滤库》
《送你 43 道 JavaScript 面试题》
《3个很棒的小众JavaScript库，你值得拥有》
《手把手教你深入巩固JavaScript知识体系【思维导图】》
《推荐7个很棒的JavaScript产品步骤引导库》
《Echa哥教你彻底弄懂 JavaScript 执行机制》
《一个合格的中级前端工程师需要掌握的 28 个 JavaScript 技巧》
《深入解析高频项目中运用到的知识点汇总【JS篇】》
《JavaScript 工具函数大全【新】》
《从JavaScript中看设计模式(总结)》
《身份证号码的正则表达式及验证详解(JavaScript，Regex)》
《浏览器中实现JavaScript计时器的4种创新方式》
《Three.js 动效方案》
《手把手教你常用的59个JS类方法》
《127个常用的JS代码片段，每段代码花30秒就能看懂-【上】》
《深入浅出讲解 js 深拷贝 vs 浅拷贝》
《手把手教你JS开发H5游戏【消灭星星】》
《深入浅出讲解JS中this/apply/call/bind巧妙用法【实践】》
《手把手教你全方位解读JS中this真正含义【实践】》
《书到用时方恨少，一大波JS开发工具函数来了》
《干货满满!如何优雅简洁地实现时钟翻牌器(支持JS/Vue/React)》
《手把手教你JS 异步编程六种方案【实践】》
《让你减少加班的15条高效JS技巧知识点汇总【实践】》
《手把手教你JS开发H5游戏【黄金矿工】》
《手把手教你JS实现监控浏览器上下左右滚动》
《JS 经典实例知识点整理汇总【实践】》
《简单几步让你的 JS 写得更漂亮》
《恭喜你获得治疗JS this的详细药方》
《谈谈前端关于文件上传下载那些事【实践】》
《面试中教你绕过关于 JavaScript 作用域的 5 个坑》
《Jquery插件（常用的插件库）》
《【JS】如何防止重复发送ajax请求》
《JavaScript+Canvas实现自定义画板》
《Continuation 在 JS 中的应用「前端篇」》
译者：王强
用户评论
我觉得这个比喻很棒！ Deno确实像个浏览器，它能加载和执行不同语言的代码，而且不受平台限制，就像在网页中访问不同的页面一样方便灵活。
有16位网友表示赞同！
作为一个资深 JavaScript 开发者，我以前一直依赖 Web 栈，现在开始探索 Deno 的新世界。 它的模块化能力确实强大，可以把我的项目变得更简洁高效。
有14位网友表示赞同！
我不太认同代码浏览器这个说法。尽管Deno支持多语言，但它更像是一个现代化的运行环境，专注于安全、性能和易用性。浏览器是用来渲染网页的，两者有着不同的目的。
有11位网友表示赞同！
确实，Deno 能够在多种平台下快速构建应用，而且安全性也得到提升，这对我来说非常重要。不过，还是需要更多工具和插件来完善生态系统。
有12位网友表示赞同！
我试用过 Deno 的内置的调试功能，感觉很棒！比以前的 Chrome 调试更直观易用，大大提高了开发效率～
有7位网友表示赞同！
我觉得这个比喻有点过于片面。Deno 更像是一个新的代码执行环境，它继承了 Node.js 一些优秀特性，并且进行了优化和改进。
有10位网友表示赞同！
虽然 Deno 还是个相对年轻的项目，但我相信它的生态系统会越来越完善。目前已经有很多优秀的库和工具支持 Deno，开发体验也越来越好
有13位网友表示赞同！
Deno 的语法简洁易懂，而且它自带了安全措施，不会像 Node.js 一样存在太多的安全风险。这对于我来说是最大的亮点。
有5位网友表示赞同！
期待 Deno 未来发展更多成熟的工具和框架，让它的生态系统更加完善！
有14位网友表示赞同！
代码浏览器这个说法挺新奇的，Deno 确实打破了传统开发模式，它让开发者能够更自由地掌控自己的代码环境。
有10位网友表示赞同！
我对开源项目一直以来都充满了热情，Deno 更是如此。它的透明性强，社区活跃，并且一直在不断改进，我相信 Deno 在未来会成为一个极具竞争力的开发环境
有20位网友表示赞同！
我比较喜欢 Node.js 的成熟生态系统和丰富的工具库，虽然 Deno 也在快速发展，但目前来说还是缺少一些关键的组件。
有20位网友表示赞同！
Deno 确实带来了很多新颖的想法和理念，它更注重安全性和可扩展性，这对于未来的 Web 开发非常有意义 。
有8位网友表示赞同！
我现在还在学习用 Deno 进行开发，它的学习曲线似乎比 Node.js 要友好一些。期待能够在未来使用 Deno 完成更多项目
有12位网友表示赞同！
我认为 "代码浏览器" 这个说法有一定的夸张成分，但它确实突出了 Deno 的开创性，它可以让开发者更容易地访问和管理不同的代码资源。
有9位网友表示赞同！
Deno 带来了许多新机遇，它让前端开发更跨平台，让后端开发更加安全可靠。我相信前端和后端之间的界限会越来越模糊，而 Deno 将成为连接两者的一座桥梁
有17位网友表示赞同！
我担心 Deno 的生态系统发展太慢，缺少一些常用的库和工具，这可能会影响它的普及率。
有14位网友表示赞同！