Companion demo: Repository | Live app

当我第一次涉足AMP时, 我以为一切都是为了速度和小小的灰色闪电. 我觉得这些目标完全值得实现, 但我团队的其他成员持怀疑态度:AMP不是有限制吗? 它不会阻止JavaScript吗? 你会做CSS吗? 我们的广告呢?? Our branding? 如何使CMS产生amp友好的输出?

我不知道所有这些问题的答案. But the AMP demo 看起来比我们大多数网站都好, 所以我乐观地认为，我们可以在适当的时候跨过这些桥梁. 考虑到通过serp访问我们文章的移动用户的快速页面加载的回报, 我觉得它至少值得拥有一个原型.

事实证明我是对的. The AMP version of our blogs looks similar to the non-AMP version; probably a bit better. 允许使用JavaScript. So is CSS. 广告、表单、分析、性能监控也是如此——我们的AMP版本什么都不需要.

在我的下一个项目中，我产生了一个想法. If nobody minded, 我只是尽快建立整个网站作为一个单一的AMP版本, 而不是“正常”的前端, 与AMP版本配对. 最近AMP团队发布了 一个相当搞笑的视频 这证实了我的怀疑:AMP可以，也许应该，为你的整个前端供电.

我还不能说我有机会在游戏发行的整个过程中执行这种方法, but I intend to, 我将带着同样的信心去做，就像我对待任何其他项目一样. 请允许我反驳一些常见的反对意见.

Design

大多数人都知道AMP可以呈现HTML和CSS的迷人组合, 但是对于某些CSS属性和值不受支持的担忧仍然存在. 我发现事实并非如此. 响应式网页设计 完全支持, 网页字体也是如此, icon fonts, SVG, 整页的背景图片—可能是您习惯使用的任何图片.

CSS

我遇到的第一个障碍是当我试图将我的普通前端CSS加载到AMP中时:CSS有85 kB的限制，而且多年来一直如此, 我们的样式表已经增长到大约270 kB. At first, 我发现这真的很令人沮丧, 但它让我认真考虑实用优先的CSS的优点. Bootstrap和Tailwind就是很好的例子，在这两个例子中，你给一个元素一个类 m-5 (或类似的)而不是写 .thing { margin: 2em; } 在样式表中. 这种方法使我能够仅在42 kB中实现设计奇偶性, 我现在相信这是更好的工作方式, regardless.

JavaScript

AMP确实对可以运行的JavaScript类型设置了一些限制, 以及可以加载它的源文件. 对此，我很感激，因为JavaScript依赖项往往是我的项目中最脆弱的部分. 实际上，你可以在AMP中使用JS做比我预期的更多的事情. AMP为显示/隐藏等常见UI元素提供了有用的模块, AJAX表单提交, validation, 即时内容更新, and more.

还有一个amp-script, 它允许你执行几乎任意的JavaScript, 但范围在开闭之内 tags.

State

人们很容易认为AMP只适用于新闻站点:显然，像数据绑定和JS状态管理这样的现代工具是不受限制的……没错? Wrong! AMP随时准备将DOM交互与全局状态对象绑定，这要归功于AMP -bind. 事实上，AMP项目是 Preact图书馆的第一位白金捐赠人，这表明它只打算增加与领先的JS框架相同的功能.

Scope

AMP能做你在非AMP网站上可能做的所有事情吗? 不，当然不是，从定义上说. 但是更实际地说, 它可以提供你真正关心的90%的功能, 这可能会帮你一个忙，防止你的应用成为它可能使用的任何框架的边缘案例.

AMP作为前端框架:一种令人惊讶的有效方法

它比你通常喜欢的更抽象. 它没有那么灵活. Guess what? 抽象本身并不坏. 灵活性本身并不好. 每个都有一个合适的水平，我相信AMP为大多数项目提供了它.

Plus, 它提供了其他框架无法提供的东西:谷歌的CDN, 它们的SERP预取, 以及他们选择传达的除了吸引人的灰色闪电之外的任何SEO好处. 对任何网站来说都是宝贵的盟友!

Companion demo: Repository | Live app

In my opinion, Svelte是web框架中真正的“下一件大事”, 在如何处理web开发方面引领一些前沿的(或)进化:

1. Svelte是第一个编译时框架(Svelte 于2016年11月15日承诺，爱奥尼亚的“模板”也紧随其后 几个月后)
2. 苗条是第一个使用的“语言” 命运的运营商 真正的响应式编程
3. Svelte也是推广“虚拟DOM是多余的”这一观点的先驱

