【大前端之前后分离】JS前端渲染VS服务器端渲染

前言

之前看了一篇文章:@Charlie.Zheng Web系统开发构架再思考-前后端的完全分离,文中论述了为何要前后分离,站在前端的角度来看,是很有必要的;但是如何说服团队使用前端渲染方案却是一个现实问题,因为如果我是一个服务器端,我便会觉得不是很有必要,为什么要前后分离,前后分离后遗留了什么问题,如何解决,都得说清楚,这样才能说服团队使用前端渲染的方案,而最近我刚好遇到了框架选型的抉择。

来到新公司开始新项目了,需要做前端框架选型,因为之前内部同事采用的fis框架,而这边又是使用的php,这次也就直接采用fis基于php的解决方案:

http://oak.baidu.com/fis-plus

说句实话,fis这套框架做的不错,但是如果使用php方案的话,我就需要蛋疼的在其中写smarty模板,然后完全按照规范走,虽然fis规范比较合理,也可以接受,但是稍微深入解后发现fis基于php的方案可以概括为(我们的框架用成这样,不特指fis):

服务器端渲染html全部图给浏览器,再加载前端js处理逻辑

显然,这个不是我要的,梦想中的工作方式是做到静态html化,静态html装载js,使用json进行业务数据通信,这就是一些朋友所谓的前端渲染了

JS渲染的鄙利

前端渲染会带来很多好处:

① 完全释放前端,运行不需要服务器;

② 服务器端只提供接口数据服务,业务逻辑全部在前端,前后分离;

③ 一些地方性能有所提升,比如服务器不需要解析index.html,直接返回即可;

④ ......

事实上以上的说法和优势皆没有十足的说服力,根据上述因素,我们知道了为什么我们要采用js+json的方案,但这不代表应该采用。

比如很多朋友认为前后分离可以让前端代码更加清晰,这一说法我就十分不认同,如果前端代码功力不够,绝对可以写成天书,分离是必要条件,却不是分离后前端就一定清晰,否则也不会有那么多人呼吁模块化、组件化;而且服务器端完全可以质疑这样做的种种问题,比如:

① 前端模板解析对手机端的负担,对手机电池产生更快的消耗;

前端渲染页面内容不能被爬虫识别,SEO等于没有了;

③ 前端渲染现阶段没有完善的ABTesting方案;

④ 不能保证一个URL每次展示的内容一致,比如js分页导致路由不一致;

⑤ ......

以上的问题,一些是难点,一些是痛点,选取前端渲染方案至少得有SEO解决方案,不然一切都是空谈

所以有如此多的问题,前端凭什么说服团队使用前端渲染的方案,难道仅仅是我们爽了,我们觉得这样好就可以了吗?

况且现状是团队中服务器端的同事资深的多,前端话语权不够,这个时候需要用数据说话,但未做调研也拿不出数据,没有数据你凭什么说服领导采用前端渲染方案?

为什么要采用前端渲染

最近两年我却找到了可以说服自己采用前端渲染的原因:

① 体验更好

Hybrid内嵌只能用静态文件

事实上我们不能用数据说明webapp(前端渲染)的体验就一定比服务器端渲染好,所以Hybrid内嵌就变成了主要的因素,现有的Hybrid有两种方案:

① webview直连线上站点,响应速度慢,没有升级负担,离线应用不易;

② 将静态html+js+css打包进native中,直接走file模式访问,交互走json,非常简单就可以实现离线应用(某些页面的离线应用)

现在一个产品一般三套应用:PC、H5站点、APP,PC站点早就形成,H5站点一般与APP同步开发,Hybrid中的逻辑与H5的逻辑大同小异,所以

H5站点与Hybrid中的静态文件使用一套代码,这个是使用前端渲染的主要原因,意思是H5程序结束,APP就完成80%了。

因为服务器端渲染需要使用动态语言,而webview只能解析html等静态文件,所以使用前端渲染就变成了必须,而这一套说辞基本可以说服多数人,自少我是信了。

拦路虎-SEO

上面说了很多前端渲染的问题,什么手机性能、手机耗电、ABTesting都不是痛点,唯一难受的是H5站点的SEO,以原来公司酒店订单来说,有20%以上的流量来源于H5站点,浏览器是一个流量的重要来源,SEO不可丢弃。

