背景
我需要创建一个潜在的非常大的HTML/JS移动web应用程序，该应用程序将作为移动网站提供，并使用Phonegap本地提供。我目前正在努力确定组织应用程序本身的最佳方式。
基本计划是有许多模块，每个模块将专注于不同的感兴趣主题。其中一些模块将非常基本(即公告/新闻)，而另一些模块则非常复杂(即体育：团队成员、日程安排、视频等)。将有一个适用于大多数页面的侧抽屉导航，以便用户可以快速导航到不同的模块。模块内需要有深度链接的能力。这些模块将由各种开发人员和供应商创建。
单页应用程序
我看到的大多数移动解决方案都涉及单页，在这种情况下，这对我来说似乎是个坏主意，因为可能会占用太多内存。似乎也很难协调模块之间的哈希导航和模块内部分之间的哈希浏览。模块开发必须考虑到应用程序框架，并限制了供应商和开发人员的工作方式。另一方面，事情没有那么频繁地加载，一切都可以很容易地相互交流。
多页应用程序
使用多个页面，似乎每个模块都可以用供应商熟悉的任何技术轻松创建(而且可以快速而廉价地创建)。这将减少内存使用，但也会消除模块通信的能力(我不知道这一功能目前对我们来说是必要的)。我可以看到每个模块都会制作一个javascript库，用于常见的各种事件处理(如日志记录错误、导航等)。模块之间的每个应用程序导航都将是一个新的页面调用，重置DOM。如果愿意，每个模块都可以使用单页设计。
请帮帮我
那么，对于这样的东西应该如何设计，有什么共同的或新的知识吗？我渴望开始工作，但不想重写可能已经存在的东西。我的推理有明显的缺陷吗？我很想听听任何有见识的人的意见。
老实说，如果你正在考虑构建任何你认为体积大、复杂度高的应用程序，你真的应该考虑进行本机开发，或者至少使用像Appcelerator这样的东西，将应用程序"编译"为本机代码，以获得更好的性能。如果您打算让任何数量的开发人员构建自己的javascript组件，这些组件可能会也可能不会很好地管理有限的系统资源，那么很快就会遇到应用程序性能问题。
另一方面，如果你只是想证明概念，并且不介意在获得足够的复杂性时对应用程序架构进行大规模重构，那么你可能只想采用web应用程序的方法。
实际上，您还需要考虑后端服务体系结构，而不是前端体系结构。在尝试集成其他开发人员的产品时，这确实会遇到问题。
几年前我也遇到过类似的体系结构问题。它不是移动的，但也不是完全基于网络的。目标应用程序是网站和桌面应用程序的混合体，有可能在未来走向移动。
有趣的是，之前有两次尝试创建一个可以在各种情况下使用的框架。这个问题，以及两次尝试都失败的原因，是开发人员将其视为一个用户体验问题空间。他们使用了几种不同的技术来处理这个项目，但几个月后就陷入了困境，因为他们事先做出了假设，并对这个项目一筹莫展。
我的方法是完全避开所有的UI讨论，专注于可以从任何角度进行处理的后端架构。为此，我创建了一个web服务，该服务具有双向数据，并最终提供了一个数学模型。该服务使用不同的技术从各种来源访问：Flash、Unity、Google Earth插件，最后，从一个提供良好HTML的无关网络架构访问。
我给你的建议是，不要把注意力集中在前端映射上，而要把后端做好。一旦你有了数据结构，你就可以向外构建，内存管理、单片应用程序与否等几个问题，即一个页面与多个页面，几乎都会自行解决。努力创建一个有很多好接口的API，你就不会陷入"很多厨师"的困境。另一方面，给一群分散的开发人员足够的绳索，你永远不会发现所有的节点在哪里！
决定是否最终在基于HTML5的技术(如SenchaTouch、jQueryMobile或Phonegap)上使用原生API是一个福音派黑洞，将在未来数月和数年内上演。在某些情况下，原生应用程序可能更具流动性和速度，但资源投资是应该考虑的。另一方面，JavaScript开发人员潜伏在每个角落，并不短缺。
您的第一步是确定这些需求。
如果你这样做是为了你自己或你自己的公司，那么确定这些模块是如何运作的。
如果你这样做是为了你的雇主，那么某人应该知道他们想看到什么，否则，你将如何构建它？
一个支持多个页面、在没有通信的情况下打开和关闭模块的解决方案将需要与负责同时维护多个小部件的框架不同的东西，这些小部件可能通过系统调用或服务进行通信，也可能不通过系统调用和服务进行通信。
没有办法绕过这一点——为模块构建服务/sandboxing/etc将比将每个模块视为页面更改(或使它们成为字面上的页面更改)需要更多的工作。
当你弄清楚你想让你的程序做什么时，开始构建一个你想让其他人拥有的API的想法
你是要为他们提供一个API来构建UI组件，还是让他们自己随心所欲？
就我个人而言，我会避免出现这样的情况：每个模块的更改都只是替换iFrame，然后最终用户可以在那里做他们想做的任何事情
同样，我会避免允许模块创建者在非沙盒环境中运行他们想要的任何东西的情况。。。它对你的最终用户(或者你，在英国法庭上)来说结局很糟糕。但这还不是一个令人担忧的问题。
第一个问题是您的平台做什么。
然后弄清楚你的后端通信会是什么样子，你将向模块创建者提供什么接口，以及你将如何从你的端到他们的端获取数据(基于http的API、REST或其他任何东西……但如果你还没有的话，请很好地解决它)。
然后，当你知道你的平台应该做什么，并且你有一个可以很好地服务于各种任务的后端时，你就可以弄清楚你将向内容创作者提供什么服务，制作他们的小工具，从你的服务和沙盒上传/下载数据，等等。