1
00:00:00,000 --> 00:00:01,920
Deno的话 他们被

2
00:00:01,940 --> 00:00:03,280
Cloudflare收购了

3
00:00:03,300 --> 00:00:04,190
但说实话

4
00:00:04,280 --> 00:00:05,260
这其实也标志着

5
00:00:05,280 --> 00:00:06,370
他们创业失败了

6
00:00:06,480 --> 00:00:07,990
但是Deno它真的失败了吗

7
00:00:10,560 --> 00:00:11,380
大家好 这里是

8
00:00:11,400 --> 00:00:12,130
AsyncTalk

9
00:00:12,160 --> 00:00:13,430
主播 AnnatarHe

10
00:00:13,520 --> 00:00:14,760
今天的话我们来去聊

11
00:00:14,780 --> 00:00:16,180
一个前几天刚发的

12
00:00:16,200 --> 00:00:18,030
一个新闻是Deno

13
00:00:18,060 --> 00:00:18,740
其实我个人是

14
00:00:18,760 --> 00:00:20,060
比较关心Deno的发展

15
00:00:20,080 --> 00:00:20,480
因为Deno

16
00:00:20,500 --> 00:00:21,840
在最开始他出来

17
00:00:21,860 --> 00:00:22,980
的时候一些理念还是

18
00:00:23,000 --> 00:00:23,990
非常好的

19
00:00:24,080 --> 00:00:25,440
我其实有一些很小的

20
00:00:25,460 --> 00:00:26,460
一些小项目也是

21
00:00:26,480 --> 00:00:27,920
拿Deno来去做测试的

22
00:00:27,940 --> 00:00:30,440
这次Deno的话他们被

23
00:00:30,460 --> 00:00:32,040
Cloudflare收购

24
00:00:32,060 --> 00:00:33,480
我们当然应该恭喜

25
00:00:33,500 --> 00:00:35,080
就是他们终于拿到了

26
00:00:35,100 --> 00:00:35,700
一些成果

27
00:00:35,720 --> 00:00:36,520
但说实话

28
00:00:36,540 --> 00:00:37,760
这其实也标志着

29
00:00:37,780 --> 00:00:38,540
他们创业失败

30
00:00:38,560 --> 00:00:40,240
他们没能上市

31
00:00:40,260 --> 00:00:42,200
他们也没能去有

32
00:00:42,220 --> 00:00:43,060
一个更好的价格

33
00:00:43,080 --> 00:00:43,840
当然我不知道

34
00:00:43,860 --> 00:00:44,460
Cloudflare

35
00:00:44,480 --> 00:00:45,760
收购的价格是怎么样的

36
00:00:45,780 --> 00:00:48,060
但我相信应该不会到

37
00:00:48,080 --> 00:00:49,820
他们最开始所期望的

38
00:00:49,840 --> 00:00:52,540
那种吞噬世界的那种情况

39
00:00:52,560 --> 00:00:53,880
但我们并不聊商业

40
00:00:53,900 --> 00:00:54,460
我们只是

41
00:00:54,480 --> 00:00:56,670
来去回顾一下说Deno

42
00:00:57,100 --> 00:00:58,380
Deno它最开始是

43
00:00:58,400 --> 00:00:59,480
因为什么原因出现了

44
00:00:59,500 --> 00:01:00,480
Node是从

45
00:01:00,500 --> 00:01:01,920
2009年开始的话

46
00:01:01,940 --> 00:01:03,260
然后是因为Ryan

47
00:01:03,280 --> 00:01:04,980
他去做了一个演讲

48
00:01:05,000 --> 00:01:06,240
当然他最开始实现了

49
00:01:06,260 --> 00:01:07,260
一个初版的Node

50
00:01:07,280 --> 00:01:09,460
非常基础的一个版本

51
00:01:09,480 --> 00:01:11,220
那他当时对于业界的

52
00:01:11,240 --> 00:01:11,960
震撼是非常大的

53
00:01:11,980 --> 00:01:14,640
因为像是那个时候的话

54
00:01:14,660 --> 00:01:15,220
JavaScript

55
00:01:15,240 --> 00:01:17,280
它只能运行在浏览器里面

56
00:01:17,300 --> 00:01:19,380
去做一个非常无聊的脚本

57
00:01:19,400 --> 00:01:21,100
但Node它带来了

58
00:01:21,120 --> 00:01:22,720
非常不一样的东西

59
00:01:22,740 --> 00:01:24,200
Node它带来的是