PS:这次我在公司和同事说前端渲染SEO有问题,结果同事说,百度的产品SEO肯定靠前不用考虑,真不要考虑吗......

所以前端渲染必须有解决SEO的方案,并且方法不能太烂,否则框架出来了也没人愿意用,好在这次做的项目不是webapp,SEO方案相对要简单一点,移动端展示的信息少SEO不会太难,这个进一步降低了我们的实现难度,经过几轮摸索,我这两天想了一个简单的方案,正在验证可行性。

JS渲染应该如何做

前端渲染应该如何做?阿里的大神们事实上一直也在思考方案,并且似乎已经有成功的产出:前后端分离的思考与实践(二)

可惜,读过文章后,依旧没有获得对自己有用的信息,并且对应的代码也看不到,自己之前的方案:探讨webapp的SEO难题(上),连自己都觉得非常戳而没有继续。

编译的过程

而最近在公司内部使用fis时候,一段代码引起了我的兴趣:

{%block name="body"%}
    {%widget name="webapp:widget/index/route/route.tpl"%}
    {%widget name="webapp:widget/index/searchCity/searchCity.tpl"%}
    {%widget name="webapp:widget/index/selectDate/selectDate.tpl"%}
{%/block%}

这段代码基于smarty模板,运行会经过一次release过程,将真正的route模板字符串与服务器data形成最终的html,这段代码引起了我的思考,却说不出来什么问题。

我偶然又看到了之前的react解决方案,似乎也有一个编译的过程:

React.render(
  // 这是什么不是字符串,不是数字,又不是变量的参数……WTF
  <h1>Hello, world!</h1>,
  document.getElementById(‘example‘)
);
//JSX编译转换为javascript==>
React.render(
  React.DOM.h1(null, ‘Hello, world!‘),
  document.getElementyById(‘example‘)
); 

所以,在程序真实运行前有一个编译的过程,一个是编译才能运行,一个是运行时候需要编译,于是我在想前端渲染可以这样做吗?

页面渲染的条件

比较简单的情况下,对于前端来说,页面html的组成需要数据与模板,而服务器也仅仅需要数据与模板,所以简单来说:

html = data + template

前后端的模板有所不同的是:

前端模板也许不能被服务器解析,如果模板中存在js函数,服务器模板将无法执行

但是经过我们之前的研究,.net可以运行一个V8的环境帮助解析模板,java等也有相关的类库,所以此问题不予关注,第二个问题是:

前端数据为异步加载,服务器端为同步加载,但是:

简单情况下,服务器端与前端数据请求需要的仅仅是URL与参数

于是,一个方案似乎变的可能。

前端渲染方案

入口页

将如我们的index.html是这样的:

debug端:

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
    <script type="text/javascript" src="./libs/zepto.js"></script>
    <script type="text/javascript" src="./libs/underscore.js"></script>
    <script type="text/javascript" src="./libs/require.js"></script>
</head>
<body>
<%widget({
name: ‘type‘,
model: ‘type‘,
controller: ‘type‘
}); %>
</body>
</html>

其中name对应的为模板文件,而model对应的是数据请求所需文件,controller对应控制器,我们这里使用grunt形成两套前端代码,分别对应服务器端前端:

注意:这里服务器实现暂时使用nodeJS,该方案设想是可以根据grunt打包支持.net/java/php等语言,但是楼主服务器战五渣,所以你懂的

服务器端:

<!DOCTYPE html>
<html>
  <head>
    <title>测试</title>
    <script type="text/javascript" src="./libs/zepto.js"></script>
    <script type="text/javascript" src="./libs/underscore.js"></script>
    <script type="text/javascript" src="./libs/require.js"></script>
  </head>
  <body>
    <%-widget({
      name: ‘type‘,
      model: ‘type‘,
      controller: ‘type‘
    }); %>
  </body>
</html>

前端:

 1 <!DOCTYPE html>
 2 <html>
 3 <head lang="en">
 4     <meta charset="UTF-8">
 5     <title></title>
 6     <script type="text/javascript" src="./libs/zepto.js"></script>
 7     <script type="text/javascript" src="./libs/underscore.js"></script>
 8     <script type="text/javascript" src="./libs/require.js"></script>
 9     <script type="text/javascript">