使用Svelte是什么感觉?

我必须诚实, 一开始感觉很奇怪, 尤其是当你意识到你写的不是JavaScript的时候, 但是还有别的. 直到您发现所有新概念的存在都是有原因的:帮助您编写更相关的代码并避免样板文件.

我不是模板语言的粉丝，你写这样的代码:

{#每个猫都是猫}
{/each}

这也许就是我喜欢React的原因. But here, Svelte无缝集成了JavaScript对异步结构的理解, 允许这样的代码:

{#等待承诺}
  
...waiting
{:then number}
  
The number is {number}
{:catch error}
  
{error.message}
{/await}

这使得它比只关注逻辑结构的模板语言有趣得多.

svelt的响应部分——如何处理状态管理——也很有趣. 新的命运号操作员， $:, 在技术上与本地JavaScript标签语法兼容，但编译成完全不同的东西. 它很容易使用，但通常常规赋值操作符更合适:

Count {value}!

Click!

在上述情况下, 不需要使用命运操作符，因为赋值操作符(由事件触发)重载了重新呈现功能.

Click!

但是在这种情况下, 如果您需要对属性中的更改做出“反应”, 不能使用赋值操作符, 因为它只会执行一次. 因此，您必须使用命运操作符($:) here.

如果你仔细想想，它只不过是React的一个惯用版本 this.setState().

文档很棒. svelte.dev 你需要的一切都在那里, 有很好的解释和互动的例子.

由于源代码映射，调试非常容易，但是如果您检查 bundle.js 苗条的生成, 你会发现几百行清晰的JavaScript代码，如果你愿意，你可以调试它们.

Is It Worth It?

如果你不了解最新的前端开发，并且正在寻找进入它的地方苗条也是不错的选择. React变得越来越简单, 但在很多情况下，创建一个新的React应用程序肯定是多余的. 苗条采用了重要但复杂的概念, 比如状态管理和不变性, 把它们藏在更简单的后面, 比如响应式编程和命运操作符. 这样即使你刚开始学习，也能学得更快更容易.

如果你有使用其他框架的经验，你绝对应该花一两天的时间来学习这个奇妙的框架. 它将对你很有用，即使只是快速原型，或创建小型应用程序.

当然，它也为大规模应用做好了准备. 你不必相信我的话:苗条一直在 部署在一些严肃的现实场景中 取得了巨大的成功.

Svelte:你在其他框架中缺失的一切

It’s fast! Fast to learn. Fast to work on. Fast to run. 我很乐意参加《欧博体育app下载》，任何时候都可以. 我肯定会在我的下一个个人项目中使用它，我强烈建议你也这样做. React很酷，但为了实现同样的目标，它被复杂的计算机科学概念所膨胀. 现在是时候做些新鲜的事情了，重新开始，给web开发带来乐趣.

Companion demo: Repository | Live app

在你明白之前 Cycle.js，你必须理解流. 如果您使用Node，以前可能遇到过它们.Js后端开发，或者如果你已经熟悉流行的流库之一: Most.js, RxJS, or Cycle.js’ own XStream.

对于外行人来说, 将流想象成类似于数组可能是最简单的, 只不过它跨越的是时间而不是空间. 比如JavaScript数组, 流可以包含任何东西, can be sparse, 可能是异质的.

流有一个开始，也可能有一个结束，或者可以无限地继续下去. 它们的成员存在于瞬间. 在流中出现新成员的那一刻，它通过回调函数发出，很像 Promise or an Observable (两者都可以很容易地形成流). 它们可以像使用函数式编程支柱一样被操作 map, fold (analogous to reduce), combine (somewhat like concat), flatten, and filter 他们，还有其他的. 此外，与许多数组函数一样，流函数返回转换后的内容的新流.

良性循环

举例来说，受…启发 Cycle自己的教程假设你有一个按钮，你想计算用户点击它的次数. 您已经将文档的单击事件转换为事件流(我们将跳过这一部分)。.

如果它是一个记录的点击事件数组, 我们可以通过只过滤按钮上的点击来达到这个目的. 假设我们也不能从这里取数组长度, 我们把它们映射成15, 把它们化简成一个和. 让我们看看它在XStream中的样子:

// event$是点击事件流，#clicker是按钮
常量计数$ =事件$
 	.filter(event => event.target.Id === 'clicker')
 	.map(() => 1)
 	.fold((acc, cur) => acc + cur, 0)

//记住，对于流，fold是减少的
//它的工作原理是一样的，除了它产生一个随时间变化的结果流而不是一个单一的值

// event$是一个点击流...click...click...click...click...
// count$是一个1的流...2...3...4...5...

你可以订阅 count$ 使用一个函数更新DOM中的计数器元素, 或者将其记录到控制台, 或者发布到你的后端.

这很好，但是循环呢.js?

想象一下，你把你前端的所有东西都变成了一条小溪. 您拥有用户输入事件流, 定时流周期性地触发实时数据的刷新, streams of fetch 请求检索数据、数据流 fetch 响应、应用程序状态流、DOM更新流等等.

现在想象一下，你的应用程序的核心是一个连接所有流端到端的纯函数. 它接受输入流，称为 sources，转换它们的成员，并产生输出流，称为 sinks. 接收器连接到处理副作用的模块. 其中一些模块，叫做 drivers，可以提供自己的输出流，这些输出流反馈到纯函数的源中.

你可以让你的应用这样工作:

你已经创造了……等等…….js).

应用程序中的所有业务逻辑本质上都是声明式的, 并存在于一个简洁但非常可读的核心函数中，该函数为Cycle.js calls run. 或者是其中的几个: run 可以通过将函数的源和接收链接在一起来嵌套和组合函数.

所有的函数都可以是纯函数，除了那些有副作用的函数，比如创建 XMLHttpRequests或更新DOM. 你所有的模块本质上都是响应式的:它们订阅流并对流做出反应, never concerned with managing outside state; inversion of control happens by default in Cycle.

副作用存在于远离业务逻辑的孤岛中, 哪个只关心流如何连接在一起. Cycle提供了一组很好的驱动程序，用于管理常见的副作用，如异步请求和DOM操作. 制作自己的驱动程序很容易:它们接受输入流sinks，在这种情况下，并且可能具有输出流(sources), mirroring run. 每当其中一个输入流发出一个新项时，就调用驱动程序.

The way you think about the flow of activity in your app maps directly to how your code is written; those conceptual flow charts you might draw while architecting an app are effectively pseudo-code with Cycle.js. 这就是框架真正的天才之处. 如果你想一分钟，或者更好, 尝试一下，您将发现您现在已经具有了功能, 被动的超级大国.

Superpowers? What’s the Catch?

Cycle.Js自豪地宣称自己“几乎没有魔法”——实际上它并没有做太多不好的事情——但整洁, expressive, predictable, 以及易于追踪的循环核心功能.Js应用程序都是他们自己的技术. 如果你觉得我太夸张了， give it a try 或者查看 广泛注释的main函数 在我的演示中.

当然，我明白你的意思，但有几点需要注意:

• Cycle.js is a small fish in a big pond; it lacks a robust third-party module ecosystem and large community, 它的文档和教程有点粗糙
• 要把他介绍给一个团队是很困难的, 甚至在一个预计未来会增加更多开发商的绿地项目中使用, 因为缺乏经验丰富的开发人员
• Cycle.如果您不熟悉函数式编程的概念，或者不喜欢它们，那么一开始可能很难理解Js
• 它没有太多的工具，尽管有一个 Chrome浏览器插件
• 为循环编写单元测试和集成测试.Js在某些方面更简单, 但在概念上有所不同:少了嘲笑和孤立, 但是更多的是异步性

什么时候应该使用自行车.js?

您可以在生产中使用它——我已经使用过了, 在几个小型商业项目中，我是(现在也是)唯一的开发人员，但它可能不适合那些不喜欢函数式编程或已经对另一个框架感到满意的团队.

如果你对这些警告感兴趣，请给Cycle.在你的下一个爱好或业余项目中尝试一下吧. Cycle.js is small, 而且它与其他框架配合得很好, 特别的反应, 这样你就可以开始享受Cycle了.Js的好处是为现有的应用构建一个小模块.

Companion demo: Repository | Live app

随着它最近的2.0重写发布, Mithril是一个非常快速和灵活的单页面应用程序框架，被Vimeo等使用, Nike, Lichess, and Fitbit. Its API is tiny, 让它更容易学习, 但它的功能覆盖范围正好适合网络应用, 具有开箱即用的路由和XHR支持.

Mithril的方法使用了虚拟DOM，并专注于组件, so in that sense, 它有点类似于React. 但是我同时尝试了React和Mithril, 我可以说，我用《欧博体育app下载》制作应用的经验非常丰富, 整体上平滑多了.

秘银哲学:“少即是多”

Mithril的文档非常出色，它的学习曲线也非常平缓. 它的开发人员(和官方文档)主要关注现实生活中的用例.

由此产生了两个特征:

1. Mithril-based代码 通常跑得非常快 默认情况下，但在需要时也很容易进行优化. 这使得它特别适合嵌入式和移动目标, 同时也支持越来越多的桌面, laptops, 平板电脑运行在(甚至是昨天的)最便宜的硬件上.
2. 秘银给你让路，然后 让你完成工作. For example, 当我创建我的第一款Mithril应用时, 我发现组件通信是一个明显的用例，而不是一个需要解决的难题 就像React一样.

习惯用语，但相当不受拘束

Mithril的开发人员围绕Mithril的多态提供了合理的习语, variadic, 以及无处不在的上标功能 m().

不过，他们并不坚持这样做. 秘银本身是灵活的，只要你需要. You can 如果您喜欢JSX，可以使用它. 但是您可能会发现，Mithril简洁的语法很容易在本地使用——附带的好处是 你可以完全不用Webpack这样的构建系统来使用Mithril，就像我的同伴演示一样，它最终可能会说服您根本没有必要使用JSX.

如果你喜欢CoffeeScript，它的语法变得非常简单，接近YAML的领域:

ToggleButton  =
  view: (vnode) ->
    m '.toggle',
      M 'input[type=checkbox]'， vnode.attrs
      m '.toggle-state'
      // ...

(Thanks to Davorin Šego 对于上面的例子.)

Mithril的开发也很有效 with TypeScript or even with Haxe, if you’ve heard of it.

并不是每个人都喜欢React Hooks API，但如果你习惯了，那就有 第三方Mithril库, too. Prefer streams? 它们包含在 optional module.

还有一些工具可以将普通HTML转换为Mithril的超脚本片段.e. 使用Mithril的纯JavaScript m()但我敢打赌，任何能直接使用JSX的设计师都能很好地遵循超标语法.

虚构的社区? (替代技术面临的大问题)

Mithril已经存在很长时间了，所以有一小群忠实的追随者. 当你需要帮助的时候，你可以通过正常的渠道，如StackOverflow, Gitter等，找到好的帮助.

Sure, 就像其他人一样, 当你在寻找一个快速的附加组件或试图雇佣有经验的开发人员时，一个小的社区意味着一定的限制. 但这并不能阻止秘银 being awesome. 我怀疑任何精通React的开发人员都会这样做 very 如果交给你一个预先存在的Mithril代码库来维护，或者即使是制作一个新的代码库，你也会很快变得真正富有成效.

请记住，Mithril的开发人员密切关注现实世界的用例. Mithril even has 它自己的测试框架ospec，使用起来很愉快.

Mithril兼顾了开发者和用户体验

Mithril在尺寸上取得了一些鼓舞人心的成就, performance, 开发人员经验, 即使它继续务实地发展. 有些人可能不同意它背后的设计决策, 和任何技术一样, 但很明显，这些决定是经过深思熟虑的.

用Mithril编码的技能是可以转移的, 因为您仍然在使用普通的JavaScript, normal CSS, 和普通的DOM事件——只是更智能. Caution, 一旦你学会了, 你会发现很难回到主流框架中去工作.

Companion demo: Repository | Live app

Hyperapp 是一个超级简约的UI框架. It’s 高度声明，借用…的精华 榆树建筑. Hyperapp占用空间非常小，重量为 4.3 kB minified or 1.9 kB Minified +gzipped，可以通过摇树进一步优化. 然而，它的功能非常丰富，允许你以纯粹的功能方式编写应用程序.

Hyperapp带来了一个定制的虚拟DOM实现，而最近从头开始的v2重写将动作“分派”层直接放入了框架呈现层. 这带来了一些惊人的便利. 例如，内置处理程序可以直接接受从" state "到"新更新的状态"的函数:

 state + 1}>Increment