60
00:01:24,220 --> 00:01:24,840
JavaScript

61
00:01:24,860 --> 00:01:26,240
终于可以运行在服务端了

62
00:01:26,260 --> 00:01:27,360
它等于说

63
00:01:27,380 --> 00:01:29,620
为web前端拓展出来了

64
00:01:29,640 --> 00:01:32,000
另外一片非常非常庞大的

65
00:01:32,020 --> 00:01:33,200
一个一块业务

66
00:01:33,220 --> 00:01:34,140
同时它也解锁了

67
00:01:34,160 --> 00:01:36,040
非常非常多的一种可能性

68
00:01:36,060 --> 00:01:37,420
但是JavaScript

69
00:01:37,440 --> 00:01:39,020
它运行在服务器的

70
00:01:39,040 --> 00:01:39,980
更大的冲击

71
00:01:40,000 --> 00:01:41,540
更多的是关于

72
00:01:41,560 --> 00:01:42,580
JavaScript的思想

73
00:01:42,600 --> 00:01:45,000
它终于在服务端上开始蔓延

74
00:01:45,020 --> 00:01:46,960
开始蚕食其他的概念

75
00:01:46,980 --> 00:01:48,880
因为在这之前的话

76
00:01:48,900 --> 00:01:50,580
你知道在服务端写程序

77
00:01:50,600 --> 00:01:52,060
它都是一个同步的概念

78
00:01:52,080 --> 00:01:53,620
你比如说

79
00:01:53,640 --> 00:01:54,720
这个API请求过来了

80
00:01:54,740 --> 00:01:55,460
要怎么办呢

81
00:01:55,480 --> 00:01:57,840
那我就首先解析

82
00:01:57,860 --> 00:01:59,900
那调DB可能是

83
00:01:59,920 --> 00:02:01,160
要先调一个Cache

84
00:02:01,180 --> 00:02:02,840
然后做计算调DB

85
00:02:02,860 --> 00:02:04,760
然后去返回用户

86
00:02:04,780 --> 00:02:05,600
那这一条都是

87
00:02:05,620 --> 00:02:06,560
一个串行的过程

88
00:02:06,580 --> 00:02:09,600
它就是你如果之前拿PHP

89
00:02:09,620 --> 00:02:10,580
或者Python的话

90
00:02:10,600 --> 00:02:13,300
它就是每一个请求过来

91
00:02:13,320 --> 00:02:14,780
它是开一个process

92
00:02:14,800 --> 00:02:16,140
那这个时候的话

93
00:02:16,160 --> 00:02:17,800
就慢慢去朝着

94
00:02:17,820 --> 00:02:18,220
Thread的

95
00:02:18,240 --> 00:02:19,040
方向来去做

96
00:02:19,060 --> 00:02:21,040
那之后的话还有更细粒度的

97
00:02:21,060 --> 00:02:22,280
像是什么fiber进程

98
00:02:22,300 --> 00:02:24,040
但它革命性的

99
00:02:24,060 --> 00:02:25,680
改变了这个思路吗

100
00:02:25,700 --> 00:02:26,420
其实并没有

101
00:02:26,440 --> 00:02:27,400
我说难听一点

102
00:02:27,420 --> 00:02:28,180
就是体力活的

103
00:02:28,200 --> 00:02:30,570
方式来去提升一些

104
00:02:31,080 --> 00:02:32,380
网络请求的吞吐量

105
00:02:32,400 --> 00:02:33,460
但JavaScript

106
00:02:33,480 --> 00:02:33,960
它不一样

107
00:02:33,980 --> 00:02:35,810
我相信你面试的时候

108
00:02:36,060 --> 00:02:37,600
你作为一个前端面试的话

109
00:02:37,620 --> 00:02:39,180
次次应该都会有问你什么

110
00:02:39,200 --> 00:02:39,960
JavaScript的

111
00:02:39,980 --> 00:02:40,560
这个event loop

112
00:02:40,580 --> 00:02:41,300
怎么做的

113
00:02:41,320 --> 00:02:42,600
那我们说回Node.js

114
00:02:42,620 --> 00:02:43,300
那Node.js

115
00:02:43,320 --> 00:02:44,100
在之后的话

116
00:02:44,120 --> 00:02:45,040
发生了什么问题呢

117
00:02:45,060 --> 00:02:47,400
那就是Node.js是

118
00:02:47,420 --> 00:02:49,040
Ryan它第一个版本写的

