同构 JavaScript 已死…同构 JavaScript 万岁！
同构 JavaScript 已死…同构 JavaScript 万岁！
这个视频是我两年前在 ng-conf 上谈论同构 JavaScript 如何风靡世界。当时，在两个地方复制代码的想法(即一个在服务器上用于搜索引擎，另一个在客户端用于丰富的用户界面)让我感到恶心。干规矩！
嗯…从那以后发生了很多事情。具体来说，一些具体的事情极大地影响了我对同构 JavaScript 概念的看法:
- 随着时间的推移，我必须发展和维护一个大型的代码库。在许多情况下，我用来使我的代码“同构”的“技巧”最终导致了比它们解决的问题更多的问题。
- 我的团队变得越来越大，我开始意识到训练某人理解同构 JavaScript 开发的微妙之处是不简单的(并且极易出错)。
- 在我的团队中，发布产品特性的速度呈指数级增长。我最终意识到，超干代码通常会产生紧密的依赖关系，这实际上阻碍了快速的迭代周期(即，您不能快速更改一段代码，因为害怕对许多其他依赖的代码段产生负面影响)
- 更好的服务器渲染解决方案出现了(包括我作为 Angular Universal 团队的一员帮助构建的一个)
- 试图同时优化初始加载性能和内容读取，而不是长期使用和丰富的界面……坦白地说，这是不可能的。当然，你可以在这两方面都做得很好，但是当你想拥有绝对最好的体验时，它们会非常不一致。
我在 AngularConnect 的一次关于代码管理的最新演讲中对所有这些做了一些介绍:
出于所有这些原因，我真的认为同构 JavaScript 已死。嗯……至少同构 JavaScript 的概念是，你可以为客户端构建一个应用程序，然后让它神奇地在服务器上运行。我再也不相信那一套了。
新的“同构”
相反，我相信未来是关于在一个地方创作你的特定平台代码(也就是说，你可以在同一个 repo 中拥有你的 SEO 代码和你的富客户端代码)，然后让你的应用程序的不同部分专门用于其中一个。换句话说:
- 登录页面 —仅服务器端呈现很少或没有客户端 JavaScript。关注最大初始加载性能和内容交付。
- 应用页面 —仅客户端呈现，可能仅在服务器端呈现一个应用外壳。专注于尽可能好的丰富用户体验。
这两个可以生活在同一个网站的同一个领域(在许多情况下应该)。例如，查看 GetHuman.com 上的联合航空公司电话号码页面。它是唯一没有客户端 JavaScript 的服务器渲染。但是，如果您点击一个链接(例如，“跳过等待”按钮)，您将开始与一系列客户端加载的具有丰富功能的页面进行交互。
放大器的最终结论
哦，还有一件事…当你开始沿着这条路走下去，还有一个额外的奖励。你创建的服务器专用登陆页面应该非常接近AMP 规范。“放大”你的页面不应该花费你太多的工作，这将在初始加载时为用户体验带来更多的好处。我将在 ng-conf 2018 上谈论更多这方面的内容，我的演讲是超级强大、服务器渲染的渐进式原生应用。