Note在撰写本文时，Hyperapp v2处于测试阶段，其文档有时不完整. 不用担心:Hyperapp团队正在不断改进它们，所以这只是时间问题. 您可能还会对v1-many感兴趣 有趣的项目 毕竟是用它建造的.

杰出的特征

• 纯函数式方法使其非常清晰，易于推理 dataflow.
• 管理副作用和效应作为数据的方法，如Elm和Cycle.js—this is huge! 如果你使用React，你会希望你也有这个功能.
• 没有应用程序代码样板:它专注于 what to do instead of how.
• Highly 可测试的:你的整个应用程序是一个纯粹的函数从状态与效果隔离的结果.

Biggest Drawback

而Hyperapp的代码非常容易理解, 有一点需要注意:没有“组件”的明确概念。. Hyperapp避免成为“另一个基于组件的UI框架”——在某些方面很酷, 但使用组件作为UI组合单元将有利于可重用性, 包括它自己的本地状态和逻辑. (另一方面，它的功能构成很好.)

注意，Hyperapp团队鼓励开发人员使用Web Components的Custom Element API来定义类似于本机的组件——这是在Hyperapp作用域之外运行任意代码的最简单方法.

告诉我代码!

Let’s look at 官方的“counter app”例子. hyperapp 带来了它自己的 h 函数来帮助创建虚拟DOM节点, 而是使用一些Babel(或TypeScript)魔法, 使用JSX很容易(也更简洁):

