Deno 1.0

• 資深大佬 : tlerbao

  插图和头像啥的都是自己画的吗？

• 資深大佬 : ares586

  不知道能不能火起来，毕竟不支持兼容 node

• 資深大佬 : FourAndHalf

  啥，又出框架了？

• 資深大佬 : Mithril

  学不动了已经，昨天的 Flutter 还挂在墙上没学呢。

• 資深大佬 : gimp

  感觉将“包管理”集成在 deno 中不太好，主流都是分离的，如 Rust + cargo / Node.js + npm / Python + pip

  还需要观望一下，看在哪个领域能发光发热，生态再养一养，再学不晚。

• 資深大佬 : quarria

  这个是什么？

• 資深大佬 : jakehu

  @quarria nodejs 之父开发的新的框架

• 資深大佬 : liuxey

  node – deno – destroy node
  – dinosaur 恐龙

• 資深大佬 : JJstyle

  这个千万别火起来

• 資深大佬 : wszgrcy

  如果没有啥提高效率的举措，感觉不太可能火。。。顶多不温不火吧

• 資深大佬 : namelosw

  期待，不知道这个 Workflow 是不是比 Node + TypeScript 开发起来更快一些

• 資深大佬 : cmdOptionKana

  @namelosw 天生支持 TypeScript

• 資深大佬 : cmdOptionKana

  @JJstyle 如果你害怕学习新东西，反而应该期待这个火起来，因为这个还算与 javascript, node 比较接近。

  如果这个不火，必然有其他与 javascript, node 距离更远的东西会火，回来取代 node 。（看看 PHP 的下场）

  这个世界总有新东西取代旧东西，这点是防不住的。

• 資深大佬 : Hanggi

  @cmdOptionKana node.js 上已经有很多成熟的 typescript 解决方案，为什么要用你 deno 呢？

• 資深大佬 : xingjue

  @cmdOptionKana php 下场咋了,php 有 swoole 生态,吊打 Node 后端

• 資深大佬 : LokiSharp

  @cmdOptionKana #13 好像 node 后端市场也没多大吧。。。

• 資深大佬 : DixCouleur

  这个头……有点像 AirPods

• 資深大佬 : cmdOptionKana

  @xingjue 看趋势，看发展，PHP 明显已经被围攻，正在走下坡路了。

• 資深大佬 : xingjue

  @cmdOptionKana 这个是事实 但是 node 做后端是扶不起的阿斗，后端没人搞 Node 。就是一些前端在玩

• 資深大佬 : cmdOptionKana

  @Hanggi 因为讨厌 npm 。你看 yarn 一出来就非常受欢迎，而 yarn 只是解决了 npm 的一部分问题，而 deno 可以解决 npm 的大部分问题。

• 資深大佬 : xingjue

  写三行代码，依赖动则几百 M 乃至几个 G，这种东西也配做后端？别侮辱了后端行吗，还是你们前端慢慢意淫 node 吧（ PS 我是做 java 的）

• 資深大佬 : cmdOptionKana

  @xingjue
  @LokiSharp 我说的重点不是后端。而是不管什么领域的技术，自己不革自己的命，就会被别的新东西侵蚀市场。

• 資深大佬 : 5G

  deno 主要想做下面的改进：
  1.single_executable，是把模块打包成一个文件
  2.以 typescript 为主编程语言
  3.从 url 导入代码，打包时候用一下，各个 node 应用可以共享缓存
  4.更多新标准 API （ fetch ）
  5.内置更多工具
  6.与 Chrome V8 更好的合作
  7.支持 WASM

• 資深大佬 : Biwood

  如果能解决 npm 的诸多痛点那不是挺好的吗，我只希望一点，每次安装依赖的时候不要再让我的 MacBook Pro 散热器疯狂工作了。

• 資深大佬 : no1xsyzy

  @cmdOptionKana #22 当初会用 Perl 写的东西现在都转 Python 了…… 这种感觉？

• 資深大佬 : revalue

  历史的车轮从我身上压过

• 資深大佬 : dinjufen

  node_modules 无底黑洞能解决吗

• 資深大佬 : Niphor

  放心 过 3 年合并回 node

• 資深大佬 : yuchenyang1994

  挺适合做 GUI 的

• 資深大佬 : taxiaohaohhh

  @xingjue 写个 java 优越感这么高的？？？我第一的 php 都还没说话

• 資深大佬 : dayFvckingByte

  @taxiaohaohhh php 第一？？ python 默秒全（下继续）

• 資深大佬 : cai314494687

  @cmdOptionKana #18 PHP 年底就出 8 了，怎么就走下坡路了？

