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