Ember.js 推出FastBoot走向服务器端渲染

使用Javascript能够编写快速 交互的Web应用,这在过去几年已经得到普遍认可,js应用提供了很多超过服务器端技术(PHP JSP ASP)应用的功能,丰富的交互性和轻量快速的反应,这些已经不只是原生应用独有的专利了。

JS的重量应用是产品性应用,在Web上加载一个应用远好于原生应用的下载和安装体验。

富内容应用如新闻和视频也开始使用JS,以便获得更好的交互性,不像产品性应用,用户在一天开始之时登录一次后,就一直处于登录状态,内容丰富的网站每天需要登录很多次,经常都是通过搜索引擎和社会媒体共享等途径反复登录。

在这个场景下,js应用看上去是"正常"的web网页,加载延迟却让人感觉不是十分像Web,的确,这也是2012年Twitter从客户端javascript迁移回服务器端渲染内容的原因。

能够在服务器端启动Javascript应用,然后在浏览器再“补充水分rehydrate”,这已经被认为是一个美好的事情,但是,大部分努力都是聚焦在服务器端将View视图层渲染成HTML(JSP等输出为HTML),这是很重要的一步,但是不足以解决问题。

解决整个问题不只是包括视图层,还包括整个应用从启动开始的生命周期,路由 抓取模型 和渲染(整个MVC过程),现在通过FastBoot将这些复杂的过程整合进入了Ember.js。

FastBoot将允许你传递一个页面的HTML和CSS,然后允许Javascript在完成这些加载后实现掌控,你的Ember应用行为将和服务器端应用没有差别,无论用户来自搜索引擎 移动用户或CURL工具,甚至用户失效了Javascript。

此外,你还可以拥有原来的好的响应性和交互性。

详细见:Ember.js - Inside FastBoot: The Road to Server-Sid

从最初PHP/JSP的服务器端渲染推送Html到浏览器,到后来将MVC迁移到客户端的Angular,js,再到返回重新使用服务器端渲染,这种螺旋上升的最后阶段已经不同于最初的阶段。

第一阶段:看山是山
第二阶段:看山不是山
第三阶段:看山还是山。

yahoo的mojito就是这个实现。但不知什么原因,纯粹由一家公司主导的,并且全部采用这家公司的技术的开源产品很难流行开来,不管做的多好都无济于事。

如果mojito不是采用yui,而是采用其它比如jquery或者有其它社区主导的第三方产品,结果可能就会不一样。

现在yahoo工程师在做的一个实现楼主介绍的无缝的可以在浏览器和服务器之间运行的项目。
https://github.com/yahoo/fluxible-app

就不再采用自家的技术,而是将expressjs,facebook的react等技术组合起来,个人很看好这个项目。

注:再解释一下这个在浏览器和服务器无缝切换的概念,(楼主当然不需要看了)。

1、当你浏览一个网页的时候,url地址栏会显示一个地址,如果你直接输入这个地址或者刷新浏览器,结果是服务器渲染输出,你可以右键查看源代码。

2、当你在页面内交互时,地址栏url也在变,但是是pushstate的结果,页面的渲染发生在客户端,在浏览器内。

能够形成这个结果,你的服务器后端可能会自然而然的采用基于api的restful架构,也就是说浏览器一层,中间服务器渲染一层,再后面restful服务器一层。

楼上解释得很详细,非常感谢,对大家都有帮助。