119
00:02:49,060 --> 00:02:50,280
他当时可能只是

120
00:02:50,300 --> 00:02:52,080
想来先去实现一下

121
00:02:52,100 --> 00:02:54,220
来去做一个小版本的验证

122
00:02:54,240 --> 00:02:55,580
OK发现它可以工作

123
00:02:55,600 --> 00:02:57,320
他当时据他自己说

124
00:02:57,340 --> 00:02:58,160
他就走了

125
00:02:58,180 --> 00:03:00,120
然后他去做一些其他的事情

126
00:03:00,140 --> 00:03:00,980
像是写Go

127
00:03:01,000 --> 00:03:02,400
但是在这最后的话

128
00:03:02,420 --> 00:03:03,940
Node.js是有很多问题的

129
00:03:03,960 --> 00:03:04,840
比如说你怎么在

130
00:03:04,860 --> 00:03:05,700
server发一个请求

131
00:03:05,720 --> 00:03:07,480
那你可以看到说

132
00:03:07,500 --> 00:03:08,500
在之前版本的话

133
00:03:08,520 --> 00:03:10,060
其实我们是去调一个

134
00:03:10,080 --> 00:03:11,540
std lib里边的

135
00:03:11,560 --> 00:03:12,400
HTTP方法

136
00:03:12,420 --> 00:03:13,520
然后这个HTTP方法

137
00:03:13,540 --> 00:03:14,380
它有一些Get

138
00:03:14,400 --> 00:03:16,140
或者说发请求的

139
00:03:16,160 --> 00:03:16,930
一些method

140
00:03:17,260 --> 00:03:18,140
它对于其他

141
00:03:18,160 --> 00:03:19,500
像是后端语言来说的话

142
00:03:19,520 --> 00:03:20,260
确实是这样

143
00:03:20,280 --> 00:03:22,240
但是它对于在我们

144
00:03:22,260 --> 00:03:24,780
以前端视角来看

145
00:03:24,800 --> 00:03:26,120
这个事情的话它对吗

146
00:03:26,140 --> 00:03:27,170
其实它不对

147
00:03:27,400 --> 00:03:28,480
简简单的我就说

148
00:03:28,500 --> 00:03:29,360
发请求这件事情

149
00:03:29,380 --> 00:03:31,120
其实它是有标准的方法的

150
00:03:31,140 --> 00:03:32,620
之前的话其实也不是很标准

151
00:03:32,640 --> 00:03:34,400
XMLHttpRequest

152
00:03:34,420 --> 00:03:35,620
对吧它也不是很标准

153
00:03:35,640 --> 00:03:36,600
但在之后的话它是

154
00:03:36,620 --> 00:03:37,540
有一些fetch方法的

155
00:03:37,560 --> 00:03:38,080
然后这个fetch

156
00:03:38,100 --> 00:03:38,760
方法就是说

157
00:03:38,780 --> 00:03:40,200
我们从客户端发起

158
00:03:40,220 --> 00:03:41,080
一个请求到服务端

159
00:03:41,100 --> 00:03:42,120
然后拿回一个返回

160
00:03:42,140 --> 00:03:42,860
但在Node

161
00:03:42,880 --> 00:03:43,720
出现的时候的话

162
00:03:43,740 --> 00:03:45,440
这个标准其实并不是

163
00:03:45,460 --> 00:03:45,900
很友好的

164
00:03:45,920 --> 00:03:46,580
那标准这个

165
00:03:46,600 --> 00:03:47,600
东西它有什么意义呢

166
00:03:47,620 --> 00:03:48,780
其实它的意义是

167
00:03:48,800 --> 00:03:49,760
非常非常巨大的

168
00:03:49,780 --> 00:03:51,220
因为它涉及到

169
00:03:51,240 --> 00:03:52,380
一个可读性的问题

170
00:03:52,400 --> 00:03:54,020
以及一个可维护性的问题

171
00:03:54,040 --> 00:03:55,760
因为它会极大的

172
00:03:55,780 --> 00:03:58,180
降低你的学习成本

173
00:03:58,200 --> 00:03:59,900
当你是一个纯前端

174
00:03:59,920 --> 00:04:01,140
你去转server的时候

175
00:04:01,160 --> 00:04:02,700
在前端你发请求是

176
00:04:02,720 --> 00:04:03,500
拿fetch去发

177
00:04:03,520 --> 00:04:05,240
你自然的就想到说

178
00:04:05,260 --> 00:04:06,060
那我在server

