我会尽力将此作为一个可回答的问题，而不是讨论的开始。
我的问题的实质是，根据您的经验，最好将您的网站的移动网络版本作为单独的应用程序开发，该应用程序将您的网站用作API或在同一个Rails应用程序中开发提供您的网站？
我目前正在计划我们将如何实施它，而且正如我所看到的那样，每个人都有上行/下行。
移动网络的单独申请
移动网络的相同应用
如果我们要在现有应用中开发移动网络，我们将采用这种方法来呈现移动视图 - http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile-pages-to-a-rails-site/
非常感谢任何见解。
答案 0 :(得分：2)
如果您设计网站以便为任何设备使用相同的代码库，那么您将有9次中有9次会变得更好，以便它能够智能地适应您的设备，从而呈现最重要/最有用的内容/基于样式表或渲染/非渲染的运行时选择的每个设备的功能。请记住，与6年前不同，您今天对移动设备的主要关注点不是缺乏处理能力，而是不同的屏幕尺寸和不同的输入。
通常，移动用户不希望看到您网站的残缺或剥离版本。他们希望看到您网站的 可用 版本。可用的含义各不相同，但它通常意味着最常用的功能非常容易访问，而更隐蔽的选项被隐藏得更低或者可能没有那么优化。 可用可能意味着您为它们提供与桌面上完全相同的功能，但可以在移动设备上更好地呈现。或者你删除了在移动设备上没有意义的东西。但是，如果你设置它，你将不得不为自己做更多的事情，以便你必须维护两个代码流，或者一个早期分支的代码流，或者一个根本不同的应用程序。这是一个更多的测试，更多的编码，更多的破损可能性。
我们遵循这种方法，它适用于我们非常小的开发团队 - 我们已成功使用它，以便我们可以使用相同的代码库为不同的客户运行两种不同的实现 - 一种非常复杂的桌面 - 第一个用户界面以及一个非常精简的移动优先应用程序：
通常，如果您要为移动设备构建已编译的应用程序并且将使用设备的UI在UI上进行繁重的工作，那么API-for-mobile方法将对您最有用。库而不是服务器上生成的HTML。再说一次，如果您选择使用Backbone.js或Angular.js等方法来处理前端显示，那么使用仅限API的方法可能也是一个很好的架构供您遵循。但是接下来你还要走出Rails了。
答案 1 :(得分：0)
在我看来，一条基本信息是＆＃34;为什么？＆＃34;你需要考虑你的预算和时间表以及工作的截止日期。
提供类似于Matthew James Taylor的精美布局的液体布局，它将根据可用的屏幕大小调整大小我能看到需要移动特定模板的唯一原因是为了提供特定的css样式来制作你认为看起来更像是一个移动应用程序。
我不认为表现是一个问题。如果您从现有网站获得性能开销，并且您正在为移动设备设计这些性能问题，那么为什么不为非移动设备设计这些问题。即设计一个具有液体布局的移动站点，并使其适用于桌面/平板电脑查看。这可能是重新设计整个网站以提高性能的好机会。
根据预算和时间尺度，我发现你确实有两种选择
1）设计一套全新的模板，同时使用液体布局设计性能问题，以便随着时间的推移将现有布局切换到新布局
2）重新设计现有的模板和功能，以建立一个适合移动设备的网站。
无论哪种方式，您的台式机和平板电脑用户都会获得好处，但是您可以在多大程度上实现这一目标，这取决于您的截止日期和预算，选项1是短期内更便宜，更快捷的方式，选项2是更便宜，更快捷的方式在长期。我的方式是，通过不为移动用户和桌面/平板电脑用户提供相同的模板，您会对某些人产生不利影响，从而为所有用户提供最佳的体验。
这确实是您项目经理的决定。
更新 - 基于评论
在这种情况下，我会去开发一个单独的移动应用程序。我甚至会考虑使用替代技术来实时流式传输更新的数据。 Rails Live Streaming and Node.js之间有一个很好的比较。
无论您选择是否引入新技术，通过为移动用户提供单独的应用程序，您将提供终极的移动体验，并能够完全专注于此。
我没有看到不同的域名在SEO方面是一个太大的问题。您应该能够利用主站点的现有可见性，并使用单独的移动域名，您可以提高您的搜索引擎优化排名，而无需进行额外的促销。
我猜你有点已经得出了自己的最佳前进方式的结论，我能给你的最好的建议就是告诉你给自己多一点思考时间并让你选择的解决方案坚定起来而且我确定它是否是正确的它只会感觉到＃34;对你而言。
没有人比你更了解自己的业务，如果没有参与项目和业务，说出最终最佳选择是不可能的。