从“hyperapp”中导入{h, app};

app({
 init: () => 0,
 view: state => (
   

     
{state}
      state - 1}>-
      state + 1}>+
   
 ),
 node: document.getElementById(“软件”)
});

Pure Functions

Hyperapp中的所有动作都被定义为纯函数，返回两者之一 state or 有效果的状态. 这意味着所有事件处理程序都喜欢 onclick 期望传递“reducers”，它将更新由框架维护的状态. 减速机的功能有:

const reset = () => 0;
const decrement = state => state - 1;
const increment = state => state + 1;

app({
 init: reset,
 view: state => (
   

     
{state}
     Reset
      - 
     +
   
 ),
 node: document.getElementById(“软件”)
});

然后，您可以将reducer移到外部模块中，在其他地方重用它们，并单独测试它们!

最佳功能:作为数据的副作用

效果是简单的功能，不包含在Hyperapp的核心中. The hyperapp-fx 包包含了一堆各种各样的效果，今天可以无缝地在Hyperapp应用中使用. 在不久的将来，一大堆的官方软件包将可用，如 @hyperapp/time, @hyperapp /事件 and more. 它也非常简单(和有趣)!)来写你自己的.

Elm Architecture中Hyperapp最强大的模式之一是 将效果表示为数据 底层框架可以处理哪些. 因此，要执行一些具有副作用的操作，例如进行HTTP调用或从 localStorage-应用程序不执行的效果. 而是传递 效果描述 到Hyperapp框架. (这就像Cycle.Js，其中的效果由驱动程序而不是应用程序代码处理.)

