我正在评估rAppid.js框架作为新项目的候选者。该项目将是一个主要针对移动设备的 Web 应用程序（我将使用 Web 视图将其包装为可以提交到 Apple 和 Android 应用程序商店的应用程序）。我意识到这不是构建 rAppid.js 的主要用例，但我认为它可能会很好地工作，至少在我的情况下，这要归功于 rAppid.js 基于 XML 的 UI 语言。
理论上，我可以使用新的 rAppid.js 服务器在那里呈现模板并将呈现的 HTML 发送到客户端吗？
鉴于我希望页面尽快加载，并且应用程序不需要离线工作，我更愿意在服务器端呈现模板并将它们作为纯 HTML 发送到客户端。显然，在这种情况下，框架只能为我提供单向数据绑定（除非我重新编写 rAppid.js 代码以支持类似于Derby框架的服务器渲染模型），但我认为应用程序的性能改进可能是值得。
也许我对 rAppidJS 在移动设备上的客户端渲染速度过于悲观，但无论如何我很想听听对此的看法。
理论上，我可以使用新的 rAppid.js 服务器在那里呈现模板并将呈现的 HTML 发送到客户端吗？
是的，具有节点渲染功能。但请记住，节点渲染是出于 SEO 的原因而开发的。由于这种背景，应用程序的唯一状态是 url。这可能适合您的应用程序概念（例如 /user/{userid}/news）来呈现用户的新闻，但呈现的站点将是完全静态的。
因此，如果您中继用户输入、客户端验证，您应该按照设计方式使用 rAppid:js，并在客户端上呈现完整的应用程序。
鉴于我希望页面尽快加载，并且应用程序不需要离线工作，我更愿意在服务器端呈现模板并将它们作为纯 HTML 发送到客户端。显然，在这种情况下，框架只能为我提供单向数据绑定（除非我重新编写 rAppid.js 代码以支持类似于 Derby 框架的服务器渲染模型），但我认为应用程序的性能改进可能是值得。
我从 RIA 获得的经验是，有一个初始加载阶段（Flex 应用程序显示加载器，iOS 原生应用程序显示图像，直到应用程序准备好）并且应用程序可以快速运行而无需额外的加载时间。如果您将应用程序分成模块（rAppid.js 很好地支持这一点）并在启动期间加载所需的模块，应用程序应该加载得非常快。如果将应用程序包装在 Web 视图中，JS 性能会比在移动浏览器中运行它稍好。
您也可以尝试结合使用服务器端和客户端渲染，但不要混合它们。因此，在服务器上渲染页面并在应用程序的加载阶段显示静态 html。只要应用程序完全加载，就可以切换视图。
也许我对 rAppidJS 在移动设备上的客户端渲染速度过于悲观，但无论如何我很想听听对此的看法。
在我们最新的项目中，我们还添加了一个预加载器并将项目分成模块。与闪存版本相比，我们还拥有它的 10 倍小，并且在桌面系统中加载速度更快。在移动设备上，由于 Flash 插件，它不会加载，所以我无法比较它。
如果您想在移动设备上获得出色的性能，请将应用程序拆分为多个模块并仅在需要时加载它们。
rAppid:js 支持基于路由的模块加载，因此也可以使用预先选择的模块启动应用程序。