如何缩小Lit-HTML(包括评论)

Lon*_*est 0 javascript typescript hyperhtml webpack-4 lit-html

我决定通过以下方式试用lit-html:

npm install lit-html --save
Run Code Online (Sandbox Code Playgroud)

我听过很多次(来自不同的来源)lit-html的大小只有2或3KB,但是只通过导入html渲染导出它导致我的webpack增长超过13KB.这比预期的要大得多.

此外,最终的dist包中嵌入了7次:

/**
 * @license
 * Copyright (c) 2017 The Polymer Project Authors. All rights reserved.
 * This code may only be used under the BSD style license found at
 * http://polymer.github.io/LICENSE.txt
 * The complete set of authors may be found at
 * http://polymer.github.io/AUTHORS.txt
 * The complete set of contributors may be found at
 * http://polymer.github.io/CONTRIBUTORS.txt
 * Code distributed by Google as part of the polymer project is also
 * subject to an additional IP rights grant found at
 * http://polymer.github.io/PATENTS.txt
**/
Run Code Online (Sandbox Code Playgroud)

那有点过分了.

我认为webpack 4可能会自动删除评论.如何使用我的所有其他代码(其中注释被自动删除,所有内容只是在一行中拼凑在一起)来最小化这个代码?

如果它过于干扰,我可以没有lit-html.

And*_*chi 11

这个问题是对Web开发现在出了什么问题的一个很好的总结,因此我决定采用这个答案,提供回答OP所有子问题所需的各种细节.

依赖性只是因为?

我曾多次(从各种渠道)听到lit-html的大小只有2或3KB

为了在软件中产生最佳结果,我们通常决定包含一些依赖性,因为它的功能,它为我们解决的问题,以及最终的解决方案.

事实上人们说一个库或实用程序很小,不应该自动转换成" 然后我会包含它 ",特别是当你的最后一个声明是:

我可以没有lit-html

因为我不觉得在你的问题还是会用很大的努力,甚至热情点燃,HTML,你确定你甚至需要它呢?

错误衡量的权衡

当我们谈论" Web事物 "时,我们通常会讨论生产代码,以及用于获取此类生产代码的所有常识技术和最佳实践.

这包括静态文件的使用压缩,因此在默认情况下,导入刚刚renderhtml亮,HTML会产生3.5KB的包作为微细化以及压缩生产规模.

这就是你的数字来自哪里,即使比它的第一个版本略大,其中基本工作确实在大约2Kb(缩小和gzip),lit-html提供已经足够的3.5Kb的果汁,这个大小绝对不相关万维网的其余部分.

favicon.ico的,或请求得到它,携带所有最终饼干,可能体重已经是类似的,如果没有更大的字节数,金额.

您确定互联网,甚至您的网站的问题是一个额外增加3.5Kb的库吗?

主要专家建议移动导向预算不到170Kb,缩小和压缩,大约是亮点的48倍,我认为这对你的初始逻辑来说还有足够的空间.

关于批评许可证

此外,最终的dist包中嵌入了7次:

不仅压缩使重复的文本大小几乎无关紧要,你正在争论Google产品的许可文本,如果我是你,我会小心隐藏任何意思.

我认为webpack 4可能会自动删除评论.

当写入评论时,/*! important */这些评论通常由缩小器保留,因为源代码的作者意味着留下该评论.

这是保持许可证的常用技术,但即使有工具不关心任何类型的评论,除非另有说明,例如--comments=/^!/通过uglify-js,请记住您的网站,应用程序,项目,即使用第三方软件时,必须 以某种方式包含 此类软件许可.

我相信你并不是要诋毁Polymer团队或Google许可证,但由于这件事非常微妙,我认为最好确保我们所有人都在同一页上.

无论如何,如何最小化

如何使用我的所有其他代码(其中注释被自动删除,所有内容只是在一行中拼凑在一起)来最小化这个代码?

默认情况下,Webpack会保留重要的注释,除非您想将自己挂钩到Webpack内部以避免默认情况下这样做,否则您可以使用其中一种不会保留它们的工具,除非另有说明.

最常用的是UglifyJS.称为uglify-jsnpm模块或uglify-esES2015 +代码,它默认剥离所有注释.

npx甚至可以在没有安装它的情况下尝试它:

npx uglify-es webpack/exported/lit-html.js
Run Code Online (Sandbox Code Playgroud)

并且看到输出已经没有显示任何评论.

自动执行此操作的方法是将UglifyJS安装为devDependency,并直接或通过-o指令修改webpack文件,作为package.json脚本的输入.

备择方案

将UglifyJS集成到Webpack和Rollup中非常容易,但是既然你已经了解了Webpack,我建议你看看这个存储库,它的目的只是展示如何捆绑lit-html或hyperHTML.

您可以在本地克隆,安装和测试它,以查看最佳结果,如果您已经针对具有ES2015功能的浏览器,它最终会降低babel转换(它会产生较小的结果).

您可以验证曾经缩小和压缩的实时内容,包括" Hello World "代码,Webpack中的lit-html权重3.5Kb,以及汇总时的4.2Kb,但在使用整个预设env进行转换后,您还可以调整为精细 - 调整你的包.

总结一下

即使我是与lit-html竞争的主要图书馆的作者,阅读有关10Kb以下的图书馆的抱怨也会极度失去动力,这会改变我们开发网络的方式.

每个其他主流框架都比lit或者hyperHTML重5到20倍,并且Web比大约5K实用程序有更大的问题所以请下次你看到一个感兴趣的库的许可证,并且大小与所有那些无关紧要如今就是网络,不要轻易向图书馆作者或简单尊重图书馆版权和许可证的捆绑商开枪.

谢谢.

  • 那么您应该抱怨您正在使用的工具无法将相同的许可证组合在一个地方。然而,正如我已经说过的,当压缩到位时,重复的文本意味着几乎 0 开销,因此 7 倍的许可证几乎就像只有一次一样,这就是每个人都必须提供压缩文本文件的原因。您将 13K 作为度量标准是错误的,因为 Webpack 没有告诉您该输出的压缩版本,实际上是 3.4K。 (2认同)