下面是一个获取随机引用的HTTP调用示例:

从“hyperapp”中导入{h, app};
从“hyperapp-fx”中导入{Http};

const getQuote = () => [
 '...'， // "loading quote"占位符
 Http({
   url: http://quotesondesign.com/wp-json/posts?过滤器[orderby] =兰德&过滤器(posts_per_page) = 1”,
   action: (_, [{ content }]) => content
 })
];

app({
 init: '点击这里查看引用'，
 view: quote => 
{quote}
,
 node: document.getElementById(“软件”)
});

The Http 函数在这里并没有进行实际的HTTP调用:而是向框架发出一个指令来执行此操作, 表示为纯数据.

这非常容易测试:测试可以对传入应用程序的纯数据和描述新状态和运行效果的纯数据进行断言.

甚至像设置焦点这样的东西在应用程序中也是纯数据. 例如，在下面的代码片段中，将焦点设置为 element, the setFocus 减速器仍然是纯的. The focus function from @hyperapp/dom 只向底层框架发出“命令”，以查找具有特定类型的元素 id 并执行DOM操作:

从“hyperapp”中导入{h, app};
从'@hyperapp/dom'导入{focus};

const setFocus = (state, id) => [state, focus({ id })];

app({
 view: () => (
   

     
     Set Focus
   
 ),
 node: document.getElementById(“软件”)
});

另外，请注意这里有一个很好的元组语法，用于向动作传递额外的负载: onclick ={(行动,有效载荷)}. Neat!

紧随其后的是订阅

另一个宏伟的榆树建筑特色, Hyperapp的订阅功能可以让应用程序监听来自外部世界的输入. The twist? 接收到的事件仍然是应用端的普通数据. 这是正确的，即使它可能是由一些不纯的代码作为副作用的结果生成的.

订阅也是以完全声明的方式设置的. 假设我们想更新应用状态 time 属性，每秒钟使用一个新的时间值:

从“hyperapp”中导入{h, app};
从“@hyperapp/time”中导入{interval};

const tick = (state, time) => ({ ...state, time });

app({
 subscriptions: state => [
   interval(tick, {
     delay: 1000
   })
 ]
});

