这是一个创建于 3963 天前的主题，其中的信息可能已经有所发展或是发生改变。
这是一点感想。我把它从回复里提出来了post了一篇新主体。希望更多人能探讨。
原post：
好奇为什么web app现在很多都用某种js的框架来开发了？
http://v2ex.com/t/98188
无论是从耦合、性能、扩展、模型等方面来讲，都应该建立起一个明确且界限清晰的『层次』，看到的用JS框架开发webapp只是表象，从更深层次来讲，它实际上是一种数据与逻辑分离的设计理念。
- 10年前，浏览器功能很弱，JS支持有限。因此后端的作用是取出数据、设计逻辑、合成成完整的『HTML』（视图）然后返回给前端。当项目的规模增大到一定程度后，这种模式的弊端就凸显出来了：视图既可以在前端通过JS处理，也可以在后端（如PHP）处理，越来越难以维护；后端数据模型和前端视图死死地捆绑在MVC框架中，过于耦合；后端不仅要处理数据层的CURD持久化等，而且还要花相当的资源处理page partials,进行模板解析。
- 随着浏览器的功能越来越完善，软件工程与架构理念也越来越倾向于前端处理，前端的MVC设计也随之被完善并证实好用。这种设计模式通常如下：
1. 对于数据运算简单的应用，后端仅仅作为一个数据持久化层，对数据进行CURD操作。对于计算复杂的应用（如分析等），后端则同时承担起这一层分析功能，仅仅暴露出输入、输出接口。除此之外，后端不进行一切模板、视图处理。具体来讲，就是RESTful的设计。
2. 前端（浏览器端）程序需要完整的MVC：
M作为一个服务层，主要用于与后端服务交互。这一层，需要一个适配器来把后端的数据抽象成模型。需要一个输出输入的接口，代理后端请求。
V是标准的HTML组成的页面、样式等等。这一层尽量没有任何与用户交互有关的JS代码。
C用来连接M与V，各种JS代码各种交互控制数据绑定等等。
好处就是，
后端接口抽象出来了，前端可以自成体系开发UI，而不需要折腾各种奇怪的Jade、PHP template Engeen之类的东西；
后端可以作为API独立提供服务，甚至足够开放，让前端UI形成丰富的生态系统；
后端不再处理页面上的事情，把页面拼凑生成模板等任务移交给用户端，减小开销提高性能；
前后端通过前端的Model层耦合，复用性高，替代性好；
TDD模式的开发变得更为简单彻底；
在迭代或重构时，只需要确保前后端Restful API的一致性。
Angular.js在这方面走到了前面，这种思路运用得非常彻底。不妨一看。
但至于Ruby/Rails很多教程涉及到的那一块的backbone.js, jqeury, d3d等相互嵌套使用，个人不敢恭维。
如有兴趣，当你更深入的开始研究Node.js等的时候，你会发现，前后端的界限其实越来越模糊了，模糊到你根本不知道当前正在写的代码会在服务器运行还是在客户端运行————但其实这并不重要，重要的是，它们正在全力支撑着你的项目。
说的有点多。一点感触。
原post：
好奇为什么web app现在很多都用某种js的框架来开发了？
http://v2ex.com/t/98188
无论是从耦合、性能、扩展、模型等方面来讲，都应该建立起一个明确且界限清晰的『层次』，看到的用JS框架开发webapp只是表象，从更深层次来讲，它实际上是一种数据与逻辑分离的设计理念。
- 10年前，浏览器功能很弱，JS支持有限。因此后端的作用是取出数据、设计逻辑、合成成完整的『HTML』（视图）然后返回给前端。当项目的规模增大到一定程度后，这种模式的弊端就凸显出来了：视图既可以在前端通过JS处理，也可以在后端（如PHP）处理，越来越难以维护；后端数据模型和前端视图死死地捆绑在MVC框架中，过于耦合；后端不仅要处理数据层的CURD持久化等，而且还要花相当的资源处理page partials,进行模板解析。
- 随着浏览器的功能越来越完善，软件工程与架构理念也越来越倾向于前端处理，前端的MVC设计也随之被完善并证实好用。这种设计模式通常如下：
1. 对于数据运算简单的应用，后端仅仅作为一个数据持久化层，对数据进行CURD操作。对于计算复杂的应用（如分析等），后端则同时承担起这一层分析功能，仅仅暴露出输入、输出接口。除此之外，后端不进行一切模板、视图处理。具体来讲，就是RESTful的设计。
2. 前端（浏览器端）程序需要完整的MVC：
M作为一个服务层，主要用于与后端服务交互。这一层，需要一个适配器来把后端的数据抽象成模型。需要一个输出输入的接口，代理后端请求。
V是标准的HTML组成的页面、样式等等。这一层尽量没有任何与用户交互有关的JS代码。
C用来连接M与V，各种JS代码各种交互控制数据绑定等等。
好处就是，
后端接口抽象出来了，前端可以自成体系开发UI，而不需要折腾各种奇怪的Jade、PHP template Engeen之类的东西；
后端可以作为API独立提供服务，甚至足够开放，让前端UI形成丰富的生态系统；
后端不再处理页面上的事情，把页面拼凑生成模板等任务移交给用户端，减小开销提高性能；
前后端通过前端的Model层耦合，复用性高，替代性好；
TDD模式的开发变得更为简单彻底；
在迭代或重构时，只需要确保前后端Restful API的一致性。
Angular.js在这方面走到了前面，这种思路运用得非常彻底。不妨一看。
但至于Ruby/Rails很多教程涉及到的那一块的backbone.js, jqeury, d3d等相互嵌套使用，个人不敢恭维。
如有兴趣，当你更深入的开始研究Node.js等的时候，你会发现，前后端的界限其实越来越模糊了，模糊到你根本不知道当前正在写的代码会在服务器运行还是在客户端运行————但其实这并不重要，重要的是，它们正在全力支撑着你的项目。
说的有点多。一点感触。
 |