• 資深大佬 : LokiSharp

  @dayFvckingByte #31 Python 就算了吧。。。web 后端市场占有率和 Node 半斤八两。。。

• 資深大佬 : whypool

  解决几个痛点就能火，甚至能去挑战 java
  依赖包管理，没有 npm 那种套娃，可以使用类似 jar 包，或者.ts 的包
  集成 web 开发包，类似于 springboot，直接是官方维护，没有第三方那么多幺蛾子，就是如果用 deno 开发 web，只有唯一选择
  分布式，多线程

• 資深大佬 : FreshOldMan

  @dinjufen 无底黑洞是啥，搜了没搜到没有没有什么关键词

• 資深大佬 : dodo2012

  @xingjue rust 表示不服，rust 安装依赖一样大几百 m 上 g，我都服了。

• 資深大佬 : darksword21

  看好，喜欢新东西。。

• 資深大佬 : szzhiyang

  标准库抄 Go 的？

• 資深大佬 : szzhiyang

  到处都是 Go 的影子。

• 資深大佬 : tiedan

  @szzhiyang 最早是 go 写的，中期觉得不好换成了 rust

• 資深大佬 : coolmenu

  dotnet core 蔑视你们！！

• 資深大佬 : Trim21

  能不能直接当不需要 tsc 的 nodejs…

• 資深大佬 : kidlj

  https://github.com/Homebrew/homebrew-core/pull/54667 [for Mac users]

• 資深大佬 : Vegetable

  @gimp 你发这两个，Node 和 python，都被从不同的角度吐槽，Cargo 感觉受到了侮辱

• 資深大佬 : Vegetable

  @dinjufen 看到有文章提到了，解决这个问题用了两个改进，一个是 deno 会有官方库，避免 node 生态这种基础功能大量不同的实现造成的混乱，另一个是包不再存放在每个项目目录里，而是隐藏的一个目录，项目之间也许能共享一份依赖。

• 資深大佬 : linglongll

  这个衣服好贵啊 100 刀

• 資深大佬 : Immortal

  @Vegetable #45
  听起来很像 golang 的方案

• 資深大佬 : Vegetable

  @Immortal 你的直觉很敏锐。
  deno_std is a loose port of Go’s standard library. When in doubt, simply port Go’s source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We generally welcome direct ports of Go’s code.

  Please ensure the copyright headers cite the code’s origin.

• 資深大佬 : coolmenu

  @Vegetable 共享依赖，也有版本的问题吧？还是有明确的库版本号的定义了

• 資深大佬 : Immortal

  @Vegetable #48
  这个大概初版 deno 用 go 写也有联系
  作者应该也是个 golang 深度用户了 后来发现 gc 冲突后才转到 rust 吧

• 資深大佬 : aloxaf

  @dodo2012 那是编译中间产物，你用 release 的话就不会有那么多
  我采用的方法是设定一个统一的 target 目录，然后 systemd 设置一个定时清理任务将这个目录维持在一定大小（我设定的是 25 G，你可以根据自己项目大小调整）。而且能够复用其他项目的中间产物加快编译速度。

• 資深大佬 : yuankui

  看到了大神的名字 @justjavac

• 資深大佬 : Vegetable

  @coolmenu

  import { serve } from “https://deno.land/[email protected]/http/server.ts”;

  这条引用自动下载的缓存，看了一下缓存目录，和差不多 Go 一样是差不多形式的

  C:Users{username}AppDataLocaldenodepshttpsdeno.land

  但是内部是很多 hash 文件名加一个 metadata.json，这个 https 的含义不太确定。版本号在 metadata 里边有，应该是不同版本在缓存中共存。

• 資深大佬 : dreamerblue

  @xingjue 有趣，原来还可以用依赖大小作为评价维度啊，学习了

• 資深大佬 : Nugine0

  从某种角度上讲，deno 就是 node 修正各种失误后的样子。py2 到 py3 也是一个大撕裂，后来 py2 死了，时间会给出答案。

• 資深大佬 : pockry

  Serverless 时代，冷启动才是核心竞争力，node 很拉胯，Python 也一般，golang 好很多，如果 deno 能达到 golang 的冷启动以及方便部署，那我觉得它的前途是光明的。

• 資深大佬 : love

  看了介绍，感觉着一股王 8 之气，必火无疑

• 資深大佬 : Jirajine

  @FreshOldMan #35 应该是指的这个梗
  

• 資深大佬 : damingxing

  我说英文怎么写得这么专业

• 資深大佬 : hantsy

  Node 已经合并过一次了，说不定以后又会合并。

• 資深大佬 : whileFalse

  @pockry 这就扯淡了，解释型语言凭什么和编译型语言比冷启动速度
  而且这个玩意儿还要先把 ts 编译成 js，还不地 node 冷启动快
  当然，如果这玩意儿能在部署前构建成 wasm 那还能快一点

