客户想把原来 pb 开发的 mis 系统升级为跨平台的新系统，如果选择用 Ruby 实现有没有成熟稳定的框架可供选择。对于这套 mis 系统有以下几点要求。 1：客户是零售连锁企业，对系统客户端要求能够流畅处理近乎实时的密集型业务。 2：大部分业务是运行在 ms 操作系统之上，如果在 ms 操作系统上不用浏览器作为客户端，那就求能够做到在 ms 操作系统上客户端能够绿色运行 (现在的 pb 程序就是拷贝及运行无需安装，设置，等维护操作)，并能够自动与服务器程序保持一致。 3：如果在 ms 操作系统上用浏览器作为客户端，请问能否完成一些特别的操作：比如打印小票时不用浏览器的打印功能而是直接访问系统的打印机设备进行 ESC 打印，或者设置打印机纸张格式等等对本地设备，文件等资源的访问，修改操作。 4：有没有类似 pb 的 datawindow 的高效快速数据库开发工具，以提高系统开发效率，缩短开发时间，降低开发成本。毕竟 mis 系统大部分功能就是对数据库记录的增删改，和各种各样的复杂的报表统计和数据呈现。 5：相对简单的服务器运行环境部署，让客户降低维护成本。
仔细分析一下需求：
- 看网络稳定性，不过现在宽带普及，4G 或 3G 网络也可以做热点，网络似乎不是瓶颈。
- 客户端自动升级就可以了
- 硬件操作方面还是直接使用 windows 客户端靠谱，使用 ActiveX 控件包装硬件 API 也行，麻烦点。
- 没想的那么容易，业务流程绕死你，开发工作量巨大，还是一家客户一种需求，是个大坑。
- 简单是指 Windows 服务器吗？找找一键部署包，Ruby 的坑略大。
感谢 Winnie 的热心回答复！我提问时说的不够清楚，有些细节我没说。现在正在运行的 pb 程序已经是三层架构的，在 ms 客户端上 pb 程序无需安装，拷贝即运行，服务器端用 WebService 调用 pb 中间层服务作数据传输之用，再后面是数据库服务器。 问题是 1：现在客户想不受限制的在各种设备上访问他的业务数据，实现一些有常规的实时性要求，无需访问硬件资源即可实现的 mis 应用。 2：对于对实时性要求很高很密集界面元素多而逻辑复杂的业务，，考虑是否在 ms 操作系统上去使用，所以提到了在 ms 客户端 Ruby 程序能否拷贝即运行，或者下载即运行无需维护 3：有些业务 (但也不是很多) 确实需要直接访问操作系统的一些设备和资源，例如对销售单据的 ESC 打印，使用标签打印机等，这些操作是不能直接用浏览器代理的。 4：业务很密集，界面元素多而逻辑复杂的业务，不用浏览器，用 Ruby 直接以客户端的形式实现最好。 5：简单肯定是 windows 服务器，不是说 Ruby 部署安装在 Windows 上不好吗？我记得有个帖子里有个家伙说“正常人不用 Windows 做服务器”这是为什么？为啥这么说？ 即使不是 Windows 服务器，只要把部署流程化也是完全可以的，但我听卖服务器的人说，Linux 服务器有 n 多版本，且不一定支持最新的 Intel 芯片组和更新的 raid 技术，这些驱动需要自己去做，或者找国外专业做 Linux 驱动程序的公司做：20000 美元起。或者，找去找服务器声明支持的 Linux 版本去用! 6：Delphi 就不折腾了，和 pb 是半斤八两的工具。 7：Ruby 适合复杂的 SQL 开发吗？或者说有没有成熟高效的 SQL 开发工具？ 8：综上所述，用 Ruby 合适吗？有没有合适可用的框架和工具。
想回答来着，但基于 lz 现在的认识水平，感觉不好讲，当前维持原状可能是最保险的方式．
企业软件 web 化的如何，看操作者水平，以我的经历，当然，我现在用的是 python, 我们现在的系统正在或已经从 vb6/.net cs/.net web 切换到纯 web 环境，传统的企业软件开发者只注重开发功能，不注重性能和负载，报表一跨年查询就是几十秒，这种情况在 c/s 还好，在 web 环境，访问量一大，服务分分钟当机． 所以，先问问自己，是否有能力处理这个转变，对如何 web 开发的各个环节优点和缺点有清楚的认识，有合适的前端和后端来处理这个事情． 还有，必须要吐槽所谓 pb/delphi 的伪三层或是.net 这种 wcf 之类的三层，具体就的不展开了．
好的前端＋后端，ui 的反映同 c/s 没有大的差异，相反，我见过不少了看了我们的程序后才彻底放弃 cs 方案，原来 web 也可以这么快．除了处理大量的数据需要分页是常态外，不象 cs 常常加载上万行到表格，硬件资源的访问，在桌面浏览器有较好的解决方案，打印之类的不是问题，但如果在 ipad 等环境，可能需要包装为 app，访问本地 api 才能解决类似蓝牙标签打印的问题（就目前）
在 web 化时，除了纯粹的浏览器访问外，还会有用 atom shell, cepython, nodewebkit 包装的客户端，这样在桌面环境就可以通过 python/nodejs访问本地资源给js使用，用于受限环境，在移动端，无论用纯本地或是html5，ui通常都是重新设计，从产品线的完善角度，是个很多个小产品组成，不是一个产品就能满足所有需求．
框架，大道无形，如果你要做出好的产品，框架的约束越少越好，通常就是简单的组合，如 bootle, torando, zmq, sqlalchemy 等，前端更是需要一定的能力，选择 extjs/kendo ui 之类的成熟框架，至于像 asp webform 那样的，接近 delphi/pb 的编程模式，但做出好的产品，想也不要想． 我在原则就是没有框架，只有最佳实践，最佳实践可以随时更新，自制的框架只会画地为牢．
需求再理一次：
- 老板等管理人员想在 ipad 或 iphone 或 iOS 等移动设备上看报表。
- 有些员工要在 windows 上使用客户端，所以你想把这些都揉在一块。
- 你好像在服务器架构上的知识比较匮乏啊，还听卖服务器的人的商务套话。
- 交互效果好不好完全靠技术支撑，就像楼上 @jjx 说的，web 也有春天。
- MIS 系统的 SQL 能复杂到哪儿去，跟语言无关，实在复杂存储过程得了，高效是相对而言，如果是传统技术开发，后期维护也是一团泥，要具体需求详细分析出相应的解决方案。
- Ruby 不适合你的团队，他不是 PHP 那种“快速，直接，粗鲁”的开发风格，入门不是三两天。
按上面的需求，如果是我来做个项目：
- 移动客户端：如果项目报价低，把原来的 WebService 利用起来，使用类 ionic framework 的 HTML5 包装方案解决。 如果项目要求效果好报价高，用 Ruby 做一套 REST API, Android 和 iOS 移动客户端使用 RubyMotion 来做。
- windows 客户端：要求硬件弱的，可以继续使用 HTML5 包装方案，要求硬件强的，还是 PB 或 Delphi 来开发。
- 服务器部署 依 1 的 情况而定，大不了 Linux 虚拟机 或 Docker 之类的，让维护人员直接网络下载恢复一下就简单了。
- 最大化利用原有业务逻辑，比如存储过程或 WebService 等，避免无必要折腾。