为什么 open-wc 脚手架会推广 lit-html答案

【问题标题】：why does open-wc scaffold promotes lit-html为什么 open-wc 脚手架会推广 lit-html
【发布时间】：2019-11-21 11:36:45
【问题描述】：

我在一家拥有大量 web 组件目录的大公司使用 Polymer 1 和 2 工作了大约一年，我相信 webcomponents 会非常有用。我知道像https://adamsilver.io/articles/the-problem-with-web-components/ 这样的“缺点想法”。

现在我正在深入研究如何有效地使用 vanilla webcomponents。我刚开始的前提是使用 vanilla web-components 将有助于与 webcomponents 的改进保持一致（我不能为这样的想法辩护——我现在只是假设）。然后我正在尝试创建一个堆栈来使用 vanilla webcomponents。

搜索推荐的测试方法我到达了https://open-wc.org/testing，我认为它的目的是在不添加特定框架的情况下推广良好实践（来自其网站：“开放 Web 组件是一项社区努力，独立于任何框架或公司”）。这正是我正在寻找的：一种好的实践和众所周知的推荐，类似于我们从 microservice.io 获得的微服务（这只是一个类比）。

尝试一下我在 package.json 中得到的脚手架：

  "dependencies": {
    "lit-html": "^1.0.0",
    "lit-element": "^2.0.1"
  }

所以，我的主要问题是：为什么 lit-html 用于 web 组件？

关于我的主要问题的有用疑问，据我所知，lit-html 是由谷歌和聚合物团队赞助的框架。这不是以某种方式迫使我使用 polifylls 在所有浏览器中运行吗？假设我不关心浏览器不符合 web 组件，我为什么需要一个框架？

【问题讨论】：

他们不推广它，他们只是使用它。如果你想开发 vanilla web 组件，则不需要 LIT。
回答您的问题。不，它不是*强迫_您使用框架并且不需要框架。唉，Open-WC 正处于 Lit 的潮流中……the very first line in the first example starts with loading Lit 是的，我同意你的观点，默认使用 Lit 可能会让人们认为 Lit == WebComponents。我说让他们玩得开心vanilla 和更多vanilla
看来我的问题已经回答了，但我无法将其设置为已回答，因为两者都回答为 cmets

标签： polymer web-component lit-html native-web-component html-templates

【解决方案1】：

open-wc 的维护者在这里 :)

我们推荐 lit-html/element 的原因是因为它们是非常小的库，可以帮助您编写 Web 组件，并且不会将您锁定在框架中。最后，LitElement 只是简单地扩展了 HTMLElement，这使得它可以与其他 Web 组件甚至框架互操作。 LitElement 还减少了您必须为 vanilla Web 组件编写的样板。然而，我们并没有与之结婚，我个人非常喜欢香草组件解决方案。此外，我们的大多数（如果不是全部）工具应该与 Web 组件兼容。

关于 polyfills； LitElement 将尝试使用可能的现代标准（例如：可构造样式表），并在不可用时使用回退。加载 web 组件 polyfills 取决于开发人员 - 而不是 litelement。如果您将我们的构建配置用于 rollup 或 webpack，您可以选择加载 polyfill。

希望能回答您的问题，请随时与我们联系！

【讨论】：

您当然回答了我的问题。目前，我正在尝试使用 open-wc 来测试不是由 open-wc 工具搭建的普通 web 组件。也许您可以在stackoverflow.com/questions/57066106/… 中回答我的问题
“LitElement 还减少了您必须为普通 Web 组件编写的样板。” 这就是为什么我敦促初学者不要从 Lit 开始.您确实没有学习自定义元素的工作原理，而是学习如何使用开瓶器和用一罐番茄丁做饭。
@Danny'365CSI'Engelman 是的，让我们开始使用汇编进行 Web 开发。当您可以编写机器代码时，为什么所有这些 Javascript 都乱七八糟？
Point is native JS 将永远被支持。 Lit, Hybrids, HyperHTML, 不管是什么糖解决方案.. 还没有明确的赢家。我见过一些公司因为 10 多年前选择 Mootools 而不是 jQuery 而破产。所以我的建议是先学习技术，然后寻找可以加快开发速度的工具，而不是相反。