Javascript Web应用程序体系结构：在浏览器中使用服务器作为数据和模板的存储库实现MVC

使用以下体系结构实现web应用程序的优缺点是什么：

简单的服务器，只提供数据的JSON响应和HTML以及要在客户机中呈现的模板。 客户端是一个javascript MVC“应用程序”，它接收并缓存HTML模板，并根据需要请求JSON格式的数据。js是应用程序的核心和逻辑，实现所有行为和交互

在这个特定场景中，服务器将请求作为数据存储库和HTML模板服务器。客户端接收模板并缓存它们，以便稍后（使用脱机存储，为什么不使用）在浏览器本身中使用JSON数据呈现它们

我可以看到一些好处：

• 浏览器只需要请求必要的数据和模板，因此它的带宽非常低。缓存模板是一大优势
• 服务器非常简单，甚至可以使用Node.js在javascript中实现，以便通过在服务器中呈现模板并在响应中发送生成的html，为禁用javascript的浏览器提供优雅的回退

还有一些缺点：

• 更多的请求是作为模板和数据分别请求的
• 在这种想法的简单应用程序中，如果用户禁用了javascript，它将不起作用

我已经思考了一段时间，我不知道这个想法有多疯狂，是否有当前的实现，或者甚至是否有一个名称。有什么额外的优点或缺点吗？有任何现有的实现吗

如果这个想法确实有一个名字并且存在问题，请随意关闭它

---

如果我有代表，我会把它变成一个社区维基，但我不能。

我不知道这样的东西是否存在

然而，我没有发现对服务器的请求有什么真正的好处，就像通常的服务器端MVC一样，您只能下载一次模板，然后只请求JSON数据（可能会将模型的一些行为转移到JS）。 另外，请记住，向服务器发送10个1kb的数据请求所需的时间要比1个10kb的请求所需的时间长。如果您有更多的请求和更少的数据，您可能会遇到更高的延迟

我发现这个想法的一个大缺点是，您正在公开所有代码。你可能会混淆它，但它仍然存在，任何人都可以看到它

---

一个很大的好处是：如果你用最少的数据实现一些离线存储，它可能会离线工作。

老问题，但我看到这里没有人提到构建在NodeJ和BackboneJS上的骨骼，这正是你想要的

网址：

Bones为主干应用程序提供约定。它允许大多数人 要在服务器和客户端上共享的代码。骨头暴露了你的皮肤 主干路由作为服务器上的常规路径，以便可以访问 通过非JavaScript代理，而有能力的客户端可以享受正常的 客户端主干网体验

---

Linkedin的工程团队目前正在写博客，介绍他们是如何从服务器端模板迁移到客户端JavaScript模板的

已经有好几篇文章了

---

这是一个好主意，也是一个跳出广场思考的好例子。现在的挑战是证明你为什么要这么做。就我个人而言（思考了2分钟后），我不明白你为什么会这么做，但这至少会引发一场有趣的学术讨论：）关于“10个1kb数据请求与1个10kb数据请求”的论点：客户端应用程序应该需要一组特定的模板和数据才能发送到服务器，服务器可以在一个请求中响应所有这些模板+数据包。当然，如果客户端应用程序执行了其中一些模板，它不会再次请求它们，只请求数据。尽管代码的公开是一个很大的争论，但根据项目的不同，它可能会变成一种优势（可交换的后端是否涉及API？）