1
suriv520 OP 我还在研究Post为什么不会被显示在流上……
|
 |
2
chemzqm 2014-01-24 23:31:47 +08:00
Friendly advise, do not use Angular unless you don't maintain your code,it only suitable for creating apps with only CRUD.
|
|
3
suriv520 OP @chemzqm Thanks for the advise, and can you be more specific on your point? especially since I'm currently using angularjs in many projects.
|
 |
4
mengzhuo 2014-01-25 22:49:14 +08:00
>>> 1. 对于数据运算简单的应用，后端仅仅作为一个数据持久化层，对数据进行CURD操作
奇葩的各种校验权限，各种安全、防渗透，数据统计、修复问题是前端能解决的？ 前端把后端想得简单了吧？ 两端都在做的苦逼人深深地了解一个真理——Nothing is simple. |
|
5
suriv520 OP @mengzhuo 我不清楚你是在尝试理解我的意思还是在咬文嚼字，但我敢肯定你还没有从上一个项目的阴影中走出来。
另，做Python+PHP+Ruby+Nodejs+Golang+Javascript/coffeescript+HTML5+LESS的人我也不知道应该定位成前端还是后端。 |
|
6
mengzhuo 2014-01-26 00:30:15 +08:00
@suriv520 既然是有些经验的dev，那就不多说了，你应该能明白后端不“仅仅”是CRUD。
阴影说不上，我只是个打杂的 回到题目上，前端有Adday那帮家伙吆喝，跟一堆人搞出的Grunt、Yeoman、Bower加上Angular确实加速了我们的生产/调试的效率，不过也只能在产品认为目标客户高大上的时候才能用上，碰到IE6-8，再多Polyfill也白搭，不如JQuery来得短平快（虽然难看难维护，好歹还能跑） |
 |
7
rekey 2014-01-26 01:59:26 +08:00
所谓前端工程师的自我臆想...
P.s : 我也是是所谓前端... |
Select Language