为什么我们服务器端渲染Web组件
#javascript #网络开发人员 #ssr

回到1月25日，我在thejam.dev举行的一个在线活动中，展示了有关Jamstack，Web开发和由我们的朋友在Certified Fresh Events托管的无服务器的演讲。接下来是我们选择平台而不是追逐JavaScript框架的理由。视频后立即关注成绩单。

视频

成绩单

我今天在这里与您讨论服务器端渲染Web组件，我们将要参与其中。不幸的是，我们必须首先执行一些背景信息才能到达那里，但是我们会建立它。

我要问一个非常愚蠢的问题来开始我的演讲：您是否曾经有过依从性？

if you could not as stupid questions

好吧，这是一个愚蠢的问题。我的意思是，依赖性不稳定，可能是时间下沉。这项计划外的工作使您无法迭代产品，这令人沮丧。

杰夫·贝佐斯（Jeff Bezos）有很棒的报价。

我经常得到一个问题：“未来10年将会发生什么变化？'
我几乎从来没有得到一个问题：“未来10年不会改变什么？'
我向您提出，第二个问题实际上是两者中更重要的 - 因为您可以围绕及时稳定的事物建立业务策略。

jeff bezos

人们总是问他在未来十年中会发生什么变化，以及我们将如何为此做准备。尽管如此，他们很少问十年来不会发生什么变化，这将是稳定的。他认为第二个问题更为重要，因为您可以为可以创建企业的稳定物品制定策略。我认为，预测未来几年会发生变化的事物更容易，这就是您可以用作建立业务的坚实基础。

为什么我们要在不改变的事情之上建立业务？

软件很复杂，并且通过为您的软件添加很多依赖项而肯定不会变得不那么复杂。可以说，这使情况变得更糟，因为这些依赖性经常彼此冲突，这可能是巨大的痛苦。

现在我们以前已经看过这种鞭打了。 Web浏览器曾经非常损坏。浏览器生态系统过去一直在改变。不同的浏览器以不同的方式解释功能并不少见，因此它们会破坏不同的网站。

Web浏览器不再破裂了。当涉及到它时，只要实现标准，我们现在就已经发展为现在已经发展为一系列不同浏览器的Web标准。在大多数情况下，它们是这种情况，并且浏览器会自动更新自己为常绿。您永远不必担心它们非常过时。要在浏览器市场中保持竞争力，他们必须保持这种向后兼容性，因此您知道这些事情将永远有效。

Web浏览器向后兼容。我们的倒数兼容性我们的意思是，如果您查看25年前编写的网站和代码，您会发现它们在当今的现代浏览器中仍然可以很好地工作。一个例子是jQuery。 JQuery在许多站点都使用了这些浏览器的差异。随着时间的流逝，随着浏览器变得越来越标准化，我们不再需要jQuery。我们能够删除该依赖性并使用平台中的内容，但是如果您在2003年写了一个网站，即使浏览器没有引入破坏更改，它仍然可以使用旧版本的jQuery。

。

我们必须问自己：如果浏览器可以如此稳定，我们自己的源代码也可以如此稳定吗？

我会认为破裂的变化是可选的。不幸的是，我们倾向于热切地选择它们。仅仅因为您知道自己选择了一个编译到Web标准的框架并不意味着您正在享受这些网络标准，因此您可能会考虑更多。

在变化方面，有两种变化，当然，我以前的问题的答案是肯定的，我们可以选择事物，以便我们的源代码不会破裂，并且非常稳定。

我们必须注意两种更改。第一个是坏人。那是一个破裂的变化。那时我们会看到删除API，接口或行为。在某些情况下，如果您因为安全问题而删除某些东西，那么摆脱它是非常有意义的。很多时候，出于破坏的变化而发生了破坏的变化。

很多时候，包装可以正确地使用SEMVER处理事物。每当引入破坏更改时，更新到专业。引入未成年人或补丁发布的破坏变化是可怕的，因为这与SEMVER的工作方式不同。

