TL;博士
在提供RIA交互性的同时,我可以使用什么框架在服务器上保持 100% 的应用程序逻辑?
解释
早在 90 年代,就可以用普通的 PHP 构建 100% 的服务器端应用程序。但随后对页内交互性的需求增加,越来越多的应用程序逻辑被转移到客户端 javascript 中。如今,借助 websocket 和完全动态的 DOM,再次可以构建服务器端应用程序,同时满足所有页面内交互性要求。客户端所需要的只是一个通用的 javascript 库,它通过 websocket 将 DOM 与服务器同步。
虽然我相信这种 Web 开发方法有其优点,但我不想在这里讨论这种技术的优缺点。
我的问题是关于 2014 年底可用的支持这种开发风格的最先进的框架。实验框架也可以,只要它们的架构足够清晰。我不需要现有框架的清单。我想看到一些实现这种软件架构的框架,或者,如果没有这样的框架,我想了解那些最接近理想的框架。
到目前为止,我自己的研究表明Meteor正在朝着正确的方向发展,但它仍然鼓励客户端使用过多的特定于应用程序的 javascript,并将服务器端平台与客户端平台(即 javascript)联系起来。我读过Trello 架构,它在很大程度上将客户端简化为模板处理器,但模板和相关的模板/绑定库是我想移回服务器端的东西之一。Amazon AppStream将所有 UI 逻辑保留在服务器上,但它对于 Web 开发来说非常昂贵,尤其是当用户将应用程序闲置在后台时。
更新:到目前为止,所有答案都集中在 Meteor 上。我删除了 Meteor 标签,因为它可能会产生误导。我提到了 Meteor,因为 Meteor 演示让我可以选择是否要在服务器端或客户端运行代码。现在很清楚 Meteor 不会通过网络传输任何 UI,只会传输数据。因此,它需要客户端上一半的应用程序,至少以模板的形式。
更新 2:我找到了 XML (REX) 的远程事件,这是一种可用于从服务器端应用程序远程操作客户端 DOM 的协议。没有明确的方式将用户操作(点击、编辑)发送回服务器,但也许这些可以定义为 REX 中的扩展事件,这是规范允许的。尽管如此,它仍然只是一个协议。没有真正的软件我可以使用。
更新 3:我必须澄清一件事。简单地获取服务器端模板并将它们转换为客户端模板,然后在客户端上执行这些模板,并不能算作 100% 的服务器端应用程序逻辑。虽然这样的框架允许我使用服务器端 API,但它们不可避免地会给客户端带来负担并暴露出大部分应用程序代码。我正在寻找只将渲染内容(和通用事件挂钩)发送到客户端的东西。
此外,关于小部件/控件,框架可以允许客户端代码处理边缘情况(新的低级小部件),但它不能要求典型应用程序逻辑(模板和高级小部件)的客户端实现。