JavaScript 你选择 Angular 还是 Ember?

jiang_plus · 2014年01月21日 · 最后由 luikore 回复于 2014年01月22日 · 26457 次阅读
本帖已被设为精华帖!

把两个框架都过了一下:

Angular:简洁,容易入门,代码量少,但背后做了很多事,觉得不好把控,对脏检查也不是很认同 Ember:结构清晰,跟rails结合更好,官方文档更清晰,但代码量大

你们是怎么选择的?

共收到 105 条回复

Emberjs不是文档不够齐全吗,, 确实很难选,但是angularjs因为google 早以声名在外,,

谷歌扔掉的东西太多了,有枣无枣他都打一杆,发现没枣就抛弃

看过 Yehuda 对 HTMLBars 的介绍之后死心塌地投靠 Ember 的飘过~

不过这货貌似最近跑去玩 Rust 了>_<

#3楼 @defmacro 耶胡达果然有眼光

我一直看好ember…可能是因为我接触的第一个rails应用是discourse…用ember的……但唯一一直怨念的就是ember不能用coffee写似乎…

#5楼 @cassiuschen 虽然我是个 CoffeeScript hater 但是我还是想好奇问一句:Ember 哪里有限制不能用 coffee 写么?貌似看 discuss.emberjs.com 上好多用 coffee 做例子的,RailsCast 那边教程里也是 Coffee 走起。。。

谷东歌不缺高手,鼓捣出来一个新玩意跟玩儿是的,扔掉一个旧玩意跟扔张手纸似的,并且谷歌很会造势,每当推出个新玩意媒体铺天盖地的造势,打几杆发现没枣就扔了不管不问了。这几年每过一段时间谷歌都会弄出来一个"革命性""颠覆性的东西调戏码农,咋呼几声就没下文了,码农还没跟上,谷歌又在鼓捣下一个革命性的东西了

#6楼 @defmacro 诶……是么………还真没太留意………上次关注的时候是像在node下跑,似乎对coffee支持不是很好…然后看angular明确说可以用coffee写……

曾经GWT火的不得了,仿佛就是下一代web的标准,程序员的希望,现在谷歌自己都把它忘了

#9楼 @gaicitadie 其实我个人觉得 Angular 跟 GWT 蛮像的,满屏的 Dependency Injection。。。

根据自己使用各种 Framework 的经验,我建议你分别研究一下 Angular 和 Ember 的源码,然后自己来感觉到底哪个 Framework 的源码自己能够把握,出现问题如果文档上没有,且 google 不到的话,可以自行深入源码去解读,就选哪个。

讨论好像朝着奇怪的方向发展了……

#1楼 @boyishwei Ember的文档还挺好的,看了之后基本掌握了,很标准的MVC模式,所以没有太大难度。 反观Angular,看完文档都不知道说啥

#10楼 @defmacro 谷歌出的东西确实技术含量高,但不够人性化、有趣,比如rails、jquery,让人眼前一亮

我两个文档都啃了两次,动手的时候发现一个问题:为什么要把一个应用拆成两个徒增代码量,所有变量传递都改成 API?