179
00:04:06,080 --> 00:04:07,640
我能不能还拿

180
00:04:07,660 --> 00:04:08,940
fetch来去发请求

181
00:04:08,960 --> 00:04:10,800
那这种符合直觉的方式

182
00:04:10,820 --> 00:04:12,320
其实才应该是

183
00:04:12,340 --> 00:04:13,920
一个正确的开发方式

184
00:04:13,940 --> 00:04:15,380
那它到我们这个

185
00:04:15,400 --> 00:04:16,120
AI时代的话

186
00:04:16,140 --> 00:04:17,480
就更为明显了

187
00:04:17,500 --> 00:04:18,760
因为在AI时代的话

188
00:04:18,780 --> 00:04:20,240
语义化对于AI来说

189
00:04:20,260 --> 00:04:21,740
是一个最核心最核心的东西

190
00:04:21,760 --> 00:04:24,660
它没有东西比语义化更重要

191
00:04:24,680 --> 00:04:26,000
所以标准化

192
00:04:26,020 --> 00:04:27,860
它非常大的影响了语义化

193
00:04:27,880 --> 00:04:30,260
以及长期的可维护性

194
00:04:30,280 --> 00:04:31,060
以及学习成本

195
00:04:31,080 --> 00:04:32,220
所以标准化是一个

196
00:04:32,240 --> 00:04:34,840
可能对Node.js来说

197
00:04:34,860 --> 00:04:36,100
最致命的一个问题

198
00:04:36,120 --> 00:04:37,420
当然Ryan他声称

199
00:04:37,440 --> 00:04:38,540
有很多其他问题了

200
00:04:38,560 --> 00:04:40,880
比如说像权限对吧

201
00:04:40,900 --> 00:04:43,560
那以及像npm包

202
00:04:43,580 --> 00:04:44,320
他怎么样去

203
00:04:44,340 --> 00:04:45,200
import一些

204
00:04:45,220 --> 00:04:46,060
第三方的

205
00:04:46,080 --> 00:04:47,140
library这些事情

206
00:04:47,160 --> 00:04:49,440
还有说top-level

207
00:04:49,460 --> 00:04:50,200
promise

208
00:04:50,220 --> 00:04:50,860
async

209
00:04:50,880 --> 00:04:51,920
await这种东西

210
00:04:51,940 --> 00:04:53,320
其实每一个都是

211
00:04:53,340 --> 00:04:54,620
挺严重的一个问题

212
00:04:54,640 --> 00:04:56,600
所以Ryan他起家去做了

213
00:04:56,620 --> 00:04:57,100
一个Deno

214
00:04:57,120 --> 00:04:59,100
然后Deno的话确实是

215
00:04:59,120 --> 00:05:00,500
在这些方面做的

216
00:05:00,520 --> 00:05:01,660
努力还是蛮多的

217
00:05:01,680 --> 00:05:03,100
他作为这样一个

218
00:05:03,120 --> 00:05:03,680
runtime的话

219
00:05:03,700 --> 00:05:05,320
他做的还是挺不错的

220
00:05:05,340 --> 00:05:06,540
然后他推动了很多事情

221
00:05:06,560 --> 00:05:08,540
包括像是很出名的

222
00:05:08,560 --> 00:05:09,520
一个binary

223
00:05:09,540 --> 00:05:10,820
因为你在做一个

224
00:05:10,840 --> 00:05:11,900
CLI程序的时候

225
00:05:11,920 --> 00:05:13,900
然后怎么样让其他人用起来

226
00:05:13,920 --> 00:05:15,440
他就打包成一个

227
00:05:15,460 --> 00:05:16,640
binary来让用户用

228
00:05:16,660 --> 00:05:18,040
像是大家都知道

229
00:05:18,060 --> 00:05:20,140
Bun在这点做得非常好的

230
00:05:20,160 --> 00:05:21,560
然后它确实也可以用

231
00:05:21,580 --> 00:05:22,760
它对于整个工具链

232
00:05:22,780 --> 00:05:25,240
也会比较像Go一点它的

233
00:05:25,260 --> 00:05:25,860
lint format

234
00:05:25,880 --> 00:05:27,380
其实我觉得做得还不错

235
00:05:27,400 --> 00:05:28,620
但它作为一家公司

236
00:05:28,640 --> 00:05:30,200
其实我觉得是有点失败的

237
00:05:30,220 --> 00:05:32,020
因为像是这种产品

