小的东西你需要平滑两者之间的一些

rmruhul

兼容性但这只会给你带来即时的性能提升，文件大小的减少，并且你可以保留做你正在做的事情。我认为更面向未来和更有趣的方式是，你使用像 Astro 这样的工具，它允许你真正使用 React 来编写你的代码，然后它将编译出来......对不起，主要是 HTML，一些 JavaScript，它将去掉 React 本身，只添加你需要的小交互位。


克里斯：一两年前，我看到来自 Netlify 开发者关系团队的 Jason Lengstorf 的一条推文，内容是关于他如何采用他构建的下一个应用程序，保留 90% 的代码，他只是做了一些更改以使其适应方式Astro 融入了事物，运行了 Astro 编译器，他最终得到了完全相同的站点，其中包含 Whatsapp 号码列表 几乎所有相同的代码，但交付的 JavaScript 比他输入的要小 90%。您将获得所有的性能和弹性胜利只需在已有的基础上添加一个编译器即可自动实现这一点。

克里斯：因此，我对 Astro 这样的工具感到非常兴奋。我还有点担心像 Astro 这样的工具会成为创可贴，阻止我们解决一些总是使用这些工具的真正的系统性问题。因为你可以继续做你正在做的事情，而不是真正做出任何有意义的改变，并暂时减少它们的影响，我不知道从长远来看，这真的能让我们作为一个行业处于更好的位置。特别是因为像 Svelte 和 Astro 这样的工具现在正在朝着这个想法努力，他们将不再发布多页面应用程序，而是发布多页面应用程序，这些应用程序只是通过水合作用逐步将自身增强为单页面应用程序，现在我们是对的回到我们有一个SPA。

克里斯：所以，我提到有些东西已经改变了，我最近看到了 Rich Harris 的演讲，他是 Svelte 和 SvelteKit 的创建者，关于这件事，他非常坚信 SPA 对用户来说更好，因为你不需要获取和每次加载页面时重新运行所有 JavaScript。我得到了这个论点，SvelteKit 以一种非常酷的方式做到了这一点，他们只是拦截传统的超链接并进行一些检查，而不是像 Next.js 或类似的东西那样使用链接元素，React 路由器或其他什么东西查看它们是否指向您的当前页面或外部站点并进行相应的操作。



克里斯：当他们谈论 SPA 更好时，没有人谈论的是所有可访问性的东西，他们往往会破坏这些东西，然后你需要重新插入。所以，即使你喜欢，“好吧，这个库正在来处理拦截链接、查找页面、完成所有渲染并找出需要更改的内容和保持不变的内容，”关于如何让使用屏幕阅读器的人知道 UI 已更改，这个经常被忽略的部分以及如何以一种不那么令人讨厌的方式做到这一点。您不想阅读页面的全部内容，因此您不能只在其中添加 ARIA live 属性。

克里斯：您是否将焦点转移到页面上的 H1 元素？如果用户没有在页面上放置 H1 元素会发生什么？您是否有一些视觉上隐藏的元素，您可以在说页面已加载时放置一些文本以便他们知道？您是否确保将焦点转移回顶部，这样如果他们是键盘用户，他们就不会被困在页面的中间？这是你如何处理的事情之一，这取决于具体情况。我认为图书馆要实现适用于所有用例的解决方案确实很困难。我认为假设开发人员总是会做正确的事情是乐观的。

克里斯：我一开始就提到，我对这些工具感到兴奋，但我也看到他们这样做，让我们再次重复同样的错误，这对我来说就是这样的感觉。我完全理解为什么在某些非常繁重的网站上，您可能想要转向 SPA 模型，但也有很多地方在走这条路时确实会对您自己或您的用户造成真正的伤害。因此，我担心这些工具的出现是为了解决一堆 UI 或 UX 以及基于状态的 UI 的性能相关问题，然后最终以不同的方式重新实现它们。那是我的肥皂盒。如果您有任何问题或意见，我很高兴听到。