V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
GeekHub
a132811
V2EX  ›  程序员

看了 deno, 感觉 ts 前景不可估量啊

  •  
  •   a132811 · 197 天前 · 11047 次点击
    这是一个创建于 197 天前的主题,其中的信息可能已经有所发展或是发生改变。

    感觉 deno 这种明确带版本号的引入方式,才是解决版本依赖的最佳方式,简洁、明确、不混淆,或许能产生比 npm 更强的生态。

    import { serve } from "https://deno.land/[email protected]/http/server.ts";
    const s = serve({ port: 8000 });
    console.log("http://localhost:8000/");
    for await (const req of s) {
      req.respond({ body: "Hello World\n" });
    }
    

    终于不用再被 package.json 和 node_module 以及 AMD-CMD 折磨了。

    就是在文件中手写 url 有点麻烦,要是能支持 domain 的 alias、支持默认版本 latest 就更好。

    	// .deno/config
        const cdn_npm = 'https://npm.cdn.deno';
        
    	// main.ts
    	import echo_latest from "cdn_npm/echo.ts"  
    	import echo_v2_1_1 from "cdn_npm/[email protected]"  
    	import echo_v2_1_0 from "cdn_npm/[email protected]"  
    
    第 1 条附言  ·  195 天前
    关于 url+version 导致项目升级版本麻烦的问题。deno 有一个更干净的方案,用全局的 deps.ts 代替 package.json
    ```
    // deps.ts
    export {
    assert,
    assertEquals,
    assertStrContains
    } from "https://deno.land/std/testing/v0.1.1/asserts.ts";


    // app.ts
    import { assertEquals, runTests, test } from "./deps.ts";
    ```
    围绕 deps.ts ,我们可以编写版本管理命令行工具。

    node 的 PnP 方案解决了 node_modules 重复包问题,这个方案还不像 deno 那么简洁。Pnp 方案在安装时要层层解析 package.json,然后要维护一张很大的.pnp.js 映射表。PnP 与现有项目、vsocde/typescript 配合时要做一点额外的配置。
    58 条回复    2020-05-14 10:05:18 +08:00
    isukkaw
        1
    isukkaw   197 天前
    然后 deno 用的 CloudFront 哪天被入侵了(就像 16 年网宿一样),然后依赖全部 GG ?
    从 URL import 依赖只适合写点小玩意,但是并不意味着就可靠。
    tyrealgray
        2
    tyrealgray   197 天前
    那到时候批量升级版本的时候岂不是要改疯?
    a132811
        3
    a132811   197 天前
    这一点不能否定 deno import
    @isukkaw 所有的依赖都会有这个 问题。golang mod, pypi, npm 无一幸免啊。
    tonytonychopper
        4
    tonytonychopper   197 天前
    package.json 里也会带版本号,我觉得像这样引入才麻烦吧,还是说除此之外还解决了什么痛点?
    a132811
        5
    a132811   197 天前
    @tyrealgray 批量升级版本,靠 ide 和 vscode 就可以解决。新引入一堆包,版本冲突、不明确,带来的问题,才更容易疯。
    或许,加上 import 别名 这个方案值得考虑一下。
    murmur
        6
    murmur   197 天前   ❤️ 1
    以前就有 js 的 cdn,然后一个 cdn 一挂或者被墙多少网站打不开
    isukkaw
        7
    isukkaw   197 天前
    @a132811 #3
    NPM 这类依赖管理都有 SHA 校验完整性,deno 这种从 URL 就直接下来了啊。
    henvm
        8
    henvm   197 天前
    @isukkaw 好奇,16 年网宿 怎么样了?可以讲讲?
    wangxiaoaer
        9
    wangxiaoaer   197 天前 via Android   ❤️ 9
    把依赖跟仓库绑定简直太搞笑了,包括 golang
    a132811
        10
    a132811   197 天前
    @isukkaw 这个问题值得讨论啊,我的想法是 https 也足够了吧。
    sha 检验完整性,要基于首次下载的 sha 也是合法的基础上。如果首次下载或者更新是 被篡改的,这个 sha 也没有啥用。
    如果需要 sha 检验,deno import 也完全可以缓存包时,也生成一份 sha 啊。这个可以提 issue。


    而且 deno 比 node 更关心安全,npm 的现状就相当不安全,network 以及本地的 file system 全都没有做权限 控制。在如此不安全的情况下,前端不也用得很欢快吗。
    HuHui
        11
    HuHui   197 天前 via Android
    导包就已经很麻烦了,你还要带个版本号
    mnssbe
        12
    mnssbe   197 天前
    @isukkaw 依赖会本地缓存的, 如果网络缓存之前就出问题了那是有问题 , 不过这是很多项目很多人对要面对的问题
    manami
        13
    manami   197 天前 via Android
    从这个看不出 deno 的前景,不过 ts 写起来还是很爽的,vue 3 的到来也将加快 ts 的发展!
    ipwx
        14
    ipwx   197 天前   ❤️ 3
    过分苛求包管理器的版本号固定本来就是本末倒置,真正应该做的是呼吁包开发者尊重 semantic version,保持基本的兼容性。毕竟是个人就会犯错,写出来的包有个小 bug 再正常不过了。一般这种解决方案就是找作者,或者提 pull request,把这个 bug 修了,版本号涨一下。

    强行固定版本号的做法,相当于对将来的 bug fix 都说 no。这在前端或许还能糊弄糊弄,到后端分分钟给你黑出翔来信不信?也就是前端为主的 node 社区敢这么玩。。。
    autoxbc
        15
    autoxbc   197 天前
    >>支持默认版本 latest 就更好
    可以不带版本号,看这里的例子
    https://deno.land/std/http/

    有些人不理解 Deno 的模块机制为何如此设计,因为 Deno 的愿景是与浏览器同构;
    即:如果脚本没有引用 Deno 内置的全局对象,那么应该可以直接运行在浏览器中

    所以,Deno 尽量不脱离 ECMAScript 创造额外的概念
    azh7138m
        16
    azh7138m   197 天前 via Android
    yarn/npm 也能带明确版本号

    ts 并不需要 deno 背书
    azh7138m
        17
    azh7138m   197 天前 via Android
    看了下
    20-30k 的前端不知道 npm/yarn 可以带明确的版本号
    我有点害怕
    rayhy
        18
    rayhy   197 天前 via Android
    不懂 js,不过想问一下,这个特性可能被 node 抄袭吗?就是在兼容原有方案的同时支持这个。一两项优点不足以让人迁移吧
    liufengsoft722
        19
    liufengsoft722   197 天前
    Golang 不早就这样做了, 但是并没感觉出来有什么优势。Java 的 Maven 仓库用起来也很好用。npm。。。
    tonytonychopper
        20
    tonytonychopper   197 天前
    @rayhy deno 貌似是 node 之父开发的,所以如果支持这个也不知道算不算抄袭 😂
    fewok
        21
    fewok   197 天前
    将 java 转译成 js,感觉更有前景。。。
    optional
        22
    optional   197 天前 via iPhone
    @liufengsoft722 我觉得 npm 比 maven 好用。。。。除了浪费一些磁盘
    isukkaw
        23
    isukkaw   197 天前
    @azh7138m #17
    不知道 npm 和 yarn 有版本管理、不知道 HTTPS 不能保护服务器被入侵导致的投毒( 16 年网宿数据中心被入侵导致 jsDelivr 和七牛的 CDN 服务受到严重影响),这种前端在 V2EX 掘金 SegmentFault 上比比皆是。对此不必感到吃惊、我们也只能暗自幸运我们的知识面比他们会 *略微* 宽广一些。
    Buges
        24
    Buges   197 天前 via Android
    把 URL 硬编码到代码中是最睿智的行为,一个广泛使用的库维护者 GitHub 改个名字全都爆炸。
    其实 npm 是非常好用的包管理,但问题是生态太乱,随便装个包后面跟几十上百个依赖一大坨小文件堆硬盘上,右键 node_modules 目录属性一看:size: xxx MB , size on disk : x.xx GB
    explore365
        25
    explore365   197 天前
    @rayhy node deno 看名字
    love
        26
    love   197 天前
    @optional 浪费磁盘也快要成过去式了,现在的 yarn2 就可以全机共享同一包文件
    janxin
        27
    janxin   197 天前   ❤️ 3
    什么时候 TS 不兼容 JS 的坑我觉得更有前途...
    keelii
        28
    keelii   197 天前
    有关 deno 的视频可以去我的 bilibili 了解一下。各种搬运 😂
    otakustay
        30
    otakustay   197 天前   ❤️ 8
    yarn:任何需要网络的依赖安装是不明智不安全的,是会被包管理的 BUG 影响的,我们要全本地 cache,所以我们发了 yarn 2.x !
    deno:放你的狗屁,全网络依赖!
    Mohanson
        31
    Mohanson   197 天前 via Android
    偏向看好没有历史包袱的 wasm, ts 对 js 态度暧昧,不如彻底抛弃 js。用 C 和 rust 写前端想想就刺激…
    fumichael
        33
    fumichael   197 天前
    @love #26 真的吗,那就是会像 maven 的本地 repo 那样?
    ipwx
        34
    ipwx   197 天前
    @Mohanson C 和 rust 那种语法,你还想写前端?前端 boy 连上游库的 bug fix 都不在意。。。
    azh7138m
        35
    azh7138m   197 天前 via Android
    @fumichael 是真的。。。webpack5 支持 PnP
    4 需要配置一下,也能支持
    周边生态可能会炸,但总是一个好的开始(
    chiuan
        36
    chiuan   197 天前
    ts 还可以。但是我觉得引用是真的很烦。
    a132811
        37
    a132811   197 天前
    @azh7138m @isukkaw npm/yarn 的版本控制也没有完全解决版本冲突的问题,还存在 node_module 体积爆炸问题,阿里 umi 框架初始化 node_module 就超过 1G,每次 ci/cd 上线 都是灾难。

    HTTPS 不能保护服务器被入侵导致的投毒,npm 同样也不能保证不被人挂马啊。

    你不能说因为 cdn 服务出现问题就 废 CDN 方案,npm 包挂马、不稳定大家不也用了这么多年了吗?而且你说的这些问题,也有很多方案,就看自己承受的成本了。安全本来就是相对的,光谈安全风险不讲自己需要的安全级别吗?
    ----------
    ps: 我的前端知识面确实很窄,还望知识面*略微*宽广的前辈多多指教,万分感谢~
    a132811
        38
    a132811   197 天前
    @otakustay 看了 yarn2 的 pnp 方案,比较期待。我记得以前 npm 有一个通过软链接共享重复包的方案,后来被放弃了。
    另外 deno 的包,也同样要本地 cache 的。
    Osk
        39
    Osk   196 天前 via Android
    看到网络依赖我流下了不争气的泪,可能大家还没被网络搞哭过吧。

    go get, 搞不好半小时起步,再搓一点,直接无法完成。
    pip install,几 kb,下至 0kb。常常失败。
    npm 文件系统爆炸,xxx 框架初始化占用空间 200MB, 共 20,0000 个文件
    ericgui
        40
    ericgui   196 天前
    ts 前景不可估量
    deno 前景,不知道
    chenxytw
        41
    chenxytw   196 天前
    @a132811 其它不清楚,pypi 可以搞私有仓库,定期同步外网线上的就行了。类似 16 年那事,是有“可能”躲过去的 0 0
    chenluo0429
        42
    chenluo0429   196 天前 via Android
    @fewok kotlin for javascript,用起来很别扭
    tairan2006
        43
    tairan2006   196 天前
    golang 没说必须用 GitHub 啊,golang 的私有库很容易建的
    azh7138m
        44
    azh7138m   196 天前 via Android
    @a132811
    deno 的版本控制也没有完全解决版本冲突的问题,还存在 cache 体积爆炸问题(只是你看不见了)。
    $HOME/.cache Linux
    $HOME/Library/Caches/deno OSX
    可以看一下

    [email protected] 37w 依赖,它需要覆盖常见的各种开发场景,主张 all in one,开箱即用,整个 webpack 生态里面常见的 loader/plugin 都会被安装,这个体积也没啥好的办法,但并没有 1G 这么夸张。
    [email protected] 体积应该是变小了。

    npm 可以自建源,减少不可控的程度,而且是无侵入的。
    DOLLOR
        45
    DOLLOR   196 天前
    @fewok
    目前转译成 js 能称得上成功的,只有 ts 了,其他的要么昙花一现( coffeescript ),要么误入歧途( scala.js ),要么无人问津( jsweet )。不如编译成 WebAssembly,虽然这个方向在短时间内也看不到前景。
    TypeError
        46
    TypeError   196 天前
    @Osk #39 我都默认境外流量=墙外了,下依赖一律梯子( proxychains/sstap/环境变量等方式)
    jieyuxue
        47
    jieyuxue   196 天前 via Android
    onfuns
        48
    onfuns   196 天前
    node 是前端技术发展的里程碑,而 deno 最多算造轮子,最终这个轮子会不会安到汽车上,就难说咯
    reus
        49
    reus   196 天前 via Android
    @wangxiaoaer 无知,除了源头仓库有代码,代理也有代码,本地也有代码,别人的机器上也有代码,想彻底删除一个广泛使用的库,根本是不可能的。包的导入路径只是一个名称,它不绑定到一个仓库。
    wangxiaoaer
        50
    wangxiaoaer   196 天前
    @reus #49 听不明白别人什么意思的就别来回复丢人了。
    reus
        51
    reus   196 天前 via Android
    @wangxiaoaer 呵呵。操你妈逼。
    a132811
        52
    a132811   196 天前
    @Osk 你那是墙的问题,不能怪网络。pypi/npm/golang/docker/maven 可以用 artifactory 这一类工具统一建镜像。

    @azh7138m deno cache 的体积哪有你说的那么 爆炸。deno 的 cache 目录结构明确单一。
    它应该跟~/.npm 这个 cache 目录一一对应才对,不能跟 node_modules 相提并论(deno 目的就是砍掉 node_modules)。node_modules 爆炸的原因是高度碎片化、重复的包(除非开启 yarn pnp)

    [email protected] 创建 antd-pro 时,我没有记错的话,不加 puppeteer 这个依赖的话就有 1.3G 的 node_modules。node_modules 额外造成的体积臃肿,这事跟 all_in_one 和开箱即用是两码事。
    [email protected] 还没有发版吧,但我不觉得其体积能显著减少,毕竟 npm 碎片化 这一事实改变不了
    azh7138m
        53
    azh7138m   196 天前 via Android
    > node_modules 爆炸的原因是高度碎片化、重复的包

    yarn/npm 现在就能解决(仅限版本语义一致时)包重复的问题

    依赖深不见底,体积庞大,那是生态的问题,并不是 yarn/npm 或者说是 node 本身的技术问题


    [email protected] 已经有了
    loading
        54
    loading   196 天前 via Android
    萌新有个疑问,npm 的包就不能以 tar 包形式存放呢,一堆碎文件,mmp。
    yuanfnadi
        55
    yuanfnadi   195 天前
    @ipwx 阿里的 node 就是不锁版本的。
    ddzy
        56
    ddzy   195 天前
    packlock 不香吗
    linkdesu
        57
    linkdesu   194 天前
    deno 让我比较担心的一点就是真正用在工程化的问题上以后,加上持续集成、单元测试等等一整套下来,最后还是需要 npm。如果只是做一点玩具,用不用目前的 deno 区别真的不大,别忘了我们还有个 ts-node 呢。
    dayFvckingByte
        58
    dayFvckingByte   129 天前
    @Osk 你可以花 1 天时间折腾一下 vpn,不然永远陷入这种生活了
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   921 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 20:31 · PVG 04:31 · LAX 13:31 · JFK 16:31
    ♥ Do have faith in what you're doing.