238
00:05:32,040 --> 00:05:33,120
它怎么样去做盈利呢

239
00:05:33,140 --> 00:05:35,280
它其实基本上就卖云服务

240
00:05:35,300 --> 00:05:37,020
然后让别家的产品

241
00:05:37,040 --> 00:05:37,560
去host

242
00:05:37,580 --> 00:05:38,720
它在云服务上面

243
00:05:38,740 --> 00:05:39,620
然后它靠这个

244
00:05:39,640 --> 00:05:41,260
做一些小的盈利

245
00:05:41,280 --> 00:05:42,540
你可以看到说

246
00:05:42,560 --> 00:05:43,920
这个竞争极为激烈

247
00:05:43,940 --> 00:05:45,060
你等于说是说

248
00:05:45,080 --> 00:05:47,220
在和AWS在抢蛋糕还有

249
00:05:47,240 --> 00:05:50,260
像微软谷歌这种庞然大物

250
00:05:50,280 --> 00:05:52,160
那新兴的话更有像是

251
00:05:52,180 --> 00:05:53,220
Cloudflare像是

252
00:05:53,240 --> 00:05:54,660
Vercel这样的产品

253
00:05:54,680 --> 00:05:55,820
对于Deno来说

254
00:05:55,840 --> 00:05:56,960
竞争还是蛮大的

255
00:05:56,980 --> 00:05:58,960
那当然他之后又去做了

256
00:05:58,980 --> 00:05:59,950
一些像是

257
00:06:00,320 --> 00:06:02,300
JSR就是Package

258
00:06:02,320 --> 00:06:03,000
Registry

259
00:06:03,020 --> 00:06:03,840
这样的东西

260
00:06:03,860 --> 00:06:05,160
说实话对于npm的

261
00:06:05,180 --> 00:06:05,840
震撼来说

262
00:06:05,860 --> 00:06:07,380
只能说可有可无吧

263
00:06:07,400 --> 00:06:09,180
那一直到前几天

264
00:06:09,200 --> 00:06:10,340
Deno宣布

265
00:06:10,360 --> 00:06:11,840
加入Cloudflare

266
00:06:11,860 --> 00:06:14,240
那这就是它的结局了

267
00:06:14,260 --> 00:06:15,420
Deno作为一家公司的话

268
00:06:15,440 --> 00:06:18,060
它的结局其实还是

269
00:06:18,080 --> 00:06:18,840
令人唏嘘的

270
00:06:18,860 --> 00:06:21,200
然后他一直在想办法比如说

271
00:06:21,220 --> 00:06:24,040
做celld这个项目

272
00:06:24,060 --> 00:06:25,340
但收效甚微吧

273
00:06:25,360 --> 00:06:27,170
但是Deno它真的失败了吗

274
00:06:27,660 --> 00:06:28,860
我不觉得Deno失败了

275
00:06:28,880 --> 00:06:30,580
因为Deno在最开始

276
00:06:30,600 --> 00:06:32,840
他声称要去解决的那些问题

277
00:06:32,860 --> 00:06:35,120
到现在为止你回过头看

278
00:06:35,140 --> 00:06:36,300
Node.js多多少

279
00:06:36,320 --> 00:06:37,940
少都是有一些提升的

280
00:06:37,960 --> 00:06:39,480
就尤其是针对这些点

281
00:06:39,500 --> 00:06:40,340
那像是它的

282
00:06:40,360 --> 00:06:42,140
另一个竞争对手Bun

283
00:06:42,160 --> 00:06:44,440
也是很大程度上去遵循了

284
00:06:44,460 --> 00:06:45,920
Deno的一些设计点

285
00:06:45,940 --> 00:06:48,120
一些思想那像是

286
00:06:48,140 --> 00:06:49,300
Deno里边最为出名

287
00:06:49,320 --> 00:06:50,540
就是它可以原生写

288
00:06:50,560 --> 00:06:51,760
TypeScript去执行

289
00:06:51,780 --> 00:06:52,720
Node里边的

290
00:06:52,740 --> 00:06:53,560
24版本的话

291
00:06:53,580 --> 00:06:54,530
它也支持

292
00:06:54,860 --> 00:06:58,620
像是安全一些权限的限制

293
00:06:58,640 --> 00:07:00,640
那Node最近也是有的

294
00:07:00,660 --> 00:07:02,320
不过它例如没有

295
00:07:02,340 --> 00:07:03,120
Deno那么细了