10         require.config({
11             "paths": {
12                 "text": "./libs/require.text"
13             }
14         });
15
16         var render = function (template, model, controller, wrapperId) {
17             require([template, model, controller],
18             function (template, model, controller) {
19                 //调用model,生成json数据
20                 model.execute(function (data) {
21                     data = JSON.parse(data);
22                     if (data.errorno != 0) return;
23                     //根据模板和data生成静态html,并形成dom结构准备插入
24                     var html = $(_.template(template)(data));
25                     var wrapper = $(‘#‘ + wrapperId);
26
27                     //将dom结构插入,并且将多余的包裹标志层删除
28                     html.insertBefore(wrapper);
29                     wrapper.remove();
30                     //执行控制器
31                     controller.init();
32                 });
33             });
34         };
35     </script>
36 </head>
37 <body>
38 <div id="type_widget_wrapper">
39 <script type="text/javascript">
40     render(‘text!./template/type.html‘, ‘./model/type‘, ‘./controller/type‘, ‘type_widget_wrapper‘);
41 </script>
42 </div>
43 </body>
44 </html>

虽然,我这里grunt的程序尚未实现,但是根据之前的经验,这是一定能实现的。

model的设计

默认入口端model为一个json对象

debug端&服务器端:

{
    "url": "http://runjs.cn/uploads/rs/279/2h5lvbt5/data.json",
    "param": {}
}

因为服务器端仅仅需要一个url一个param,所以服务器端与debug端保持一致,而前端被grunt加工为:

define(function () {
    return{
        url: ‘./data/data.json‘,
        param: {},
        execute: function (success) {
            $.get(this.url, this.param, function (data) {
                success(data);
            })
        }
    };
})

显然,此数据源文件比较简单,真实情况不可能如此,我们这里也仅仅做demo说明,后续逐步加强。

服务器端运行流程

服务器端由于是基于node的,首先需要配置app,这里将所有路由全部放到index.js中:

 1 var express = require(‘express‘);
 2 var path = require(‘path‘);
 3 var favicon = require(‘serve-favicon‘);
 4 var logger = require(‘morgan‘);
 5 var cookieParser = require(‘cookie-parser‘);
 6 var bodyParser = require(‘body-parser‘);
 7 var http = require(‘http‘);
 8
 9 var routes = require(‘./routes/index‘);
10
11 var app = express();
12
13 // view engine setup
14 app.set(‘views‘, path.join(__dirname, ‘views‘));
15 app.set(‘view engine‘, ‘ejs‘);
16
17 // uncomment after placing your favicon in /public
18 //app.use(favicon(__dirname + ‘/public/favicon.ico‘));
19 app.use(logger(‘dev‘));
20 app.use(bodyParser.json());
21 app.use(bodyParser.urlencoded({ extended: false }));
22 app.use(cookieParser());
23 app.use(express.static(path.join(__dirname, ‘public‘)));
24
25 //全部路由放到index中
26 routes(app);
27
28 // catch 404 and forward to error handler
29 app.use(function(req, res, next) {
30   var err = new Error(‘Not Found‘);
31   err.status = 404;
32   next(err);
33 });
34
35
36 // development error handler
37 // will print stacktrace
38 if (app.get(‘env‘) === ‘development‘) {
39   app.use(function(err, req, res, next) {
40     res.status(err.status || 500);
41     res.render(‘error‘, {
42       message: err.message,
43       error: err
44     });
45   });
46 }
47
48 // production error handler
49 // no stacktraces leaked to user
50 app.use(function(err, req, res, next) {
51   res.status(err.status || 500);
52   res.render(‘error‘, {
53     message: err.message,
54     error: {}
55   });
56 });
57
58
59 app.set(‘port‘, process.env.PORT || 3000);
60 http.createServer(app).listen(app.get(‘port‘), function(){
61   console.log(‘Express server listening on port ‘ + app.get(‘port‘));
62 });
63
64 module.exports = app;

index的代码:

 1 var express = require(‘express‘);
 2 var path = require(‘path‘);
 3 var ejs = require(‘ejs‘);
 4 var fs= require(‘fs‘);
 5 var srequest = require(‘request-sync‘);
 6
 7 var project_path = path.resolve();
 8 var routerCfg = require(project_path + ‘/routerCfg.json‘);
 9
10 //定义页面读取方法,需要同步读取
11 var widget = function(opts) {
12   var model = require(project_path + ‘/model/‘ + opts.model + ‘.json‘) ;
13   //var controller =project_path + ‘/controller/‘ + opts.controller + ‘.js‘;
14   var tmpt = fs.readFileSync(project_path + ‘/template/‘ + opts.name + ‘.html‘, ‘utf-8‘);
15
16   //设置代理,直接使用ip不能读取数据,但是设置代理的化,代理不生效,只能直接读取线上了......
17   var res = srequest({ uri: model.url, qs: model.param});
18
19   var html = ejs.render(tmpt, JSON.parse(res.body.toString(‘utf-8‘)));
20
21   //插入控制器,这个路径可能需要调整
22   html += ‘<script type="text/javascript">require(["controller/‘ + opts.controller + ‘"], function(controller){controller.init();});</script>‘;
23
24   return html;
25 };
26
27 var initRounter = function(opts, app) {
28   //根据路由配置生成路由
29   for(var k in opts) {
30     app.get(‘/‘ + k, function (req, res) {
31       res.render(k, { widget: widget});
32     });
33   }
34 };
35
36 module.exports = function(app) {
37   //加载所有路由配置
38   initRounter(routerCfg, app);
39 };

简单加载流程:

核心点:对于服务器端来说,widget为一个javascript方法,会根据参数返回一个字符串(因为需要同步返回所以模板读取,数据访问皆为同步进行)

① 访问/index路径

② 根据widget参数获取model数据(json)

③ 获取model url,并且根据param发送请求获取数据(这里的情况比较简单,先不要苛责)

④ 根据参数获取模板

⑤ 根据esj模板(类似于undersocre模板),解析生成html

⑥ 将控制器代码一require的方式添加到html,最后返回html

启动node服务,运行之得到了最终结果:

运行结果:

查看源代码,可以看到有完整的html结构:

<!DOCTYPE html>
<html>
  <head>
    <title>测试</title>
    <script type="text/javascript" src="./libs/zepto.js"></script>
    <script type="text/javascript" src="./libs/underscore.js"></script>
    <script type="text/javascript" src="./libs/require.js"></script>
  </head>
  <body>

    <ul id="type_id">

    <li class="type js_type">
        <h2>电脑</h2>
        <ul class="product_list">

                <li class="product">
                    戴尔
                </li>

                <li class="product">
                    苹果
                </li>

                <li class="product">
                    联想
                </li>

                <li class="product">
                    华硕
                </li>

        </ul>
    </li>

    <li class="type js_type">
        <h2>书籍</h2>
        <ul class="product_list">

                <li class="product">
                    三国演义
                </li>

                <li class="product">
                    西游记
                </li>

                <li class="product">
                    红楼梦
                </li>

                <li class="product">
                    水浒传
                </li>

        </ul>
    </li>

    <li class="type js_type">
        <h2>游戏</h2>
        <ul class="product_list">

                <li class="product">
                    仙剑1
                </li>

                <li class="product">
                    仙剑2
                </li>

                <li class="product">
                    仙剑3
                </li>

                <li class="product">
                    仙剑4
                </li>

        </ul>
    </li>

</ul><script type="text/javascript">require(["controller/type"], function(controller){controller.init();});</script>

  </body>
</html>

客户端流程

客户端由于需要异步性,所以生成的结构是这样的:

1 <div id="type_widget_wrapper">
2 <script type="text/javascript">
3     render(‘text!./template/type.html‘, ‘./model/type‘, ‘./controller/type‘, ‘type_widget_wrapper‘);
4 </script>
5 </div>

核心代码为:

 1 var render = function (template, model, controller, wrapperId) {
 2     require([template, model, controller],
 3     function (template, model, controller) {
 4         //调用model,生成json数据
 5         model.execute(function (data) {
 6             data = JSON.parse(data);
 7             if (data.errorno != 0) return;
 8             //根据模板和data生成静态html,并形成dom结构准备插入
 9             var html = $(_.template(template)(data));
10             var wrapper = $(‘#‘ + wrapperId);
11
12             //将dom结构插入,并且将多余的包裹标志层删除
13             html.insertBefore(wrapper);
14             wrapper.remove();
15             //执行控制器
16             controller.init();
17         });
18     });
19 };

① 页面加载,开始解析页面中的render方法

② render方法根据参数获取model模块与template模块

③ 执行model.execute异步请求数据,并与template形成html

④ 将html形成jquery对象,插入包装节点前,然后删除节点

运行结果:

查看源代码,可以看到,这些代码与seo毫无关系:

 1 <!DOCTYPE html>
 2 <html>
 3 <head lang="en">
 4     <meta charset="UTF-8">
 5     <title></title>
 6     <script type="text/javascript" src="./libs/zepto.js"></script>
 7     <script type="text/javascript" src="./libs/underscore.js"></script>
 8     <script type="text/javascript" src="./libs/require.js"></script>
 9     <script type="text/javascript">
10         require.config({
11             "paths": {
12                 "text": "./libs/require.text"
13             }
14         });
15
16         var render = function (template, model, controller, wrapperId) {
17             require([template, model, controller],
18             function (template, model, controller) {
19                 //调用model,生成json数据
20                 model.execute(function (data) {
21                     data = JSON.parse(data);
22                     if (data.errorno != 0) return;
23                     //根据模板和data生成静态html,并形成dom结构准备插入
24                     var html = $(_.template(template)(data));
25                     var wrapper = $(‘#‘ + wrapperId);
26
27                     //将dom结构插入,并且将多余的包裹标志层删除
28                     html.insertBefore(wrapper);
29                     wrapper.remove();
30                     //执行控制器
31                     controller.init();
32                 });
33             });
34         };
35     </script>
36 </head>
37 <body>
38 <div id="type_widget_wrapper">
39 <script type="text/javascript">
40     render(‘text!./template/type.html‘, ‘./model/type‘, ‘./controller/type‘, ‘type_widget_wrapper‘);
41 </script>
42 </div>
43
44
45
46 </body>
47 </html>

整体目录

PS:目录有一定缺少,因为程序尚未完全完成,而最近工作忙起来了......

问题&后续

因为这个方案是自己想的,肯定认为是有一定可行性的,但是有几个问题必须得解决。

debug烦

如所示,开始阶段我们一般都只开发debug层,但是要调试却每次需要grunt工具release一下才能运行client中的程序,显然不好,需要解决。

模板嵌套

模板嵌套问题事实上是最难的,想象一下,我们在一个模板中又有一个widget,在子模板中又有一个widget,这个就变成了一个噩梦,这里的嵌套最怕的是,父模块与子模块中有数据依赖,或者子模块为一个循环,循环却依赖父模块单个值,这个非常难解决。

后续

这个想法最近才出现,刚刚实现必定会有这样那样的问题,而且自己的知识体系也达不到架构水平,如果您发现文中任何问题,或者有更好的方案,请您留言,后续这块的研究暂时规划为:

① 完善grunt程序,形成.net方案

② 解决debug时候需要编译问题

③ 解决模板嵌套、模块数据依赖问题

④ ......

github

https://github.com/yexiaochai/sword

微博求粉

时间: 2024-08-12 22:03:31

【大前端之前后分离】JS前端渲染VS服务器端渲染的相关文章

【大前端之前后分离02】前端模板嵌套问题

回顾 接上文:[大前端之前后分离01]JS前端渲染VS服务器端渲染,我们探讨了为什么要做前后分离,以及前端渲染需要解决的问题,最后提出了自己的解决方案: 前端代码编译形成两套代码:①前端发布版本 + ②服务器端脚本 这个想法借鉴了fis plus的smarty模块化思维,以及reactJS编译运行的概念,上次初步论证了其可行性,也遗留了一些问题,其中比较关键的问题是: 前端模块嵌套问题 我们在一个模板中又有一个widget,在子模板中又有一个widget,父模块与子模块中有数据依赖,或者子模块为

编程学习之如何在Node.js中优化服务器端渲染?[图]

编程学习之如何在Node.js中优化服务器端渲染?[图]在 Airbnb,我们花了数年时间将所有前端代码迁移到 React 架构,Ruby on Rails 在 Web 应用中所占的比例每天都在减少.实际上,我们很快会转向另一个新的服务,即通过 Node.js 提供完整的服务器端渲染页面.这个服务将为 Airbnb 的所有产品渲染大部分 HTML.这个渲染引擎不同于其他后端服务,因为它不是用 Ruby 或 Java 开发的,但它也不同于常见的 I/O 密集型 Node.js 服务.一说起 Nod

服务端渲染和客户端渲染区别

SPA.SEO.SSR 三者的区别? SPA(single page application) 单页面应用,是前后端分离时提出的一种解决方案.优点:页面之间切换快:减少了服务器压力:缺点:首屏打开速度慢,不利于 SEO 搜索引擎优. SEO(search engine optimization)搜索引擎优化,利用搜索引擎的规则提高网站在有关搜索引擎内的自然排名. 我们之前说 SPA 单页面应用,通过 ajax 获取数据,这就难保证我们的页面能被搜索引擎收到.并且有一些搜索引擎不支持的 js 和通

服务端渲染与客户端渲染的区别与应用场景

内容整理自多个论坛博客. 主要参考:https://www.jianshu.com/p/b8cfa496b7ec https://www.jianshu.com/p/10b6074d772c https://www.douban.com/note/722996691/ 客户端渲染(CSR)VS服务端渲染(SSR) 1.客户端渲染和服务端渲染 1.1 概念 客户端渲染:后端不提供完整的html页面,而是提供一些api使得前端可以获取json数据,然后前端拿到json数据之后再在前端进行html页面

大前端 前后端分离带来的好处

大前端 前后端分离带来的好处:1. 前后端分离开发,相互之间的影响很小2. 使用 webpack,模块化打包前端代码3. 在开发时,可以做到代码热替换,可以使用 babel,可以使用 css 预处理器等等4. 打包时,打包代码的同时还可以做到按需加载代码,静态文件地址自动写入 html 标签,压缩 css.js 代码.压缩图片5. NPM 管理依赖 除了享受不到前后端分离的优点外,还会1. 放弃 ES6,只能写 ES5 以下版本的代码,且要自己处理一些兼容问题2. 不能够使用 A.R.V 三大框

闲话js前端框架(5)——再看自己一年前设计的微型渲染引擎

闲话js前端框架 前端人员=美工+设计+代码+测试 --题记 专题文章: 一.从avalonjs的模板说起 二.庞大的angularjs 三.再也不想碰DOM 四.组件化?有没有后端的事? 五.再看自己一年前设计的微型渲染引擎 六.在浏览器标准上做文章 七.抛开浏览器,构建应用容器 八.为何Flash.银光和Java都在网页端一蹶不振 本文属 西风逍遥游 原创, 转载请注明出处: 西风世界 http://blog.csdn.net/xfxyy_sxfancy 五.再看自己一年前设计的微型渲染引擎

Mustache.js前端渲染模板

引自:http://blog.csdn.net/xuemoyao/article/details/17896203 Mustache 使用心得总结 前言: 之前的一个项目里面就有用到这个前台的渲染模版,当时挺忙的也没时间抽空总结一下,刚好上周项目里又用到这个轻量型的渲染模版,真心感觉很好用,因此就总结一下使用心得,算是一个入门级别的指引吧. 1.  Mustache 概述 Mustache是基于JavaScript实现的模版引擎,类似于JQuery Template,但是这个模版更加的轻量级,语

一探前端开发中的JS调试技巧

前言:调试技巧,在任何一项技术研发中都可谓是必不可少的技能.掌握各种调试技巧,必定能在工作中起到事半功倍的效果.譬如,快速定位问题.降低故障概率.帮助分析逻辑错误等等.而在互联网前端开发越来越重要的今天,如何在前端开发中降低开发成本,提升工作效率,掌握前端开发调试技巧尤为重要. 本文将一一讲解各种前端JS调试技巧,也许你已经熟练掌握,那让我们一起来温习,也许有你没见过的方法,不妨一起来学习,也许你尚不知如何调试,赶紧趁此机会填补空白. 骨灰级调试大师Alert 那还是互联网刚刚起步的时代,网页前

闲话js前端框架(2)——庞大的angularjs

闲话js前端框架 前端人员=美工+设计+代码+测试 --题记 专题文章: 一.从avalonjs的模板说起 二.庞大的angularjs 三.再也不想碰DOM 四.组件化?有没有后端的事? 五.再看自己一年前设计的微型渲染引擎 六.在浏览器标准上做文章 七.抛开浏览器,构建应用容器 八.为何Flash.银光和Java都在网页端一蹶不振 本文属 西风逍遥游 原创, 转载请注明出处: 西风世界 http://blog.csdn.net/xfxyy_sxfancy 二.庞大的angularjs Ang