使用JavaScript呈现整个页面是一种很好的做法

没有。如果一个站点有任何有价值的东西可以在没有JavaScript的情况下提供给用户，那么如果你不这样做，你就会对他们造成严重的伤害。你的代码可能(阅读:将)有错误，CDN可能会下降，他们甚至可能会关闭JS的各种原因。而且完全可以不使用任何JavaScript(使用表单)就登录用户，也完全可以不使用JavaScript获取和提供内容(使用服务器端HTTP请求和呈现)。你已经构建了你的应用程序需要 JS，但除了数据刷新之外，它似乎实际上不需要JavaScript。除非你有什么事瞒着我们。

很好的做法，它不是。在这个特定的案例中可以辩护吗?可能。

还请注意，许多辅助技术现在是javascript感知的，谷歌至少也是如此，即使这不是理想的从SEO的角度来看，一切都没有失去。这真的归结为UX的事情。

我并不是在这里采取强硬立场。当然也存在一些需要JavaScript的反例和存在证明:画布游戏、文本/图像等编辑器、吉他调音器、谷歌地图应用等。我构建的大多数站点都需要JavaScript。还有一个内部网站，只对你自己的员工开放?需要JavaScript可能很好。但是在任何面向公众的事情上都要非常非常犹豫。

理论上没有问题。这就是React应用程序通常的工作方式。

SEO重要吗?如果是这样，您将考虑使用同构应用程序—这意味着您在服务器上生成HTML输出(使用与客户端几乎相同的代码)并将其发送到浏览器。

然而，如果你只是使用JS来渲染HTML内容，而没有像React这样的库，我想说这不是一个好主意。React的流行之处在于它使用了虚拟dom。大多数web应用程序的第一个性能瓶颈是渲染，或者更具体地说，是DOM抖动。React做了一些聪明的事情来最小化浏览器更新页面所需的渲染量。

现在，如果有人想要构建一个web应用程序，我很难想出一个好的理由不使用React和Redux这样的东西。

根据您提供的信息，这很好(我总是认为将某些描述为"良好实践"意味着其他解决方案不好，当事实并非如此时)。

如果不把你的应用拆开看看它是如何设计的，在

• 代码版本控制
• 内容与表示分离

代码版本控制

仅来回传递JSON数据意味着您在性能方面获得了巨大的胜利。但是，您计划好如何将新版本的Javascript代码部署到客户端了吗?例如，在事务中使用HTML5清单、版本信息。

内容与表示的分离

你发送序列化的HTML, Javascript或CSS嵌入JSON?这可能会导致各种各样的复杂性和安全问题。

如果你的应用程序被入侵，最坏的情况是什么?关于保护web应用程序的通常指导是围绕更传统的带有会话的服务器端HTTP请求-响应模型构建的。编写安全应用程序的人首先要知道的一件事是，Javascript无法访问会话cookie。Oauth2就是专门为解决这种情况而编写的。

我想注意几件事:

第一个服务器端渲染vs客户端。Javascript非常擅长在本地做事情....但是如果你试图在加载时隐藏元素(只是一个例子)，你可能会遇到闪烁或其他奇怪的现象，这是一个糟糕的用户体验。拥有合适的init状态非常重要。同样的，如果你有一个庞大的应用程序，它可能会阻碍用户体验，因为长时间的加载时间。

2日可维护性。如果您正在组组化不同的UI元素，那么对视图进行更改将是很自然的。这适用于所有软件，但如果你在没有框架或客户端库(如angular或react)的情况下手动编写组件，那么它将成为你和与你一起工作的人的负担。