这篇帖子有意挑战，两极分化，发人深省。它涵盖了许多您很可能不知道的新鲜内容和想法。1.简介我将尽我所能创建一个连贯的逻辑论证链，您可以遵循这些论证来理解前端开发应该如何工作。我还将尽量使这篇博文尽可能简单，以便“非开发人员”能够大体理解。2.电脑或智能手机有多少个内核？你们都见过这样的CPU图片。例如，如果您使用的是Mac，您可以点击左上角的Apple图标，然后点击“关于本机”，它会显示类似这样的内容。处理器3.2GHz8核IntelXeonW处理器iPhone有6个核。每台计算机或智能手机都有多个可用内核。这意味着您可以并行运行多个线程。你会开一辆只有一个发动机气缸的汽车吗？如果你的回答是：“当然不是！”。它会很慢！”，那么你应该仔细阅读这篇文章。3.浏览器使用多少个内核？浏览器本身每个选项卡/窗口只使用一个内核。意思是：你的Angular或React应用程序看起来像这样。你的应用程序中运行的JavaScript任务越多，它就会越慢。最坏的情况是UI完全冻结并且你的一个核心处于100%状态，而所有其他核心完全空闲。这根本不可扩展。[题外话]如果您正在创建简单、小型且相当静态的网站或应用程序，此设置就足够了。4.WebWorkerAPIWebWorkersAPI-WebAPIs|MDNWebWorkers使运行脚本成为可能后台线程中的操作与执行的主线程分开...developer.mozilla.orgWebWorkers使在Web应用程序的主执行线程中运行脚本操作成为可能在后台线程中运行脚本操作是可能的。这样做的好处是费力的过程sing可以在单独的线程中执行，这样主线程（通常是UI）就不会被阻塞/变慢。WebWorkers-Wikipediaen.wikipedia.orgW3C和WHATWG将WebWorkers设想为长时间运行的脚本，不会被响应点击或其他用户交互的脚本中断。让这些工作人员不被用户活动打断应该允许网页在后台运行长时间任务时保持响应。Worker最简单的用途是在不中断用户界面的情况下执行计算密集型任务。因此，使用worker，我们实际上可以并行使用多个内核，结束这种可扩展性噩梦。让下面这段话真正沉淀下来。Worker最简单的用途是在不中断用户界面的情况下执行计算密集型任务。这导致了一个问题。“最昂贵的任务是什么？”答案很简单：UI框架或库本身，以及我们使用它构建的应用程序。这导致了一个想法。让我们将所有内容移出主线程，以便该线程可以完全专注于它应该做的事情：操纵DOM。如果您的应用程序不再在主系统中运行，那么没有什么可以减慢或阻塞您的UI或造成内存泄漏。这种想法导致了以下概念。5.应用工作者是主要参与者范式。为了解决这个性能瓶颈，我们希望主线程尽可能保持空闲状态，以便它们可以完全专注于渲染/动态操作DOM。现在可能发生的最坏情况是，当该核心以100%运行时，您的应用程序工作人员将变慢。但是，这不会影响您的UI（渲染线程→主线程）。单页应用程序(SPA)的最佳解决方案可能如下所示。为了防止applicationworker处理太多逻辑，我们可以选择使用虚拟DOMworker，在其中计算状态转换之间的延迟更新。对于具有相当空闲的applicationworker的应用程序，您可以选择直接在applicationworker中运行虚拟DOM引擎。我们也可以使用数据工作者。如果我们有一个远程数据存储并且想在本地对数据进行排序/分组/过滤，这些计算可以在那里完成。这篇博文描述了如何在保持相同API的同时使Workers的使用成为可选的。JavaScript开发。做一个可选的WebWorker。如果您在主线程或WebWorker中运行大量与JavaScript相关的逻辑，这就很有意义。6、Worker可以访问DOM吗？在WorkerGlobalScope中，window和window.document是未定义的。意思是：你根本无法直接访问真实的DOM。所以我们在这里基本上有两个选择。选项1是在Worker中重新创建整个DOMAPI。在我看来，这是个坏主意。工人不理解DOM是有原因的，而且有大量逻辑经常变化。DOMOP变得不同步，如果您按顺序触发大量它们，可能会导致大量WorkerpostMessages。唯一的好处是你可以像以前一样继续写你的应用程序，这是值得怀疑的。稍后我会告诉你如何做得更好。事实上，有一个项目可以做到这一点。GitHub-ampproject/worker-dom：您知道的相同DOMAPI和框架，但在WebWorker中。更明智的做法是选择2：坚持Worker不应该知道真实DOM的概念。这使得使用虚拟DOM成为绝对必须的。在社交媒体上阅读时，我看到诸如“vdom很糟糕！”之类的帖子。经常。这是不正确的。很大程度上取决于它是如何实现的。Angular和React的主要障碍是基于xml或JSX的模板。这些家伙需要转换成我们可以使用的数据结构。JavaScript既不快也不设计用于解析字符串。解析模板很昂贵，甚至服务器端渲染(SSR)也重新流行起来。20年前我去过那里并创建了一个基于PHP的CMS，它可以生成html输出文件。你可能会争辩说，今天的云可以处理更多的客户端连接，但富/胖/胖客户端的概念仍然非常有意义。7.Worker是否可以访问DOM？其实有一个。OffscreenCanvas-WebAPI|MDN的OffscreenCanvas接口提供了一个可以离屏渲染的画布。它适用于窗口和屏幕外。工人可以获得CanvasDOM节点的所有权。这在Chromium中已经运行良好，Safari(Webkit)和Firefox正在积极实现它。这可能还有6个月的时间，所以这是2022年的主题。8.如何以智能方式创建虚拟DOM？虽然JavaScript不擅长解析字符串，但它擅长处理嵌套的对象/数组结构。这种格式的名称您肯定很熟悉。JSON。如果我们坚持使用基于JSON的vdom语法，则无需在您的UI中重复进行昂贵的模板解析，甚至无需将这部分移至构建步骤。这当然有点类似于直接使用JSX输出。做得好，虚拟DOM中没有变量、if/else语句、绑定、方法、循环或任何类型的逻辑。您永远不会看到包含1000多行代码的模板（看看Angular）。通过编程方法，您将在属于它的地方使用逻辑：在JavaScript中。例如，当创建一个列表时，你可以先创建一个框架Vdom，一旦数据存储被加载就遍历记录，并动态创建新的虚拟DOM节点。这个概念允许我们在运行时从根本上改变组件的Vdom。是的，更改组件的vdom在安装前后的工作方式完全相同。实现无限滚动或其他高级功能变得容易。您可以在此处找到更多输入。使用基于JSON的虚拟DOM的好处。基于JSON的虚拟DOM的新格式化概念。虽然编程方法对低级vdomOP有意义，但我们绝对更喜欢声明式方法来创建我们的应用程序。为了实现这两点，我们唯一需要做的就是在vdom之上添加一个声明式抽象层：组件树。意思是：你只在创建组件类时使用vdom。要创建应用程序，您可以坚持使用组件树。9、UI开发可以直接在浏览器中完成吗？当React在5-8年前流行时，浏览器在支持最新的ECMAScript特性方面表现糟糕。例如，不支持类(ES6)或JS模块。在这一点上，将UI开发转移到节点中是非常有意义的。意思是：你可以使用最新的语言特性，并以一个构建步骤为代价，将你的代码编译/翻译成浏览器可以理解的Javascript。浏览器供应商正在迎头赶上。今天有许多闪亮的新功能开箱即用，大多数第3阶段的建议确实可以立即实施。JS模块在Worker范围内的Chromium中运行良好。Webkit(Safari)也完成了，但它仍然仅限于SafariTechnologyPreview。Mozilla(Firefox)正在积极推广它。我们可以放心地假设全面支持将在2022年准备就绪。构建步骤非常昂贵，对于UI库或框架开发模式应该不再是必需的。它的优势是显而易见的。JavaScript旨在成为浏览器引擎理解的唯一编程语言。以浏览器无法理解的方式编写JS只是感觉不对。通过将UI开发带回浏览器，我们可以调试我们的真实代码，而无需任何类型的构建/翻译或使用源映射。我们不需要热模块更换。尤其是创建和调试代码将再次成为一种乐趣，因为我们可以确保没有外部因素导致的错误。绝对仍然需要像webpack这样的工具来创建语言环境/生产输出。但是，它们将是构建工具，而不是运行时环境。从node到deno的过渡将进一步促进这一点。CommonJS迟早会消亡。一旦deno有了包管理器，越来越多的包将使用可在浏览器中运行的语法（例如，没有裸模块说明符→导入无效路径和文件扩展名）。10.TypeScript有未来吗？这可能是本文中最具争议的部分。JS社区分为两部分：一些人喜欢使用TS，而另一些人则拒绝接触它。期待您的讨论。我的想法。现在，在节点中开发UI时，有一个必要的构建/翻译步骤，使用TS就可以了。一旦UI开发回到浏览器中，这将彻底改变。您会为使用TS设置完整的构建步骤吗？在这一点上，它变得太昂贵了。问题是。TS不是网络标准。目前没有计划在浏览器中实现它。历史已经多次告诉我们，不基于网络标准的网络技术会发生什么：它们会在某个时候消失。MSSilverlight就是一个很好的例子。一般来说，类型检查是一件好事。主要问题是Angular和React不使用基于JSDoc的注释，这允许IDE在编写代码时警告您。事实上，甚至可以使用基于JSDoc的注释来“伪造”TS。如何在JSDoc注释中编写TypeScript接口这绝对是我们可以讨论的选项。如果你真的想直接用你的编程语言进行类型检查，而不关心构建步骤，那么Dart2不是更合适吗？Dart2完全支持Workers，因此我们也可以在那里运行Worker设置。移动端的优势包括AOT编译。11.React有什么问题？公平地说：在React之前，有JQuery。这在React流行时是一个很大的改进，React是第一个让虚拟DOM流行起来的库。那么，为什么我们不应该在2022年使用React？React在主线程中运行。React的代码库是基于CommonJS→没有构建步骤，它不会在浏览器中运行。JSDoc没有评论。JSX模板的解析成本很高。甚至有像Svelte这样的编译器将其移至服务器端。React不暴露核心。一切都扩展了Component，这根本没有意义。状态管理无缘无故太难了。render()方法无疑是有问题的。让我更深入地解释一下：防止状态更改触发渲染肯定很复杂。如果React组件包含子组件（render()中的自定义标签），如果您不小心使用键，将会创建新实例。重新创建Component实例使函数式编程流行起来，因为创建类实例的次数超过了必要的次数，并且您自己的Component实现中的内存泄漏可能会造成伤害。如果你有很多状态道具，例如影响项目的位置，你将需要在你的JSX中添加相当多的逻辑。React只是一个库，而不是一个框架。这意味着。组件几乎就是它的全部。没有逻辑层次链，例如。core.Base->component.Base->button.Base->tab.header.Button一旦你摆脱了render()的疯狂，你就可以为你想要创建的东西选择最合适的基类。例如，一个容器有一个vdom对象，该对象包含对其子容器的vdom对象的引用。然后我们可以更改子组件的vdom而无需重新创建它们的基于JS的实例。此时状态管理变得微不足道，我们甚至不需要钩子。特别是在保证最多调用一次vdom引擎的情况下，并行更改多个配置是关键。12.多窗口应用程序可以选择性地通过将Worker设置替换为SharedWorkers来增强此概念。这允许我们在不同的浏览器窗口中移动整个组件树，同时保持其JS实例的位置。多窗口状态管理，无需后台。可以跨窗口拖放。13.我们需要自己实现worker设置吗？我自己实施所有提到的想法实际上需要数年时间。幸运的是，我已经为你完成了。生态系统中有超过12,000个提交，由麻省理工学院完全授权。GitHub-neomjs/neo:Appworker驱动的前端框架。这包括一个远程方法访问API，使您能够通过承诺（消息传递之上的抽象层）直接调用不同工作者或主人的方法。大量组件已经到位，连同控制器、视图模型、应用程序和其他实用程序类。您不需要任何第三方库来支持架构设计模式，如MVVM、Observable和许多其他模式。特别是状态管理非常容易（提示：类配置系统）。CLI是高级的：您可以使用一行创建一个新的应用程序（工作区）：npxneo-app。我们甚至可以跨应用程序拆分块，因此将多个应用程序放在一个页面上时几乎没有开销。14.最后的想法你不必等到2022年，你现在就可以使用这些想法将你的前端开发提升到一个新的水平。一些公司和开发人员已经在这样做，并且正在利用他们的领先优势将新技术转化为业务优势。neo.mjs被提名为“最激动人心的技术应用”。大多数开发人员仍然不知道neo.mjs项目的存在，这令人沮丧。我很乐意看到有人证明我在这些概念上是错误的。为此，您需要创建第一个基于neo的PoC应用程序。在这种情况下，我想查看您的代码。对于运行时的动态DOM操作，neo是最快的选择。特别是当涉及到大型和复杂的应用程序时。15.我如何开始？我刚刚创建了一个教程，介绍如何使用这项技术实际构建应用程序。将web4.0应用程序定义为多线程应用程序。