那些已经足够长的人可能还记得从Angular 1.x到2.x的巨大变化。这是您应用程序的完整重写，然后他们在后来版本的Angular中再次对我们做了。许多人被Angular烧毁了太多次，并转向其他框架。 React 18也有一些破裂的变化。它可以正确处理事情，因为它正在大型版本上打破东西。 TypeScript 4.8（次要更新）还包括破坏您想要看到的更改。您希望在主要版本上引入这些更改。如果您关注SEMVER并查看Typescript 4.8已出来，您会认为：“我只是升级它，因为它只是一个小的更改。它不应该有任何突破性的问题，”您就去了。您已经引入了破坏的变化，因此，您已经有了很多计划外的工作，因此您想明智地选择依赖项或消除它们。

适当处理这些更改并确保其正确使用SEMVER的框架是良好更改的另一种更改。加性更改只是它添加了新功能，而无需删除任何旧内容。 HTTP 1.x至2.x非常好，因为它为我们提供了新的功能，但是它使旧协议保持完整。我们曾经将XMLHTTPRequest用于ajax。首先，这是一个非常不错的API，但是我们将其完善为fetch，对于开发人员人体工程学来说，这是更好的API。我们添加了您可以使用的异步/等待的内容，或者您​​仍然可以做出承诺或回调。我们还添加了脚本标签的模块类型。我们可以告诉人们这就像一个新的ES模块，而不仅仅是使用旧的标准脚本标签。这些都是对平台加性更改的示例，而无需破坏其他任何内容，这真是太好了。

现在前端本身也非常复杂。前端是这个庞大的生态系统，存在许多兼容性问题，因此您可以使用跨代码很常见。但是，您编写的代码和运行的代码之间的那些细微差异可能会导致意外的断裂，这非常令人沮丧。

查看这些模板系统，JavaScript的早期版本没有字符串模板概念，因此我们从Java，Ruby或Ruby或Python等其他运行时间中获取了一个页面，我们创建了这些模板语言。这就像将较小的语言嵌入到您的较大语言中，有时会使语法难以阅读。因为它不是很标准，所以不是JavaScript。然后，我们还有其他东西，例如JSX等非标准方言。 JSX不是JavaScript。看起来像JavaScript。它的作用类似于JavaScript，但是您无法直接在浏览器中运行该代码。您必须在浏览器中执行jsx的翻译步骤，因此您编写的代码和在情况下运行的代码再次大不相同。

做事的另一种方法是引入一种全新的编程语言，然后使用它来汇编为网络标准。这就是Svelte背后的想法，它具有与模板语言相同的问题。就像html一样，就像javaScript，但事实并非如此。现在，您必须对Svelte表示赞赏，因为它们是一个非标准的方言，并且您知道他们坚持编译器是一个更好的解决方案的想法，因为它可以输出更有效的代码。

转卸

好吧，让我们看一下一些转侧输出。转运器的问题在于它们使运行时代码混淆。这很糟糕，当您挖进去时会变得更糟。让我们看一下此代码示例：