后来 DHH 写了 SJR 那篇文章(http://37signals.com/svn/posts/3697-server-generated-javascript-responses),我发现 Basecamp 方案就是我要的。

#11楼 @lgn21st 你个人用的是哪一个?

两个都可以用,目前更倾向于ember,因为跟rails的逻辑结构更吻合

都不用, 我用 rivetsjs, 比 ember 和 angular 小多了, no shit, 只做一件简简单单的事: 数据绑定, 还不需要手写一堆 getter setter

#5楼 @cassiuschen 我们一直就在用coffee写ember

b/m的路过。。

为啥没人说backbone....

@Rei 如果是有多种客户端(web app, mobile app)这种,server 只当 API 传递 json,web app 用 MVC 就是一个合适的选择。mobile app 如果使用 PhoneGap 的话用 MVC 也是个好方法。

如果只考虑 web app 的话用什么都行,DHH 曾经发过一个推,大概意思就是为什么我们需要 double MVC 共 6 层把事情搞得很复杂。实际使用中我确实感觉到麻烦一些。所以不建议只是为了架构或尝鲜去使用前端 MVC。简单有效的方案就收好方案。

我以前是ExtJS重度使用者,感觉Ember,Angular,Backbone之类的跟Ext里的方式比弱爆了。。。当然,我现在也在使用这些东西

@darkbaby123 可以用 http://www.odata.org/ 将服务器 render 完全弱化, server 只处理 model , validate , permission , scale 此类事情,UI ,是完全不需要 server 来处理的,这样开发其实更简单

@hysios 感觉和 Parse 比较类似。其实把 server API 化也是不用管 UI 的,只用管 resource 和 action 就行。但我一直不喜欢 Parse 的原因之一在于,这种服务简单的把 model 和 RESTful 的 resource 画了等号,面对简单的应用场景没问题,但复杂的地方我觉得还是自己写后端逻辑更好。而且 Rails 本来处理 model, validation 这些就不麻烦。

@darkbaby123 实际上,这让 server 更专注于逻辑,而不是交互,server render 实际上是没办法处理复杂的交互场景的

#13楼 @gaicitadie 完全同意,google 做算法、工程工具没啥问题,但是做框架、语言会很死板,非常不喜欢

但是。。。最后我的选择还是 Angular ,虽然有 DI 等等一系列讨厌的东西,但是整体的思路上先进太多了

期待今年有比 Angular 更“有趣”的框架诞生

@hysios 你没理解我的意思。实际上用 Rails 做 API server 也就是返回 json 而已,不涉及到任何 view & helper 的事情。自然不会有 server render。我举 Parse 的例子只是想说明有些业务逻辑还是自己写更方便。而不是让第三方 API server 托管一切。

@darkbaby123 odata 并不是通过第三插件,而是一个技术标准,是通过 http 实现的一种接口,像是 Rails JSON API 一样, 你可以定义自己的输入与输出参数,调用自己定义的 API , 有点像是 servcie over http, 而且还可以 batch api request/response, 这样避免的要拿一个变量,就发出一个请求的这种问题,你可以把许多的数据通过一个请求拿回来,这样避免了 @Rei 所说的 涂增代码与请求数的问题

而且也是同样支持 restful 所以写业务逻辑是没什么问题的

不聊 backbone 我插不上话

这年头选择太多了也确实是头疼啊, 所以才有了 http://todomvc.com/ 这种奇葩网站. 不过说实在的, todo list这种简单的应用真的用框架写了也不太能试出来一个框架的痛点.

这两者里面只用过angular, 投angular 一票吧.

@Rei @darkbaby123 我同意darkbaby的看法, 随着现在移动端如此强势的情况下, 网页端已经弱化成一种终端形式, 后台的restful化能够使得架构及其简单实用, 非常易于扩展和维护. 各个终端开发团队可以并行开发, 分别实现最贴近于各自平台的交互和UI (或者是hybrid).

Rei转的那篇文章我觉得思路有些不对, 我认为计算力应该往终端移, 特别是初创企业, 如何减少服务器和带宽使用,就能减少初期投入而增加生存的可能性.

#16楼 @darkbaby123 赞, 学习了

#11楼 @lgn21st 严重同意,只有你能够随意玩转angularjs的核心代码,玩转各种自定义指令的话,就选angularjs,否则的话,还是算了吧,许多坑,特别是想和其他框架整合(例如semantic-ui)。要知道angularjs有一套自己的哲学,非主流。

@hysios 这倒是有意思,有时间我去看看。JSON API 的标准确实很有必要。Ember 就自己折腾了一套规范(名字就叫 JSON API),你说的功能像 batch get ,batch update,relationship 和 side loading 都有定义。不过还在完善中,某些地方我觉得也不够实用。目前这方面还有一个比较有名的规范 HAL

JSON API 和 HAL 这两个都是属于 hyperlink API ,我感觉很像把网页的数据直接转换成了 JSON 格式,有数据有链接,如果以后搜索引擎支持的话,完全可以做到搜索引擎友好。也可以避免前端 MVC 动态生成模板导致的 SEO 问题,估计会是以后 API 发展的一个方向。

我在自己的项目中刻意对backbone、ember、angularjs三种框架都用了一下,体会如下: 1 做一些简单的表单处理,angularjs最好用,速度最快,但是面临复杂的情况,就会遇到许多坑,特别是用到js做一些特殊处理(例如与bootsrap整合,所幸的是,有人已经帮你做好了,各种指令、服务等,不过semantic-ui就没有这么幸运了,需要自己写指令和服务)需要自己研究源码,会花费许多时间。 2 bakcbone本身很简单,但也有许多坑,不过克服了这些坑之后,还算顺利,退一步,即使遇到backbone解决不了的,但也可以自己写plugin,另外,backbone有jquery这个后盾,退一万步,还可以用jquery。backbone的缺点是重复性代码比较多,需要考虑许多细节,例如sub-view,模型绑定等(这个缺点可以通过一些插件解决),比较烦。 3 ember从表面看起来最优雅,其设计哲学与rails有许多借鉴,但这一点同时引入许多其特有的概念不是很好理解,从我自己角度来看,其model、view、controller区分的不是很明确,从传统mvc角度理解的话,有点变扭。

总结的话,对于不是很熟练的人来说,backbone风险最小,但比较繁琐。 ember最优雅,但学习曲线有点抖,不过过了这个坎之后,用ember最舒服。 angularjs也许未来很光明,但现阶段风险比较大。 如果最后到了需要研究源码的阶段,backbone最好把握,另外两种旗鼓相当,都不是省油的灯

#3楼 @defmacro Rust 竟然有范型,java的范型让我心有余悸啊。

因为 #16楼 @darkbaby123 和其他精彩回复比如 @xwf286 的点评,我给这个帖子加精。

我来说说我的观点,第一,楼主的问题本来就是一个XY problem 。两个都可以说可以,都可以说不可以。帖子没有一点建设性的新意,只会增加初学者的心里负担。

第二,javascript社区发展很快,但仍然不是很成熟。单独靠它做项目,最最重要的技术还是javascript,框架都是语法糖,没啥心意。和Rails社区比起来,差好几个档次。大家玩技术都是想做的更酷一点。你总不能拿个破车充当奔驰

第三,如果非要做出选择,其实代价也不是不可承受。那就是成为两个框架的top 10 contributor,不管你投入精力的初衷是不是为了验证哪个框架好,最少你曾经投入过精力去做过。

第四,实际项目选那个都可以,作为专业开发,没有的功能就实现它,有的功能就强化它。说这个坑,那个坑,都是在回避问题,不想解决问题。哪有没有代价的选择呢?

@lgn21st 谢谢!大家都是夜猫子~

@jeff_duan 随着 web 端越来越重视交互,和浏览器功能的日益强大,前端 MVC 只会发展的越来越好。因为本身就是因为需求导致的前端 js 越来越复杂,才会有人想到加入模式去构造系统。不管从现实世界用户需求的发展还是从技术发展来看,现在已经接近前端 MVC 的黄金时期。

不过传统的 server rendered website 还是不会消失。有些页面像公司主页或者一些宣传页面,结构简单并且各种动画效果做的很酷。这些页面直接 server render page + jQuery 干活反而更快。还是那句话,不同的应用场景使用不同的技术。

@xds2000 第二点和第三点不赞同。JavaScript 社区现在确实不成熟,但并不代表差 Rails 社区几个档次,实际上论创新程度,Github 上的 JavaScript 项目绝对比 Ruby 项目多。因为某些程度上说,不成熟才代表有足够的进化空间。不成熟,但有前景,就更好了。这两点 JavaScript 都符合。而且严格来说 JavaScript 不存在一个统一的社区,这点跟 Rails 没有可比性。拿 jQuery 社区,Angular 社区和 Ember 社区相比还差不多。

框架就是语法糖,换个角度也可以说,Ruby 才是最主要的(这点没错),Rails 就是语法糖,没啥新意(这点没人同意吧)……

学习和使用框架也没必要成为 contributor 。如果说每种框架代表一种思想,能跻身进入 top 10 contributors 的都是对框架有不下于原作者理解,并且做出绝大贡献的人。我等使用者能去按照实际情况提几个 feature & bug ,发 pull request 修复下 issue 都算是不错了。

@darkbaby123 请注意, Rails重新定义了Ruby。但jQuery,Angular,Ember都只能玩模式,更本动不了一点Javascript的语意。这个差距我说好几个档次都是客气了。但我说个Javascript发展比较快,加上Nodejs的推动,让它可以理论上替代任何后端技术。但就技术,高大上,这三个维度,都是没法和Ruby比(这里不比较Rails)。这是现状,但未来如何,还要看业界的大佬怎么看。

学习和使用框架以成为contributor为目标,进入 top 10 contributors,都只是姿态。你去试试就会知道,投入的精力非一般人那么轻松。我的意思就是投入,只有投入才可以有产出。投入多少看个人情况了。但“去按照实际情况提几个 feature & bug ,发 pull request 修复下 issue ”,这都是打酱油的情况,根本提升不了对这个框架的理解。

好奇,若若问问使用 https://github.com/marionettejs/backbone.marionette 的有多少呢?

@xds2000 框架都是基于语言之上的,语言做不到的,任何框架都做不到。Ruby 的灵活性和潜力就摆在那,只是被 Rails 发现并且发挥到一个极致了而已。所以这点上我觉得 Rails 没有“重新”定义 Ruby。

如果从影响力而言,Rails 把 Ruby 从一个小众的语言一下子拉入了大众视野,这确实可以算是重新定义。但是……它只是 重新定义了人们认知中 Ruby 能做的事情 而已。

同样从影响力而言,Prototype 和 jQuery 完全可以说重新定义了人们对 JavaScript 的看法。让人们认识到可以用如此统一的方法解决跨浏览器的问题,可以用 css selector 的语法去操作 dom 树。可以让不擅长编程的设计师都能上手做一做动画效果。这都不算是影响?没有这些基础框架我们现在还在做 if else 去判断 ajax 用 ActiveX 还是 XMLHttpRequest,还在纠结事件绑定该用哪种 API ,还在纠结某些特定事件是没有冒泡版本的。没有这些库把底层都统一了,你哪有时间去做高大上的 app ?

同理,在 jQuery 做的前端越来越复杂的前提上,Backbone 引入了 MVC 的基本概念来构建前端代码结构,让人们认识到 JavaScript 是能构建前端 app 的“语言”,而不只是到处绑定一下事件写写 callback 的“脚本”,Angular 和 Ember 更进一步让人认识到作为展现和逻辑分离的框架,没必要去手动更新template ,可以让人们更专注于数据。这些都不算进步什么算进步?

如果你觉得 Rails 基于 Ruby 的元编程做了很多的事情,可以在此基础上重新定义 DSL 等等算是重新定义,我只能说语言特性和应用场景不同,不必拿 Ruby 的标准去衡量 JavaScript ,反过来也没必要。举个例子,Promise 在 JavaScript 中特别有用,单这一点就可以改变很多地方的编程模式,但在 Ruby 中没得到重视,除开语言特性的不同,在 server 端也有很多其他的方式(比如 background job)去做到异步调用,以一种更适合 server 端的方式。

至于 contributor 。我本意只是想表达学习框架跟成为 contributor 没有必然联系。想要作贡献也必须要有非常深入的了解,不然就是添乱。很多使用者都只是跟跟源码,能做到发现 bug 并且打补丁都是进一步的了(框架都不了解谁能去打补丁,酱油也不是这么打的)。真正能做到贡献很大的都是对框架有不下于原作者理解的人。这需要大量的时间和精力去积累。只是学习框架没必要定这么高的目标。自己实际上手用用,看开发理念合不合自己的 style 就行。

@small_fish__ 我就用Marionette. 当时在Backbone和Ember之间摇摆,一看到Marionette立刻被说服。Marionette文档虽然很详尽,但在具体实践方面写得没有Ember那么直接,例子也没那么多。感觉一定要深入理解bbclonemail才能顺利入手。我的观点是Marionette各个方面都有覆盖,但比较轻量,很多功能想要可以自己加。

至于Angular, 我是跟着 Unobtrusive web一直做上来的。暂时还没法接受直接在HTML中写ngclick=()之类的做法。

#47楼 @billy 就我个人而言,还是比较喜欢将js逻辑和template分开的。。。然后写一些components 比如图片上传,表单修改,验证,table sort, 分页和以及input search 等等。我感觉b/m比较自由,暂时满足需求,虽然很手工的样子。。

backbone被抛弃了吗?

@billy @small_fish__ 有空说说 Backbone/Marionette 的经验?很多人对 Marionette 评价很高的样子。

#50楼 @darkbaby123 关于 Backbone,我甚至不认为它是一个框架,或者说远远达不到一个框架的程度,只能说他是一些可以方便复用的组件库,可以基于这些组件搭建抽象层级更高一点的框架,Marionette 就是这么干的。但是在抽象问题,映射问题,解决问题方面,越是抽象层级越高的框架越方便有利,从这个角度看,Marionette 就完全被 Angular / Ember 甩出去几条街了。

#47楼 @billy 我在学习 Marionette 的过程中,也发现他很多时候需要反复研读作者的 Blog 上的文章才能理解 Marionette 的设计思想,以及如何才能正确使用 Marionette。

后来公司同事介绍一本书给我,帮我解决了很大的问题,让我在最短时间掌握用 Marionette 构建应用的知识和最佳实践。这本书叫做 Backbone.Marionette.js: A Gentle Introduction 如果需要用到 Marionette 的话,我强烈推荐这本书。

#49楼 @yuh http://backbonejs.org/#examples 这个列表依然给我强劲的信心

以前backbone,现在只用spinejs

@darkbaby123 我们讨论的话题已经开始跑题,但我还是愿意再回一条,以此来切磋。

“框架都是基于语言之上的,语言做不到的,任何框架都做不到。” 不是我要扣字,只是你没有说清楚到底什么是语言做不到了。我不想胡乱猜测你的想法,但你说的意思好像是说没有Rails,肯定有其它项目能把Ruby 的灵活性和潜力发挥到极致? 这个我不敢苟同,但多挣这个,在技术讨论上,也不会让我们学到啥,这个只能把我的论点放在这里。

同样从影响力而言,我指的是Rails -> ruby语言这个方向。 通过Rails core lib转化到ruby core lib(再ruby 1.8 -> ruby 1.9期间),这个就是影响。但jQuery, Angular和Ember -> javascript语言的影响更本就不存在,并没有那个技术能被Javascript标准所采纳。大家只能服从,模仿,兼容javascript标准。加上浏览器引擎对spec的理解又不相同,实现上更多的坑等着开发者。

"如果你觉得 Rails 基于 Ruby 的元编程做了很多的事情,可以在此基础上重新定义 DSL 等等算是重新定义,我只能说语言特性和应用场景不同,不必拿 Ruby 的标准去衡量 JavaScript ,反过来也没必要。" nodejs都把后端全做了,这还有什么不能比的。ruby能做的,javascript也都能做。这个业界的产品都有参考物。作为技术,咱们不比语言特性比什么? 应用场景我说的都是和Web相关的,不靠谱其他,但加上nodejs后,没有什么场景是javascript不能用的。反过来,javascript能做的,ruby也能做,最多转换一下。比如https://github.com/xxuejie/webruby。 这个扯远了,我的观点就是现在ruby和javascript是可以放在一个台面来比的。

至于 contributor ,这个每个人的学习方式不同,可以ignore我的观点。不用讨论这点。

@veggie,Spinejs我也喜欢,可惜应用实例不是很多,所以没用过。Spine的作者写过一本Object Oriented Javascript, 感觉非常不错。

@small_fish__ @darkbaby123 , 同感,喜欢自由。不敢说经验,只觉得好用,够用。关键是掌握sub apps和components. 另外, 广泛应用resreq太重要了。不过现在Stackoverflow上面Marionette非常少人问问题,反观Angular一大把,不解。

@lgn21st, 同感,那本书我也看过,很不错。本质是把bbclonemail加深理解。Brian的视频也是很好的。

#57楼 @billy 使用Marionette 应该人数少了很多吧. resreq是什么意思? res/req吗?

@small_fish__ , this one https://github.com/marionettejs/backbone.wreqr, Extracted from Marionette to decouple modules. The pattern App.request, App.vent is very useful in my opinon. Allow me to reply in English as Pinyin is buggy on Opera in Ubuntu.

我用Angular,方便简洁!

#52楼 @lgn21st 我觉得如果要读完一整本书才能开始使用的一个框架,那成本有点大了(尤其team里成员对js mvc都没概念时)。 我建议对js mvc框架新入门的话,还是可以直接尝试backbone的,熟悉后再尝试Marionette,高阶选手的就看emberjs(经历过从0.9.x 到1.0.0的升级折腾后,我个人认为,它是要把一个简单的事情做得复杂了)。 另外,backbone让我喜欢的一个大原因是基于underscore。

#62楼 @rainchen 你说的对,如果没有 MVC 方面的经验和 Backbone 的基础,是要先解决这个问题。

不过读一本书成本高么?我觉得不高,真的要是连读一本书的时间都没有的话,有点太过浮躁了。你可以理解这本书相对于 Rails 就是 AWDWR,一本教你怎么用 Rails 做 Depot Application 在线书城的教程。我自己读这本 Backbone.Marionette.js: A Gentle Introduction 大概用了一天,时间都花在了把书中的教程亲自敲了一遍,获益匪浅。

@xds2000 说到框架是基于语言之上,我想说的是,任何框架都是在语言之上构建的,他们可以最大地挖掘语言的潜力,但没法做到语言做不到的事情。所以从语言特性上说,没有框架可以重新定义新的语言特性。 举个栗子,客户端 JavaScript 都是跑在浏览器的沙箱之内的,而且有严格的限制,比如 website A 的 JavaScript 读不到 website B 的数据,或者操作浏览器之外的资源(外加 ActiveX 这种插件的另当别论)。 我也并没有表达 “如果没有 Rails 也会有其他框架诞生去挖掘 Ruby 的潜力” 的意思。就像谁也不知道当年牛顿如果被苹果砸死了会不会导致物理学晚发展一百年。这种事情没有定论。

从影响力而言,Rails -> Ruby 的影响力确实存在。其实两者是相辅相成的,框架不能直接去修改语言特性,但可以通过提倡 best practice 去影响语言设计的趋势。Rails 大量用 hash 模拟可选参数,因为这种编程方式用的多了,到了 Ruby 1.9(忘了是 1.9 还是 2.0 了)有了内建的可选参数机制。与此相类似的还有 concern 。很难说 Ruby 是不是受了 Rails 的影响。反过来说,从语言层面有了更好的支持,框架才可以以此为基础走的更远。

JavaScript 也有类似的情况。只是不是由一个框架说了算的。更类似于每个 lib 或 framework 产生一些新的点子。因为 JavaScript 从开始到现在都没有诞生过一个占统治地位和指导思想的框架。原因说起来很复杂,我觉得不仅仅是语言灵活度的因素,还有浏览器不一致的因素。

但这种语言和框架互相促进的情况也是有。实际上 ES 5 和 ES 6 的规范,都是基于现在人们碰到的问题而设计的。而不是先设计好标准然后框架坐等实现。举个栗子,ES 6 module 是为了从语言层面上提供模块化的功能。设计的原因在于模块化这玩意后端以 CommonJS 为主,前端以 AMD 为主。没有个统一的规则。但 ES 6 module 的语法现有的浏览器又不支持。怎么办呢?有人开发了 ES 6 transpiler 去把 ES 6 module 语法编译成 AMD 或 CommonJS 的语法。浏览器不支持的时候就先这么用着,等支持了再作处理。

与此类似的还有 observer ,web component 等。我想说的是,前端这一块不仅仅是有人定规范,然后各家框架都去遵守,框架的发展也会推进或改变标准化的定义。

太晚了,瞌睡来了先写这些。

一直在用angularjs 感觉很不错, 支持一下它

我选angularjs,现在的理由是框架本身下载大小差不多已经是移动客户端的可接受极限了,Ember.js的250kb+初始下载真的不可接受啊。。。

#50楼 @darkbaby123 之所以很多人对 Marionette 评价很高,是因为backbone本身做的有点差,连最低层的视图刷新、内存管理都需要用户自己做(想象一下,一小部分数据改变,你需要手动刷新整个视图),Marionette 弥补了这些缺陷。我倒是觉得backbone+Marionette =ember,我很赞赏ember对视图刷新这部分的处理(特别是被backbone蹂躏过的人来说),读一下:http://emberjs.com/guides/understanding-ember/the-view-layer/上面的文章就知道了。

backbone太低层了(基本上是jquery的一个方便的包装器,不过反过来说,正因为这样,风险最小,jquery大街上一抓一大把,许多问题社区都有解决方案)。

#62楼 @rainchen 同意你最后一句话,underscore使得js也变得那么优美,特别是在集合、函数编程风格方面,不过uderscore可以独立使用。

backbone +1

#65楼 @darkbaby123 看了这篇slide 单从语法上 ember 对我来说更舒服一些。 顺便问个问题 slide里面有 “How Angular Embraces Plain ol’ JS” , “How Ember Ditches Plain ol’ JS”, ol'js 怎么翻译呢

其实支持哪个框架要好没多大意义了,用得好才是重点,做的东西好了用户不会关心你拿什么做的,ember和angular现在都是可以产生生产力的框架,我觉得这个看项目组实际情况来决定用哪个就好了,其实学起来都不难,还有就是个人喜好,我个人是比较喜欢ember这种了,我觉得ember目前被接受程度不高的原因是文档还是写的不够详细,例子也不多,实际上如果你真的用心去学习了ember一定不会让你失望的。还有高手们应该多愿意给大家分享下自己的成果,这样会有助于技术的普及,当然分享在国内也是个问题,小白程序员提问的素质也比较差点。

有没有用react.js的

还是哪个官网比较好看用哪个算了

大家觉得Durandaljs怎样,有用的吗?

再用knockoutjs的说

用过一阵子AngularJS,一开始觉得很高兴,后来各种不清楚跟性能问题搞到很失落,总得感受是入门不难,但是高阶有难度,总感觉没把握。 最近开始使用ractivejs,感觉很清爽,个人会推荐用这个多些。

#71楼 @TsingHan Plain ol’ JS => Plain Old JS => no subclassing (no inheritance)

angular.
入门没那么简单,但是绝对是顶级框架。
比较几个框架的时候,看看关注的人数。另外stackoverflow搜一下。很多帖子的。

不过要是快速开发,还是先rails 吧。

我更喜欢EmberJS 首先在Ember里面可以看到更多Ruby的影子 其次Ember已经是JS MVC的集大成者,用起来比Backbone要方便,但又比Angular透彻 不可否认,Ember还有很多缺点,譬如与生成DOM的jquery插件集成度不好,handlebar的使用导致会出现大批的

#74楼 @krazy react 听名字就觉得不错, 马上试试看...

#82楼 @luikore 确实比angular设计的好一些,侵入性少,还有个叫reactive的

个人感觉任何一个框架 粉丝们都能罗列一堆优点 然后那? 好的宣讲者还应该罗列出自己遇到的缺点 或被虐的经历 然后(准)使用者们权衡一下能不能接受这些弊端,这样结果就出来了。

可能有人说我消极,但我还是坚信: Nothing is perfect

js已经统治世界了。。。。因为web已经统治世界了。 想想还真是,约定一个容器,把标准放出,就是相当于一层开源免费的虚拟机啦,完全隔离了操作系统的不同,更不用说底层的硬件了。在这个免费开放的标准之上,我们构建出缤纷的GUI世界。 web已经统治世界了。。。

86楼 已删除
87楼 已删除

我選擇 BatmanJS

#16楼 @darkbaby123 请问怎么用 Em.Object来自己封装Model呢?我用ember data实在用不下去了,可是我在网上搜,对于用Em.Object怎么自己封装Model的文章实在少的可怜,有没有什么代码可以介绍一下呢?Discourse看到不他的Discourse.Model是哪里跑出来的。

@QueXuQ 我也是很简单的封装了一下。单个 model 用 Em.Object ,集合有些是仿照 Backbone 的做法封装 collection。更简单的地方就直接是 $.ajax 了。举个栗子:

比如单个 model

App.Task = Em.Object.extend
  isNew: (->
    not @get('id')
  ).property 'id'

  # Common methods, like create and update
  save: ->
    if @get('isNew')
      url = "/api/tasks.json"
      method = 'POST'
    else
      url = "/api/tasks/#{@get('id')}.json"
      method = 'PUT'

    $.ajax(url: url, type: method, data: @paramsForSave()).then(
      (payload) =>
        @setProperties(data.user)
      (xhr) =>
        @setProperties(xhr.responseJSON.user)
    )

  # Custom method, finish task, submit to "/api/tasks/1/finish.json" (PUT)
  finish: ->
    $.ajax(url: "/api/tasks/#{@get('id')}/finish.json", type: 'PUT')

  paramsForSave: ->
    # generate params

# class methods
App.Task.reopenClass
  _findAll: (params) ->
    modelClass = @
    $.get("/api/tasks.json", params).then (payload) ->
      payload.tasks.map (obj) -> modelClass.create(obj)

  findAll: (params) ->
    App.PromiseArray.create promise: @_findAll(params)

  find: (id) ->
    # find a single object

App.PromiseArray = Em.ArrayProxy.extend Em.PromiseProxyMixin

使用方法:

tasks = App.Task.findAll(finished: false)
# Before data is resolved
tasks.get('firstObject')    # => null
# After data is resolved
tasks.get('firstObject')    # => an <App.Task> object

这个例子做了一些简化,只是为了解释思路。大概就是把 $.ajax 封装成方法方便调用,至于为什么把 json 用 App.Task 封装起来,是为了用 computed property 构造更多的虚属性,或者实现一些 model 相关的逻辑。

虽然 Ember Data 碰到实际需求不怎么好用,但它的代码还是很值得一看的。比如:

  1. DS.attr 用来声明 model 属性,可以看看它是怎么处理属性类型转化的,比如 json 无法表示 date,都是字符串形式,但在客户端 model 中需要变成 date。
  2. 各种 Serializer/Adapter,根据声明的 model 属性自动生成提交用的 params 。
  3. PromiseArray 和 PromiseObject ,对 array 和 object 的封装,可以用 isFulfilled 和 isRejected 查看 ajax 是否加载完成,而且让 array 在 ajax 没有完成的时候也可以调用 enumerable 里的方法。

如果觉得麻烦,那就用 Ember Model 或者 EPF,不过我觉得他们也只是比 Ember Data 更轻量,碰到问题更容易扩展,其实也没那么灵活。

#90楼 @darkbaby123 Ember Data可以声明model属性之类的方法确实把Model做的更接近M这一层,可是Ember Data的文档实在太少了,遇到问题后需要花非常多的时间进行解决,而且不知道如何扩展,源码看过一点,实在太多了,无法清晰的理解。

估计还得先看看ember model的源码,就几百行而已。

看了你用Ember Object写的源码后,比较清晰怎么用Ember Object来写Model,我试试看看。但是有个地方不是很理解,就是:

$.ajax(url: url, type: method, data: @paramsForSave())
paramsForSave: ->
    # generate params

这个要做的是处理参数的形式,例如把userId转为user_id,还有拼接等等?

@QueXuQ 嗯,建议自己写的时候不要做 camelcase 和 underscore 格式的转换,因为这意味着你要处理两种逻辑:

  1. 获取数据时把 underscore 转换成 camelcase 的model property
  2. 提交数据时把 camelcase 转换成 underscore 的 params

往往一个简单的赋值就要变成写循环去转换 key ,多了一堆代码,而且处理不慎会比较容易出错。

所以我对 model 字段名都是用的 underscore 格式。不和谐就不和谐吧。

#92楼 @darkbaby123 确实,我也不打算做转换了。直接能用underscore的地方就用underscore,就好了。 麻烦我想问问,你有什么拼params的好方法吗?我直接是:

paramsForSave: ->
  user = 
    name: @.name
    email: @.email
  {user: user}

我觉得我这样做比较死板。不知道有没有什么优雅的方法呢?

最简单的做法:

keys = ['attr1', 'attr2', 'attr3'];
params = @getProperties(keys)
# 对不存在的 key, getProperties 会返回 undefined
# $.ajax 会把所有值为 undefined 的 key 忽略,所以要把 undefined 全部转成 null
params[key] = null for key in params when params[key] == undefined
params

#68楼 @xwf286 backbone.model + rivets 倒是可以减少很多刷新的代码,以至于我连状态都用model + rivets 来处理了, View层再也不用写toggleXXX,addXXX,removeXXX了。

backbone 胜在上手,没有多余的概念。用来构建自己的一套framework也非常简单。但是也如其名,只是一个backbone罢了。其余的两个在摸索架构上面还是不建议使用,毕竟一用,感觉就有点定型了。

ember让我抛弃的原因最关键的也就handlebars编译之后过于庞大,View实现刷新的代码实在丑陋。

AngularJS的问题是如果要实现一套对等的API难度过大,架构和概念上有点不利于新手上手,二来Google的东西有点信不过,容易被抛弃的感觉。

#95楼 @iwege 「实现一套对等的API」是什么意思?

#94楼 @darkbaby123 感激不尽,自从告别Ember Data后,行云流水啊。

@QueXuQ ED 主要是还没完成,现实中有太多 edge case 需要考虑了,没可能那么理想化。但自己写 model 也有很多麻烦的地方。所以我现在挺期望 ED 能够完成的。 @iwege Ember 为了实现绑定加入的一系列 script 标签确实很蛋疼,还影响比如 :first-child 的这种 css 。

#98楼 @darkbaby123 恩。关键我看Ember Data现在的更新速度,要完成估计需要很长的时间了。 关于model层这个设计,我有个疑问我想请教一下你。 Ember Data的删除设计是这样的:

@content.deleteRecord()
@content.save()

而我写的是直接就deleteRecord():

deleteRecord: ->
  $.ajax(url: "/api/products/#{@get('id')}.json", type: "DELETE")

然后跳到首页,数据重新加载了,就直接没有了。这样的设计不知道有没有什么缺陷呢?

喜欢backbone的non-opinionated nature,可以让我随时都有掌控权。 对于大一些的backbone,我认为marionette在构建大型可维护的前端应用的best practice和patterns很实用。 现在的前端开发跟软件开发越来越接近,所需要的tools,design patterns也越来越多。花更多的时间去了解自己的设计架构比去了解一个framework的内部运行重要的多。backbone在这点上很赞。

@QueXuQ 我对 ED 用的也不是很多,但 ED 这种客户端 model 层都有种客户端缓存的概念,deleteRecord 是删除客户端 record 可能只是改变状态,让你在客户端能过滤掉这个数据,save 把改变同步到服务端去。

这个没所谓哪种 pattern 更好,看你的实际需要而定。

@coderek 这就是各个框架的设计哲学了。Ember 就是 strong opnionated 的。作者认为对 web 开发而言,有很多架构问题是大部分 web app 都会遇到的,而 “常见的问题需要通用的解决方案”,避免开发者在什么才是最好的构架方式上纠结从而浪费时间。marionette 仅仅提供的是点,而不是面,Angular 则只提供地基。但这没什么不好,如果开发者很清楚自己在做什么,有自己的一套架构,那么选择灵活性高的框架是更适合的选择。

angularjs与rails搭配比较好,rails本身可以补充一下angularjs

Angular ,不过学习资料感觉有点少啊

#67楼 @ericguo 顶一下,哈哈,同感。

backbone的路过。。。。。。。。

最近越发感到angular是神器。当初选他太tm幸运了。

半年多过去了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册