它与主流框架相比如何?

我认为我们不需要比较它们:Hyperapp意味着一种不同的方法, 不一定比React更好或更差, Angular, or Vue.js. 关键是 does 带来自己的主要好处. Hyperapp非常值得熟悉，因为它和榆树建筑都突出了许多优雅的状态管理和效果处理模式. 声明性副作用是, in particular, 随着时间的推移，我希望它在主流框架中变得更加普遍.

Hyperapp最适合做什么?

这是一个通用的web界面框架，可以用来代替，e.g., React. 实际上，这可以归结为偏好. 区别主要在于强加的编程风格, 强烈支持函数式和声明式方法. 我不认为它是一个“利基”, 要么，它运行得很好, 每个LOC的有用模式密度非常高. 一定要试一试!

配套演示(结合存储库和实时应用程序)

Preact是一个前端框架，旨在提供与React相同的功能集，而其包的大小只是React的一小部分. 但是这种方法带来了什么不同呢? 如何在它们之间做出选择?

Familiar API

On the surface, Preact组件看起来与React组件相同, 以及生命周期方法, JSX, and hooks. 如果你想尽可能接近React, 那么你就不会对Preact失望了.

Code Example

下面是一个典型的有状态组件:

从preact中导入{h, render, Component};

类Hello扩展组件{
  render() {
    return (
      

        
Hello {this.props.name}
      
    );
  }
}

render(, document.body);

Preact和React有什么不同?

基本Preact发行版中的功能对开发完整的用户体验有很大帮助. That being said, 当你从React切换到Preact时，一些差异可能会让你犹豫. For example:

• props.children 总是一个数组，这可能会影响你的实现“渲染道具”模式.
• 门户在基本发行版中不可用，但是 可单独安装
• Support for Fragments and the new Context 缺少API(但计划)

Preact如何实现更小的包大小?

Preact库的重量只有3.5 kB，同时提供与react + react-dom相同的功能，它们的总重量为35 kB. 小包大小是Preact设计决策的核心, 如果不在性能和可用性之间做出妥协，就不可能实现这一目标.

Preact vs. React性能比较

Preact取消的第一件事是虚拟DOM差分. Instead, Preact在更大程度上利用了浏览器的功能, 用更少的抽象实现相同的结果. Benchmarks 他说，Preact在某些情况下速度较慢，而在其他情况下则快得多. 然而，即使在最坏的情况下，这里的负面影响似乎也可以忽略不计.

拆分功能和可树摇模块

Preact的设计理念也影响了其代码的组织方式. 确保只有最少的必要代码进入最终的包, Preact提取可选功能, such as hooks, 分成不同的模块. 这使开发人员能够通过牺牲代码重用来支持自包含函数，从而更好地利用摇树技术.

与React的兼容性

除了提供React功能的完整补充, Preact还可以在你的Preact项目中使用React生态系统中的任何组件. 为此，Preact提供了一个名为 preact-compat的公共API的完整实现 react and react-dom，但使用Preact提供的函数.

preact-compat 最重的模块是从Preact单独运送的，额外增加4个.1 kB到包大小.

To start using preact-compat 你需要这样做，以便任何依赖于react的外部库开始使用 preact-compat instead. 您可以通过更改打包器配置来实现这一点. 下面是webpack的一个例子:

{
    // ...
    resolve: {
        alias: {
            “反应”:“preact-compat”,
            “react-dom”:“preact-compat”
        }
    }
    // ...
}

也可以将现有项目迁移到Preact preact-compat 用完全相同的方法. 这为开发人员提供了灵活性，可以在开发的任何阶段开始使用Preact，而不必从一开始就购买Preact.

But there are a 大量专门针对Preact的库, i.e. 它们提供了自己的Preact绑定. 所以有一个不需要就能进入的生态系统 preact-compat in a project.

什么时候使用预演

使用Preact时, occasionally, 您可能是第一个遇到无法预料的边缘情况的人, 而寻求帮助将会更加困难. React的流行是你不得不放弃用Preact代替它的好处之一. 然而，在某些情况下，Preact绝对是最明智的选择.

为移动网络设计应用程序带来了许多额外的挑战. 有抱负的渐进式web应用(pwa)开发者将面临的一个问题是如何会面 关键路径资源的性能预算. Preact的小尺寸在移动网络环境中发挥了很好的作用，并且在理性的开发人员手中可以证明是一个有效的工具.

嵌入式应用程序也可以从Preact对资源的保守使用中获益. React在