好奇为什么web app现在很多都用某种js的框架来开发了？

后台得提供内容啊，当然也可以用 Node.js

web 的东西，都是一前一后，有前端必然有后端。不然数据怎么处理？即使前端有逻辑，后端必有一份比前端更强大的逻辑。

除非某某员偷懒，看前端有逻辑，后端就略过了。

web 开发安全准则一条是，前端推过来所有数据都是不安全的。

DHH的访问：When to use Pjax, when to use client-side MVC, and the performance secrets of Rails 4 and the new Basecamp: https://twitter.com/dhh/status/239435882044727296

关于JavaScript是否需要框架的讨论：Frameworkless JavaScript － Why Angular, Ember, or Backbone don't work for us： https://moot.it/blog/technology/frameworkless-javascript.html

还有AngularJs跟jQuery的本质区别：StackoverFlow－How do I “think in AngularJS” if I have a jQuery background?

因为简单……

我一直理解为，因为是app不是site，交互需求更强，这也是restful流行的原因吧

resetful中，权限控制还是要的。

因为所谓基于html的bs结构有着天然的缺陷，后端能力被隔离了，很多东西都不是能够直接操作的。
所以能直接操作的javascript自然大行其道，自然衍生出框架。
其实RIA的理念在10年前就在提了，只是各大公司谈不拢，分不均蛋糕。自己去玩RIA的flash推了flex，大家也都知道是什么下场了。
公正的说，BS的B那端，长期以来都是个弱B，至少也能提供flash的能力，我们开发起来才会爽歪歪。看看页游主要用什么就知道了。

长久以来所谓的BS都是在变态的道路上越走越远。现在开发的工作量往“前端”偏，开始重javascript是对的，至少开始走回正途了。目前后端负责好增删改查，提供数据就好了。（仿佛看到了多年前的flex）
以后真正的理想化，根本不应该分所谓前端后端，我们只管写好“程序”就行了

@bigzhu 仔细读你 的话中…… 好像很有道理

Node.js 是后端啊

能移到前端的都是表现逻辑，包括楼主说的backbone之类的
这不算是啥后端的变化，只不过前端的技术更丰富了而已

我发现很多后端需要被普及一下mvc的编年史，以前在qclub讲过一次，从最早的smalltalk-80体系中的mvc讲到今天精粹的backbone和大红大紫的angular，再到未来奇幻的meteor。

总体来说，mvc本来是客户端的UI组件交互体系，之所以放在了服务器后端，是因为机器性能，浏览器和当时html/css/js的局限性。

现在看来是服务器端mvc是个硕大无比的坑，但是站在当时的角度来看，浏览器才是一个完整app，那么你的web仅仅是一个view而已。

时代改变技术格局。

@takwai 前端更多的职责是负责交互逻辑，后端是业务逻辑，没有谁比谁更强大。况且大部分程序员做不好前端，因为根本就没有人机交互的素养，学校也不会教。

后端要没饭吃了，楼主该做前端吧。

简洁
高效

如果同样一件事件，你用其他语言要几百兆的安装来实现，但js只用了几兆
而效率上也没什么差别，为什么不用几兆的方案去实现呢？

无论是从耦合、性能、扩展、模型等方面来讲，都应该建立起一个明确且界限清晰的『层次』，你看到的用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等的时候，你会发现，前后端的界限其实越来越模糊了，模糊到你根本不知道当前正在写的代码会在服务器运行还是在客户端运行————但其实这并不重要，重要的是，它们正在全力支撑着你的项目。

说的有点多。一点感触。

@suriv520
谢谢。那是不是可以这么理解，就是后端只是负责管理数据和把各种分析运算的结果给前端？

另外，可以说说为什么对Rails和js框架的嵌套使用不太认同呢？

@itfanr 补充一下,可以关注一下 meteor,已经很有一种写"程序"的感觉了,不怎么分前后端.

@colinxt 我觉得是因为 RoR 管的事太多了，JS 的事它也管了。 我没用过 RoR，感觉而已。