• 資深大佬 : hafuhafu

  第一感觉居然是…logo 很萌

• 資深大佬 : gimp

  @Vegetable 不用太敏感，我举例说明下包管理分离是常见做法。

  Cargo 设计的不错也很强大，但没必要贬损 npm 与 pip 。

• 資深大佬 : gimp

  @hafuhafu 喜欢 Logo +1 2333

• 資深大佬 : yafoo

  @xingjue 自己坐了高铁，然后抱怨高铁车太长，车上人多。自己坐了飞机，然后嫌弃飞的太高。既然只有三行代码，你完全可以步行啊。。。

• 資深大佬 : zoharSoul

  @xingjue 可是事实是 php 在下滑,node 在上升

• 資深大佬 : youxiachai

  justjavac 早年风评 md 程序员…
  但是老实说….实力还是比大部分人强….

• 資深大佬 : hronro

  @pockry @whileFalse
  Deno 在部署的时候可以可以直接加 V8 cache，冷启动还是很快的。
  关于 TypeScript 需要转译的问题，Deno 的官网上已经说了，“TSC must be ported to Rust”，现在虽然很慢，但未来换到 Rust 实现之后，速度会快很多的。

• 資深大佬 : cairnechen

  @youxiachai md 程序员是啥，搜了下没搜到，总不会是 markdown 吧

• 資深大佬 : youxiachai

  @cairnechen 就是 markdown …..这个属于当年的风评了…

• 資深大佬 : aaaaaaaaa

  @youxiachai

  “justjavac 早年风评 md 程序员”

  今年应该还是吧

• 資深大佬 : luozic

  实际上用 v8 做后端，最后是准备用 rust 做一个 typescript 的前端？

• 資深大佬 : Nugine0

  进一步了解可以看 Deno 中文手册，官方的由于 github 部分被墙而看不了。
  https://www.v2ex.com/t/671658

• 資深大佬 : fanchangyong

  比较关心直接使用 URL 作为引用包的地址，打起字来会不会手疼，以及包的版本如何统一管理

• 資深大佬 : xg4

  @fanchangyong
  第三方库放在 deps.ts 中，然后从 deps.ts 中引入到代码中，管理 deps.ts 就行
  url 过长可以使用 import_maps，https://deno.land/manual/linking_to_external_code/import_maps

• 資深大佬 : liuguang

  node 这个坑够大了，又开个新坑。与其用这玩意儿写后端，还不如直接用 rust 性能好, 后端性能这一块基本 pass 了。
  写前端的话，node 还是够用的，所以为啥用 deno 呢，deno 类库生态都没有。这玩意儿早点凉凉是最好的了。

• 資深大佬 : autoxbc

  @liuguang #76 Deno 在设计上是为了替代 bash 和 python 在系统管理中的应用，和 Rust 场景不重合

  注意 Deno 的作者同时精通 JavaScript Golang 和 Rust，但是他仍然认为需要这么一个属于程序员的”瑞士军刀”

  至于生态，Node.js 里的模块抛掉技术债，经过现代化改造后都是 Deno 的生态

• 資深大佬 : ayase252

  用 URL 来引入依赖很激进啊….最后感觉可能要 reinvent 包管理器

• 資深大佬 : cy476571989

  我自己做了一个翻译工具，叫 Breword, 专门用来翻译开源项目文档， 已经用它翻译了 redux, koa, node-mysql 等项目文档。

  最近我已经把 Deno 的文档抓取了下来，欢迎一起来翻译：

  https://www_breword_com/projects/5ebcb0f5ddcf37001b4c33eb

  一段好的翻译，必须建立在对原文充分理解的基础上，所以，在翻译文档时，也是一个非常好的学习机会。

  Breword 这个翻译工具支持自动监测文档更新，一旦源项目更新后，会在 Breword editor diff 出译文的差异，方便维护译文文档。所以，我们会持续将 deno 的中文文档维护下去。

  期待你的参与。

• 資深大佬 : charlie21

  为了卖衣服写了一个代码库，难道这就是有钱人的生活？

• 資深大佬 : DOLLOR

  我总感觉 deno 可能未干掉 node，反倒干掉了 node 的竞争对手，尤其是 php 。

• 資深大佬 : chengxiao

  @fanchangyong
  “比较关心直接使用 URL 作为引用包的地址”
  golang 最初就是这么做的，但是后面发现版本控制是个大问题，才不得不引入 go mod 来管理包

• 資深大佬 : MichealXie

  @liuguang node, deno 能三天上手，rust 起步 1 个月吧？而且大部分程序员都不会用 rust