我尝试使用PhoneJS——它很容易上手，而且似乎提供了一个很好的框架。但是，我通常更喜欢避免预先构建的框架，因为它们限制了我的灵活性。我主要担心的两个问题是：
1. PhoneJs 使用 Jquery，而很多人建议使用 Zepto 以获得更好的性能
如果您打算使用 Zepto，尽管某些基准测试表明它的整体性能并不比 jQuery 好，但您很可能可以毫不费力地将它用于 jQuery。Zepto 是一个 jQuery 克隆，其中删除了处理旧浏览器边缘情况的代码。由于您正在为移动设备开发，我怀疑这不会成为问题。Foundation 4 框架，仅作为示例，允许您在两者之间进行选择。
2. 我可以使用原生 trigger.io/phonegap 插件吗？
没有理由不能使用 PhoneJS 来构建代码并使用 PhoneGap 或 Trigger.io 来构建、打包和部署它。PhoneJS 和 PhoneGap / Trigger.io 是旨在解决完全不同（但互补）问题的框架。事实上，PhoneJS 页面特别提到了使用 PhoneGap 打包应用程序。您当然可以充分利用您决定与 PhoneJS 一起使用的两者（PhoneGap 或 Trigger.io）中的任何一个提供的 API 和插件。
3. 根据经验，应该避免为移动应用程序使用“大型”框架（出于性能原因）——这就是为什么有些人反对 Jquery Mobile。PhoneJS 相当大。有人对PhoneJS性能有任何经验吗？
除了对下载时间的影响（如果您使用 trigger.io / PhoneGap 将您的代码打包为原生应用程序，这不会成为问题），框架的大小和质量之间不一定存在相关性的表现。据我了解，jQuery mobile 的主要问题是它为渲染其 UI 组件（链接）而生成的标记量。也就是说，我最近在一个使用 PhoneGap 打包的移动应用程序上使用了 jQuery mobile，并且性能很好。我很可能希望PhoneJS 会是一样的。
请注意，您从使用过框架的人那里得到的关于框架性能的任何答案都可能是相当主观的。如果您担心，最好的建议是下载该框架，使用它来为您的应用程序功能的代表性子集制作原型，并在您计划定位的最低规格设备上对其进行测试。
4. 框架降低了灵活性——PhoneJS 定制/扩展有多容易？
一个好的框架可能会在一定程度上限制您的灵活性，但我认为，这是一种积极的方式。它将鼓励您构建代码，使其保持一致、解耦和可维护。既然有人已经为您完成了所有艰苦的工作，为什么还要浪费时间重新发明轮子呢？
使用框架将使您不必做出许多关于文件和代码结构的无聊决定，并节省您的时间，以便您可以专注于在实际问题域中的解决方案中具有创造性和灵活性（即那些您的应用程序独有）。
PhoneJS 由一套 UI 组件和Knockout MVVM 框架组成，因此它大致类似于 jQuery mobile 和 Backbone 的组合。如果您不喜欢 UI 组件，您可以编辑代码以改进它们或选择根本不使用它们。通过查看文档，您将了解 Knockout 的灵活性，但参考我的第一点，如果您发现自己与它抗争，您可能无法充分利用它。
TLDR：就性能和灵活性而言，最适合评估框架是否适合您的要求的人是您。下载它，看看代码，玩弄它，自己制作一些功能的原型，然后根据你的经验做出决定。