(self.webpackChunk_N_E = self.webpackChunk_N_E || []).push( [ [59172], {
    95627: function(t, e, r) {
        var 1 = r(15686). Buffer,
        n = r (4163);
        !function() {
            var e,
            a,
            0,
            5,
            f,
            h,
            d,
            C,
            u = {
                7160: function(t, e, r) {
                    var i = e;
                    1.bignum = r(711),
                    1.define = r(495). define,
                    i.base = r (853),
                    1. constants = r (7335),
                    i. decoders = r (6701),
                    i.encoders = r (3418)
                },
                495: function(t, e, r) {
                    var i = r(7160),
                    n = r(3782);
                    function a(t, e) {
                        this.name = t,
                        this. body = e,
                        this. decoders = 0),
                        this.encoders = {}
                    }
                    e.define = function(t, e) {
                        return new a(t, e)
                    a.prototype. _createNamed = function(t) {
                        var e;
                        try {
                            e = r(6144) .runInThisContext ("(function " + this.name + "(entity) {\n
                            this._initNamed (entity); \n})")
                        } catch (i) {
                            e = function (t) {
                            this._initNamed(t)
                        }
                        }
                        return n(e, t), e-prototype. _initNamed = function (e) {
                            t.call(this, e)
                        }, new e(this)
                    },

这可能更可读。在这种环境中的任何调试都将很难诊断。您需要弄清楚事物的来源，因为这不是您编写的代码。它与您编写的代码无关。

            e.Decipheriv = s.Decipheriv,
            e.createDecipheriv = s.createDecipheriv,
            e.getCiphers = s.getCiphers,
            e.listCiphers = s. listCiphers,
            f = P(6587),
            e. DiffieHellmanGroup = f.DiffieHellmanGroup,
            e.createDiffieHellmanGroup = f. createDiffieHellmanGroup,
            e.getDiffieHellman = f.getDiffieHellman,
            e.createDiffieHellman = f.createDiffieHellman,
            e.DiffieHellman = f.DiffieHellman,
            h = p(4078),
            e. createSign = h. createSign,
            e.Sign = h. Sign,
            e. createVerify = h.createVerify,
            e.Verify = h. Verify,
            e. createECDH = p(9942),
            d = p(9783),
            e.publicEncrypt = d.publicEncrypt,
            e.privateEncrypt = d.privateEncrypt,
            e.publicDecrypt = d.publicDecrypt,
            e.privateDecrypt = d.privateDecrypt,
            c = p(6445),
            e. randomFill = c. randomFill,
            e. randomFillSync = c. randomFillSync,
            e. createCredentials = function () {
            throw Error("sorry, createCredentials is not implemented yet\we accept pull
                requests\nhttps://github.com/crypto-browserify/crypto-browserify")
            },
            e.constants = {
                DH_CHECK_P_NOT_SAFE_PRIME: 2,
                DH_CHECK_P_NOT_PRIME: 1,
                DH_UNABLE_TO_CHECK_ GENERATOR: 4,
                DH_NOT_SUITABLE_GENERATOR: 8,
                NPN_ENABLED: 1,
                ALPN_ENABLED: 1,
                RSA_PKCS1_PADDING: 1,
                RSA_SSLV23_PADDING: 2,
                RSA_NO_PADDING: 3,
                RSA_PKCS1_0AEP_PADDING: 4,
                RSA_X931_PADDING: 5,
                RSA_PKCS1_PSS_PADDING: 6,
                POINT CONVERSION UNCOMPRESSED?"'4, POINT_CONVERSION_UNCOMPRESSED:
                POINT_CONVERSION_HYBRID: 6
            },
            t.exports = b
        }()
    }
}]);

现在，对于微不足道的捆绑包来说，12,000行代码是正常的，而且这不是很高效，这是您可以调试的可怕开发人员体验。许多人会认为源地图会解决此问题，但是通常，它们无法正常工作，尤其是当您在Node.js之类的环境中运行时，该问题不是为此类型的事物而构建的。

介绍诸如转卸步骤之类的东西时，您知道您的工具在做什么吗？您只是指望他们为您做正确的事情，所以让我给您一个例子，说明我最近在检查应用程序时遇到的东西。

(self.__LOADABLE_LOADED_CHUNKS__=self.
_LOADABLE_LOADED_CHUNKS. - I| []). push (C[9158], {9158:(-,e,r)=>
{var o=r (85081) ("toLower", r(46129),r (39478));o.placeholder=r
(48051), -. exports=o}, 46129:(-,e,r)=>{var o=r (26478);-.
exports=function(_){return o(_).toLowerCase ()}}}]);

这个单线是296个字节。一个微小的，完全独立的JavaScript文件。我能告诉它，添加了一种称为toLower的方法，该方法称为toLowerCase。

如何为您进行优化代码？为什么会更好？我不明白。它为我节省了四个字符，但是每次我需要在平台中调用某些东西时，都会添加开销。无论如何，检查您的工具在做什么，

静态！==动态

今天早些时候，亨利（Henri）讨论了诸如第一个内容的油漆和互动时间之类的指标。当我们使用巨型框架时，这些指标可能会更好。发生的事情是，我们必须将JavaScript发送到浏览器以创建用户界面，然后将API调用到后端，以使用数据填充界面。因此，这将影响您的第一个内容涂料和互动时间。

您真的想看一下 - 那真的是做事的正确方法吗？在当今现代的JavaScript环境中，我们有太多的活动部件。我们可以摆脱什么？

我们可以简化这种情况。复杂性的根本原因是什么？我们如何避免这种事情？我们可以防止这种方法的方法之一是回到以前写网页和网站的方式，我们有一个新的渐进增强案例。

渐进式增强

渐进式增强并不是新人已经做了很长时间了。在某个时候，它用尽了时尚，您知道我喜欢JavaScript。它帮助我没有买我的房子，而是在上面付了很好的首付，但是有时确实会变得有点时尚。

渐进式增强效果过时，但我们应该将其带回来并更多地考虑它，因为有很多原因。首先，包容性的道德原因。我们希望尽可能多的人使用我们的网站和应用程序，并且当您以渐进式增强构建构建时，您会从工作的HTML开始。您可以开始的最访问的应用程序。

如果您需要提出这一论点，也有业务原因。观众越大，设备和人们可以使用它。这意味着他们将花在您的产品或服务上。最后，有一个自私的开发人员的原因，因为我讨厌修复破碎的东西。

我喜欢东西时。如果我有一种方法可以适用于屏幕读取器和旧的Web浏览器，它将适用于常绿的Web浏览器。它将在出现的新设备上使用，该设备正在出现，该设备是虚拟语音助手或类似的东西，这都是因为我们正在使用渐进式增强技术。这就是我想要的，因为我将花更多的时间在产品上添加新功能，从而使我的客户感到高兴，而不是追求一堆破碎的变化。

随着渐进式增强功能，您从工作HTML开始，并使用标准锚和表格。然后，通过将JavaScript添加到它来使其更好。不是相反。不要从一堆JavaScript开始以查看失败的位置，然后确保失败案例仍然可行。那是优雅的退化！

IMHO，渐进式增强胜过优雅的退化。当我们首先谈论执行HTML时，我们不仅在谈论HTML。 JavaScript在您的应用程序中排名第二，因为这是Web浏览器的工作方式。使用您的检查员打开任何站点，然后转到网络选项卡。加载的第一件事是您的HTML，然后您的HTML用于构建页面。 HTML和CSS加载后，然后加载JavaScript。这就是使您的页面更好的原因。它给它提供了更多的互动性，但应该是撒上JavaScript的洒水，而不是JavaScript的海啸。

下一代

首先有许多下一代前端框架。例如，11ty，Remix和Astro。所有这些框架都首先考虑进行HTML。 HTML首先是说渐进式增强的新营销方式。正如我之前提到的，渐进式增强的声誉不佳，并且过时了。您可以查看这些框架中的任何一个，看看他们的工作方式。

开始时，我们自2017年以来就已经进行了这个开源项目。成千上万的应用程序建于Architect，这始终是HTML。我们使用云函数开发应用程序，直接从服务器输出HTML，因此服务器下降的所有内容都可以正常工作HTML，然后我们在客户端上使用JavaScript增强了HTML。我们已经这样做了五到六年。我们在那段时间里学到的东西推断了我们以后将使用增强框架做的事情。

如果整个后端只是纯云功能怎么办？建筑师开源项目主要与后端有关。与其加载一大堆网络服务器，不如让我们制作所有可以使用Architect进行管理的后端诸如小型云功能之类的东西，到目前为止，它的工作非常出色。

使用现代JS生态系统，我们遇到了一些主要问题。首先，这很脆弱；这些生态系统彼此不兼容，并且常常失败。我们还拥有这些非标准的模板库，或者更糟糕的是，我们必须添加不透明的编程语言，以增加为构建Web应用程序的更复杂性。它们经常是静态的，而不是动态的。您不会从一开始就得到用户想要的内容，并且会导致所有这些类型的旋转器，骨架屏幕和不良指标在您的第一次互动时。

我们的前端源可以是纯标准的HTML，CSS和JavaScript吗？如果我们从Web标准开始，而不是学习JSX等非标准编程语言并将其编译成JavaScript怎么办？让我们从一些非常基本的原语开始，使事情逐步工作。让我们选择HTML和CSS。我们将从一开始就开始使用这些乐高积木，然后将它们堆叠起来，以建造更大更好的东西。一旦所有工作都可以，我们就可以添加客户端的JavaScript，以实现更多增强的浏览器行为。

换句话说，我想说的是

use the platform

使用平台

回到当天，我们曾经使用jQuery来做所有事情，但是现在我们很少需要达到它，因为jQuery最重要的部分已成为平台的一部分。它使在jQuery中进行查询选择器变得更加容易。尽管如此，现在我们将querySelectorAll内置在平台中，正是由于jQuery的受欢迎程度，我们拥有这些API。

我们使用的一些现代JavaScript框架是同一件事，我们用来构建可重复使用的组件用户界面。我们已经普及了很多，但是平台中是否可以使用一些可以减少对某些框架的依赖性的东西？当然，有。

Web组件

Web组件是一套不同的技术，可让您创建可重复使用的自定义元素并在Web应用程序中使用它们。这些自定义元素全部都远离代码的其余部分。样式和行为可以包含在单个文件中，以便您可以在不同的项目中重复使用它们，并且不会影响应用程序的其他部分。构建Web组件时，使用三个主要规格。

  • 自定义元素：一组JavaScript API，允许您定义自定义元素及其行为，然后可以按照您的用户界面中的要求使用。
  • 阴影dom：一组JavaScript API，用于将封装的“阴影” DOM树连接到与主文档DOM分开渲染并控制相关功能的元素。通过这种方式，您可以将元素的功能保留为私有，因此可以对其进行脚本和样式，而不必担心与文档的其他部分相撞。
  • html模板：<template>和<slot>元素使您能够编写渲染页面中未显示的标记模板。然后可以多次重复使用它们作为自定义元素结构的基础。

React即将在2023年中期拥有10岁生日。 Web组件已经过了10岁生日，因为它自2012年以来就已经出现了。差异是它是一个不断发展的标准。多年以来，我都不会说已经准备好了黄金时段，但是我们已经达到了一个在所有常绿浏览器中都可以使用的网络组件，并且没有理由现在不使用它们，因此，如果您可以使用Web组件并摆脱您现在用来构建UIS的一些大型JavaScript框架，您可能应该看一下这样的事情。

Web组件有问题。所有解决方案都有问题。您会注意到Web组件的几件事是，它们的渐进性增强不太好。不幸的是，当您设置Web组件时，您会使用JavaScript定义它。您必须调用customElements.define方法，以便在浏览器中注册组件。如果JavaScript出于任何原因而失败，并且相信我，那么JavaScript可能会失败的许多原因，这并不是因为有人只是决定关闭它，因为他们喜欢看世界燃烧。有网络问题，DNS问题和圈养门户，仅举几例。 JavaScript可能会遇到问题有很多充分的理由。这是Web组件的问题，因为如果您没有JavaScript，您将无法实例化该Web组件，并且浏览器不知道该如何处理您提供的自定义标签。

另一个问题是浏览器的工作方式。首先，您加载HTML，然后加载CSS，最后是JavaScript。如果您的标签是您的自定义元素，直到JavaScript加载，解析和执行，它将不知道如何显示该自定义元素。取而代之的是，您会得到一个白盒子，它将闪烁到应该的外观。这就是所谓的未风格的自定义元素（fouce）的闪光灯。这些是处理Web组件时必须要注意的几件事。有常见的问题，但是我只有为它们提供解决方案时才提出这些问题。

Enhance

增强是HTML框架。这是我们在开始时进行的另一个开源项目。它允许您使用Web组件（例如Web组件）在HTML中在HTML中撰写页面，以构建UIS，然后逐步增强使用某些客户端JavaScript的HTML，以使所有内容变得更好。

增强的有趣之处在于，您将Web组件写入纯云功能。使用Enhance，您的自定义元素在服务器上扩展。我们确定Web组件的哪些部分要向下发送电线，以便当最初的HTML加载到浏览器中时，我们不需要等待customElements.define，因为它内部的所有HTML都已经扩展。如果JavaScript失败，您无法致电customElements.define，这将消除问题。它还消除了未风格的自定义元素的闪光灯，因为您的初始HTML已经存在。它还使您可以在服务器上执行某种个性化，在该服务器中您立即将所有数据发送下来，这也将有助于您的指标。您首先进行互动的时间会更快地，因为数据已经存在于HTML中，因此第一个内容的涂料也将会更好。我们不是在等待JavaScript加载，也不在等待该页面加载后要进行的API调用 - 我们已经为您提供了该数据。

演示

增强关键概念

  • 基于文件的html基于文件的路由
  • 用自定义元素重复使用标记
  • 基于量表而不是绝对值的内置实用程序CSS
  • 无手动接线道具的API路线
  • 用标准JS逐步增强；没有特殊的语法
  • hood下的完整堆栈FWA

frontend backend

使用Enhance.dev，我们在将前端和后端融合在一起方面做得很好。

假设您将在客户端JavaScript中进行一些操作。您最终将添加一个脚本标签到发送给客户端的内容，这是您将Web组件在客户端端实例化的地方，注册您的活动侦听器并执行所有其他标准JavaScript。

在引擎盖下，我们正在使用建筑师部署。我们正在使用AWS为数据库运行您的云功能和发电机DB。这是一个功能齐全的Web应用程序，具有基础架构作为代码来管理您的所有内容。

进一步的资源

如果您想要有关此的更多信息，最好的办法就是在Enhance.dev上查看Enhance文档。加入我们的不和谐问我们问题，因为我们很高兴收到您的来信，当然，在Mastodon上关注我们。

问答

肖恩·戴维斯（Sean Davis）谢谢，西蒙（Simon），我喜欢那个演讲。我有很多问题，所以我要跳进去。
您在thejam.dev上知道，我们经常谈论jamstack和不同的趋势。我知道人们仍在某种程度上坚持使用更传统的静态站点生成器，但是我们看到了更多服务器端渲染内容。因此，我想很多人都在观看您的演讲和思考，这是像独家SSR一样，还是您可以选择使用Enhance预渲染内容？是在作品中还是仅专注于服务器？

西蒙·麦克唐纳（Simon MacDonald）我们专注于服务器端渲染片。我忽略的一件事是，有一个公共桶将其映射到S3桶。如果您想在Enhance之外运行一个过程，该过程将带有静态站点生成的内容填充该存储桶，则可以做到这一点。我见过的传统事情之一是人们使用jamstack进行渲染一堆Markdown文件，将其转换为HTML并将其存储在您的存储桶中。

我们取得了很大的成功，可以自动生成该HTML。根本不需要很长时间。增强。DEV本身使用该方法。这是一个开源项目。您可以看到我们是如何做到的。我们之前也写了一篇文章。以这种方式渲染的事情没有对此进行惩罚，如果您必须根据已记录的用户插入任何类型的动态内容或个性化，则可以在服务器上查询该问题。侧面并以初始页面负载将其发送到电线，而不必等待事实之后进行另一个API调用，这是此步骤适合Jamstack的新定义，因为没有做到这一点的一种正确方法。

肖恩·戴维斯（Sean Davis）我想您可以与Begin结合使用它，但是许多其他云提供商呢？您可以在任何地方部署增强应用程序吗？

Simon MacDonald 现在，增强应用程序可以部署到AWS。我们将为您提供最佳的经验，开始部署到我们的基础架构，但是如果您不想使用开始，则可以使用Architect直接部署到AWS。当然，如果您真的觉得自己想自己管理它，则可以从建筑师那里弹出并直接部署到AWS。在这种情况下，您必须管理云形成，我不建议这样做。在这种情况下，您绝对想使用工具将基础架构作为代码进行。一个10线架构师清单文件，可能是五个API调用，静态存储桶最终是1400行的云形式。您不想写那个。太可怕了。

肖恩·戴维斯（Sean Davis）使用抽象层完全可以的情况吗？

Simon MacDonald 完全！

肖恩·戴维斯（Sean Davis）我还注意到项目中有少数MJS文件，我知道这很像是非常两极分化的主题。我对您的意见很好奇，并提高了对打字稿的看法。这是您对本机支持的东西，还是您觉得那是反对使用本机库等回到基础知识的想法。？

？

Simon MacDonald 就个人而言，我不喜欢打字稿。您可以将Typescript与增强和开始使用，但是您可以在项目中添加转卸步骤。您编写的打字稿代码不是在浏览器上执行的JavaScript代码，我们试图避免这种情况。它使您的代码更难调试。我知道人们喜欢很多打字稿的功能，我对TC39的一项建议非常兴奋，即在JavaScript中添加类型注释。在开发时启用静态类型检查，同时不在运行时添加任何开销。

肖恩·戴维斯（Sean Davis） henri提到他介绍了CBS体育网站，并表示他们目前正在运行JQuery版本1.8.3，该版本于2012年11月推出。我喜欢您的开始谈论您在杰夫·贝佐斯（Jeff Bezos）的名言中谈到未来十年中会发生什么变化，并重新关注稳定的事情。因此，从一般的角度来看，我只是好奇，如果jQuery仍然有效，您是否认为使用旧图书馆是不好的做法？还可以使用吗？我们如何在所有新闪亮的东西上露面？

之间取得平衡

西蒙·麦克唐纳（Simon MacDonald）我在使用jQuery上没有任何问题。在这种特殊情况下，我的建议是停止使用它，因为jQuery中的许多事情都在平台中出现。您可以直接使用平台减少发送给客户端的JavaScript量。这是我与许多其他UI框架的论点之一。当我们在浏览器中没有一个良好的组件模型时，它们就在附近，但是现在我们应该开始删除他们的一些复杂性，以支持Web组件。但是我们现在没有看到那个，所以我们会看到发生了什么。

好处是，如果您十年前创办了一家企业，建立WordPress并使用JQuery，那么您现在仍在赚很多钱。它可能不是性感的。这可能不是技术上最困难的事情，但是您仍在为此谋生，因为平台没有打破您

如果您在五年前或七年前开始使用React，那么您将从createElement到JSX，再到今年的新事物。这种搅动每18个月左右发生一次，当反应本身会重新发明，您会不停地追逐这些变化。您必须问自己，我是否浪费了很多时间，可以为客户使用建筑功能并赚钱？而不是只是在追逐这些计划外的中断？我尽量不要像我多年来使用过的那样对反应太多，但是我想我已经看到了光。

肖恩·戴维斯（Sean Davis）完全公平。现在，人们对此有不同的看法，但是您提到网络组件已经十岁了，我觉得头几年有很多噪音，然后掉了一段时间。 React变得非常受欢迎，但仍然如此，但是在过去的六到12个月内，我在这个空间中的Web组件周围看到了更多的噪音。我知道您要押注它。我对您的观点感到好奇。您看到同样的趋势吗？我想我想问的是，您是否看到这种方法引起人们的共鸣？您是否觉得我们也会开始看到其他一些框架弹出？这是我们看到回到基础知识的趋势吗？

Simon MacDonald 我相信。我们看到的东西不仅是增强的，而且还使用WebC的11th，还使用Web Consents。像Google这样的主要公司已使用Web组件构建了YouTube。 Adobe使用Web组件制作其所有创意云网络应用程序。 Web组件现在可以使用黄金时间。当它最初宣布它的规格仍在不断发展时，还没有准备好。当涉及到规格的演变时，这些东西需要一段时间才能巩固并正确完成所有用例。这就是客户端库非常有帮助的地方，因为它们可以很快迭代。 jQuery是一个例子，它迅速迭代，最终，这些东西最终进入了平台。在移动方面，Adobe PhoneGap/Apache Cordova使用地理位置和其他最终进入平台的移动API实施了一堆API，以连接到相机。为什么一些事情反应，vue和Angular会被该平台已经可用的东西取代？那就是网络组件！我认为您会看到许多人开始朝这个方向发展。

肖恩·戴维斯（Sean Davis）很有意义。我会密切关注它，因为我喜欢使用本地图书馆回到基础知识的概念，而且我对您的Enhance的发展感到兴奋。