296
00:07:03,140 --> 00:07:04,800
但它也有对吧它能用

297
00:07:04,820 --> 00:07:05,720
那么像是

298
00:07:05,740 --> 00:07:06,420
top-level的

299
00:07:06,440 --> 00:07:07,260
Promise以及

300
00:07:07,280 --> 00:07:07,940
async await

301
00:07:07,960 --> 00:07:09,140
现在也都有了

302
00:07:09,160 --> 00:07:10,600
像是API的标准化

303
00:07:10,620 --> 00:07:11,320
现在的话

304
00:07:11,340 --> 00:07:12,480
Node其实做的

305
00:07:12,500 --> 00:07:13,940
还是不错的

306
00:07:13,960 --> 00:07:14,920
对所以Deno

307
00:07:14,940 --> 00:07:15,840
最开始声称的点

308
00:07:15,860 --> 00:07:16,600
到现在的话

309
00:07:16,620 --> 00:07:18,480
Node都有一些解决

310
00:07:18,500 --> 00:07:20,540
因为它现在吸取了

311
00:07:20,560 --> 00:07:21,200
一些Deno的

312
00:07:21,220 --> 00:07:22,160
一些想法

313
00:07:22,180 --> 00:07:22,860
一些设计

314
00:07:22,880 --> 00:07:24,000
那我们说回Deno

315
00:07:24,020 --> 00:07:24,720
那Deno的话

316
00:07:24,740 --> 00:07:26,460
它的商业成绩并不是很理想

317
00:07:26,480 --> 00:07:27,860
但是Deno的理念

318
00:07:27,880 --> 00:07:29,180
却在Node.js

319
00:07:29,200 --> 00:07:31,380
以及Bun上面得到了

320
00:07:31,400 --> 00:07:32,500
很大的一个体现

321
00:07:32,520 --> 00:07:33,640
在Deno出来的时候

322
00:07:33,660 --> 00:07:34,920
它定义了说

323
00:07:34,940 --> 00:07:35,600
JavaScript的

324
00:07:35,620 --> 00:07:35,920
runtime

325
00:07:35,940 --> 00:07:37,040
它应该是一个什么样子

326
00:07:37,060 --> 00:07:37,740
随后Deno

327
00:07:37,760 --> 00:07:39,380
它率先表态来去做

328
00:07:39,400 --> 00:07:41,500
出来这样一些改进

329
00:07:41,520 --> 00:07:42,360
那Node

330
00:07:42,380 --> 00:07:44,220
虽然它进展比较迟缓

331
00:07:44,240 --> 00:07:45,840
但它也算是跟上了

332
00:07:45,860 --> 00:07:47,000
那Bun的话

333
00:07:47,020 --> 00:07:48,820
它另辟蹊径最近

334
00:07:48,840 --> 00:07:50,300
卖身给Anthropic

335
00:07:50,320 --> 00:07:51,500
过得可是太滋润了

336
00:07:51,520 --> 00:07:53,740
当然它其实也是遵循了很多

337
00:07:53,760 --> 00:07:55,580
Deno当时希望

338
00:07:55,600 --> 00:07:56,040
Jaloscope

339
00:07:56,060 --> 00:07:56,480
runtime

340
00:07:56,500 --> 00:07:57,720
去实现的一些东西

341
00:07:57,740 --> 00:08:00,360
那我更想表达的是说

342
00:08:00,380 --> 00:08:02,160
有些时候成功和失败

343
00:08:02,180 --> 00:08:03,980
概念我们是要打引号的

344
00:08:04,000 --> 00:08:04,880
因为看起来

345
00:08:04,900 --> 00:08:06,220
Deno它失败了但是

346
00:08:06,240 --> 00:08:07,420
对于Jaloscope的用户

347
00:08:07,440 --> 00:08:09,060
以及整个业界来说的话

348
00:08:09,080 --> 00:08:11,400
Deno的理念得到了实践

349
00:08:11,420 --> 00:08:13,940
Deno的追求得到了结果好的

350
00:08:13,960 --> 00:08:14,960
那大家可以

351
00:08:14,980 --> 00:08:16,160
在评论区来聊一聊

352
00:08:16,180 --> 00:08:17,400
说你有没有用过Deno

353
00:08:17,420 --> 00:08:19,080
你用过Deno的哪些特点

354
00:08:19,100 --> 00:08:20,520
你怎么看待Deno好的

355
00:08:20,540 --> 00:08:22,090
那我们下期节目再见拜拜