React是一个错误，更像是一个失误。
它骗取了所有人的信任，让他们相信它是一切的答案。
Next.js极力想纠正这个错误，但最终却成为另一个问题。
你知道，当他们说 "你不能在一个薄弱的基础上建造一个伟大的建筑 "时，他们是对的。
React是Web开发进化过程中的绊脚石。
现在是时候接受我们使用react.js所犯的错误，并为更好的生活继续前进了。
当事情出错时，不要随波逐流
在react.js出现后不久，单页应用程序就大行其道，我们用 react 所做的只是重新创建浏览器已经知道如何做的事情：从导航到处理表单再到提出应用请求。
React将概念上的开销提高了一个数量级。虽然在少数地方它值得开销，但在其他地方它只是一个混乱。
追求React的一切的代价是现代复杂性的畸形。
是的，它使前端的功能比以前强大得多。但它也使它变得更加复杂和耗时，对于大多数网络应用来说，这是很合理的。
现在是摆脱这种混乱局面的时候了。
在我们这样做之前--让我们确保我们知道我们的意思是什么。
SSR（服务器端渲染）
把它想象成传统的绘画方式。艺术家在画布上创作整幅画，然后把完成的画发给观众。
它是接受来自浏览器的请求，并将页面的渲染版本作为HTML文档返回作为响应的过程，这对SEO（搜索引擎优化）非常有利，因为它很容易被爬虫索引。
MPA（多页面应用程序）
是另一个用于基于SSR的应用程序的术语，其中你浏览的每一个页面都要刷新页面--想想电子商务应用程序。
SSG（静态网站生成）
类似于SSR，但不是按需（每次）构建页面，而是提前绘制（预渲染）页面，你可以在某个地方存储（缓存）它们。
在另一边（使用客户端渲染），艺术家会向观众发送一个空的画布，然后使用JavaScript在客户端绘制画面，让观众实时观看画作。
如果你想听起来很有技术含量，你可以说CSR（客户端渲染）是指你向浏览器发送一个空的HTML文档，让浏览器使用JavaScript处理里面的所有内容的渲染。
SPA（单页应用程序）是CSR的一个副产品--一个用来描述当你改变路线时不需要重新加载的应用程序的一般术语，它包含在一个页面中，JavaScript使用CSR处理一切。
足够的行话秀逗了
现在，在Web开发领域，我们被SPA（或CSR）或SSR的构建方式所困扰。
尽管在许多人看来，其中一个并不比另一个好。
当使用SPA时--你可以实现像速度一样的本地应用，但你最终会得到很差的SEO（这对你的业务不利）。
现在看来，为了一些搜索引擎公司而放弃SPA的爽快感是愚蠢的--为什么他们不能在这方面下功夫，解决这个问题呢？
谷歌表示它可以使用 JavaScript 抓取网站，但这样做并不便宜，因为与查看 HTML 页面并为其编制索引相比，您必须在无头浏览器中打开页面并执行 JavaScript，一旦 Googlebot 的资源允许，无头 Chromium 就会呈现该页面并执行 JavaScript。
现在，这是一件代价高昂的事情，尤其是当您要抓取数十亿个页面时。如果你使用单页应用程序，你将不可避免地发送大量 JS，如果你想要出色的 SEO，你将受到惩罚。
肯定存在前端需要现代反应性的情况。但我不赞成将客户端渲染范式推广为唯一的救赎之道。
此外，SPA 有时是不可预测的（并且在处理导航时似乎有问题）。
服务器端渲染的好处是可以更快提供一个完全渲染的网站给用户，因为HTML是在服务器上生成的，可以立即发送到客户端。这可以改善用户体验，特别是对于互联网连接较慢或处理能力有限的设备的用户。
但你失去了迅捷的部分，它也有一个缺点，就是设置和维护更加复杂，因为它需要服务器做更多的工作。
为了构建网络应用，我们被困在这两种范式中--这更像是SSR和CSR之间的斗争--我们必须找到一种合理的方式来构建事物。
不能做伟大的事情？以一种伟大的方式做小事情
当涉及到管理状态时，React在浏览器中完成了大部分的逻辑，这在性能上是昂贵的，而且最终会带来相对较大的捆绑开销。
React不必要地将简单事情复杂化。
它在JJSX - VDOM的虫洞中被击中，这消耗了开发者的宝贵时间。
把简单的东西变成复杂的东西并从中获得成就感是根本没有意义的。
我们不能做得更好吗？
幸运的是，这个问题的答案是--是的。
而且事实证明，这涉及这一代人最爱的框架。
Svelte帮助你从JSX和Virtual-DOM的漩涡中突围。
它允许你通过三个简单的步骤编写简单的声明性代码。
它囊括了网络开发的三大支柱--脚本、风格和标记。
这使得事情变得更加简单。
Svelte在构建步骤中处理反应状态，这意味着它不仅更快、更轻，而且你不必处理钩子的限制，核心团队基本上可以在编译器中包含任何他们想要的东西，而不必担心捆绑的大小。
一旦你开始使用svelte来构建甚至是简单的东西，react的开销就会变得很明显。
有了HTML授权的（声明式）语法--它允许你执行枯燥的东西而不感到厌烦。
合理的构建方式
事实上，无论是后端开发人员还是前端开发人员，都不愿意接触客户端，也不愿意对服务器端做任何事情，大多数框架都是围绕这一宗旨建立和销售的。
它们的设计是为了吸引特定部落的开发者，而不是为了有效地解决问题。结果呢？我们得到了以框架为名的蹩脚的抽象性。
著名的框架，如Next和Remix，允许你几乎没有自由地使用它来实现多用途（SSR/CSR），但它们是围绕React建立的，它有虚拟DOM的基本限制，对于许多不同类型的应用程序来说，它是一个进化的死胡同。
很可爱的是，SvelteKit并不是建立在Svelte之上的--它是一个使用Svelte作为视图层的后端Web框架。
因此，如果明天感觉到Svelte变成遗留问题，我们可以通过用其他东西（支持服务器端渲染）替换它来快速前进，而不像其他框架那样与下面使用的技术在时间上发生冲突。
SvelteKit的关键优势之一是它对性能的关注。
与其他使用虚拟DOM来更新页面的框架不同，SvelteKit在构建时编译你的代码，生成高效的vanilla JavaScript，直接在浏览器上运行。
这意味着你的应用程序将更快、更灵敏，用户体验更顺畅。
SvelteKit还能让你轻松构建服务器渲染、静态生成或完全客户端渲染的应用程序。
这意味着你可以选择对你的项目最有意义的方法，而不会被锁定在一个特定的架构中。
默认情况下，你的页面在你第一次访问时是服务器端渲染的，但当你浏览其他页面时，它们将是客户端渲染的。
SvelteKit的另一个优势是它的代码组织方法：
不像其他框架需要你遵循特定的目录结构和文件命名惯例，SvelteKit允许你以对你的项目有意义的方式组织你的代码。
这种灵活性使你能够随着项目的发展轻松地扩展和维护你的代码库。
此外，SvelteKit还配有一个强大的工具包，用于构建实时应用程序。
它包括像WebSockets和服务工作者这样的功能，使你可以很容易地构建反应性强且始终保持最新的应用程序。
总的来说，SvelteKit是一个强大而灵活的框架，与Next.js、Remix等其他流行的框架相比，它具有许多优势。
它对性能、代码组织和实时能力的关注使其成为构建现代网络应用的绝佳选择。
结论
"你所想要的一切都在恐惧的另一边"。
- 乔治-阿代尔
在过去的5年中，React最引人注目的大转变是React文档的大修。
除此以外--还有什么？
React唯一有用的功能是它可以支付账单。
比较React混乱的API命名（Hooks）--Java感觉像一本儿童书。
React生态系统本身是有问题的，有状态管理，有大量的库--几乎所有的库都比你在其他地方得到的差。
以行业标准的名义--React正在做当年Java的折磨。
没有什么事情是你在svelte中做不到的，而你今天却在react中做。
唯一的区别是，svelte重视你的时间，而react则不然。
SvelteKit拥有成为下一个大事件的所有必要因素。
现在它已经达到了1.0版本，商业应用可以从这一点上真正起飞--加入这个行列--在另一端见。