Backbone.js 和 Angular.js 选哪个 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
Sponsored by
国内领先的实时后端云野狗 API 可用于开发即时聊天、网络游戏、实时定位等实时场景传输快！响应快！入门快！
Promoted by
Backbone.js 和 Angular.js 选哪个
10:42:42 +08:00 · 3519 次点击
很纠结 其实我也搜了些关于这两个的比较 但还是很纠结 希望有经验的伙伴们分析下下
27 回复 &| &直到
18:19:24 +08:00
& & 11:04:18 +08:00
2个完全不一样……
其实都学也不是啥问题
& & 11:11:29 +08:00 via Android
你学了一个，另一个就不难了，哦，先学ng
& & 11:12:12 +08:00
你问题描述的不清晰，因为技术只有最合适的没有最好的，根据自己的项目和需求来。
& & 11:12:58 +08:00
适合的场景不一样
& & 11:28:02 +08:00
用 Backbone 的话可以看看
& & 11:53:27 +08:00
看你和哪个更合拍.
挑软件这种事是要看有没有感觉的, 两个都用一用, 哪个让你更爽, 就选哪个. 跟挑女人一样.
& & 14:27:54 +08:00
backbone用着用着，自己添加添加内容就成ng了
& & 15:32:53 +08:00 via iPhone
angularjs。简单易学，更能写出优质的代码。
& & 15:35:50 +08:00 via iPhone
Backbone流行于几年前，然后AngularJS开始流行了，Backbone 就渐渐不行了。 --个人观点。
& & 15:45:03 +08:00 via iPhone
都用过，相比而言angular更潮一些。
& & 15:47:35 +08:00 via Android
选字母排序靠前的那个 (认真状
& & 15:48:21 +08:00
不知道选哪个
就看爹
angular 的爹是谷歌～
所以选angular
& & 16:11:25 +08:00
没用过，但是看过测评，
angular大而全，主流
backbone轻巧，插件多，自定义程度高
& & 16:12:35 +08:00
Ember 呢？
& & 16:53:34 +08:00
@ 毕竟亲儿子
& & 16:54:05 +08:00
回复错了
@ 毕竟亲儿子
& & 17:13:51 +08:00
谁有ng 增删查改的例子
& & 17:20:49 +08:00
Backbone代码 2K 行，容易掌握，当然要写好还是很费劲的。
Angular 不是很熟悉，但是2.0应该和1.x 是不兼容的。
其实还可以选择 Ember，已在公司项目使用，主要是做面向用户的后台系统。
& & 17:32:25 +08:00
backbone自己造的轮子太多了！还是用angularjs吧
& & 18:10:36 +08:00
也可以尝试下avalonjs
& & 20:31:27 +08:00
建议可以看一下Backbone，但是Backbone是基于underscore的，你如果前端不是很熟，可能一下子上手比较难，而且Backbone比较晦涩难懂，你理解一下他的思想就好了
Angular的确不错，比较适合新手
Ember更加复杂不建议初学者使用，Spine的话其实不错的，是基于Backbone的
& & 08:50:19 +08:00 via iPhone
Angular的文档能看…?
& & 12:48:56 +08:00
backbone + react 清量又靠谱, angular 已经快死了
& & 17:36:37 +08:00
Angular 建议先学，并不是因为他比 backbone 好，而是因为他的设计会改变你对一般的 web 前端的看法。他使用到的一些技术，shadow dom 这类东西，以后应该会成为 web 设计的主流。另外 Angular 已经把简单的包依赖处理、前端模板加载等等问题解决好了。入手会很快。
backbone 是一个很轻量的框架，简单来讲优势就是比较灵活，很多企业喜欢用这个。但是开发效率不算很高。另外 backbone 不会挡着你用其他的框架。如果你准备学习 react.js， 那就选 backbone 吧。
至于前面提到的 ember，我不是很喜欢，觉得它既没有 backbone 这种轻量的感觉，也没有 angular 这种功能完备的感觉。
& & 11:40:02 +08:00
@ ng还没死吧?
& & 18:19:24 +08:00
你听说过 Angular 2.0 么...
& · & 1770 人在线 & 最高记录 2011 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.7.3 · 57ms · UTC 03:30 · PVG 11:30 · LAX 20:30 · JFK 23:30? Do have faith in what you're doing.BackboneJS + MarionetteJS
Backbone is an unopinionated library that has Models, Views but no Controllers out of the box. That’s right, a library rather than a framework because your code needs to know about it, rather than it knowing about and executing your code. It does not follow the MVC, MVP or MVVM patterns. It’s views and routers act similarly to a controller. Marionette brings the
to Backbone (if you want or need it), thus you can keep your router doing what it should be doing (just routing, with no controller logic).
What I find strange is that a Backbone view contains a model. I’m not sure I’d even call this a MV* library, as it may introduce confusion.
Backbone’s sweet spot is providing the user with brief and casual interaction. Doesn’t provide help or guidance with deallocating memory and detaching events. Assumptions are that the user isn’t going to be using this application all day without closing the browser window. Although in saying that, there are many applications that use Backbone for this type of thing, but they must provide explicit code to release event handlers. Marionette provided some help here for
of Backbone. and Backbone has improved things with . You will still need to keep in mind that event handlers need to be released though (Backbone’s
takes care of this now). Marionette provides
to deal with these like the
method which provides a place to add clean-up code and then calls Backbone’s remove. Failing to remove event handlers are the largest cause of memory leaks in Backbone.
Backbone: Jeremy Ashkenas
Marionette: Derick Bailey
IRC: #marionette on FreeNode. Little activity.
Conferences
Statistics
Version: 1.1.0
Payload size: Depends on Underscore development version 43kb or minified and gzipped 4.9kb
Backbone development version 59kb
Backbone minified and gzipped 6.4kb
Age: Backbone: Initial Github commits: September 2010
Performance
The second half of
shows the difference between Backbone and Ember performance. What I’ve seen to date, is that in terms of performance, Backbone leads, second is Ember, third is Angular. You need to decide how much performance matters to your situation and whether or not it’s “good enough” for the framework/library you choose.
Documentation
(also covers some backbone)
Screen-casts
. This resource is about adding Marionette to a MongoDB document explorer. Also features source code.
Blog Posts, Tutorials, etc.
Free to use any templating engine. You can use underscore as it’s the only dependency of backbone, or
of your choosing.
A lot of excellent documentation
Very flexible in how you may want to use it
Minimalist library
Easy to learn (not a lot of it).
Payload including dependencies is the smallest out of all three. About 9 times smaller than Ember.
No two way data-binding. Although if you want/need it, you could use the likes of the data binding offerings below in the Interesting Plug-ins section.
No provision for handling nested views. This is where the likes of Marionette’s
More work required to build large scale applications than the likes of Angular or Ember (just a library after all).
If your large complex application is written in Backbone, chances are you have added a lot of boiler plate code. Any new developers coming onto the project will have to get up to speed on this code. If your large complex application uses Angular or Ember and the new developers coming onto the project have worked with these frameworks, they more than likely won’t have to learn the boiler plate code that they would have to with the likes of Backbone, because it’s part of the framework.
Interesting Plug-ins
There is a similar offering: backbone.layoutmanager which I haven’t really looked into, but according to Derick Bailey (Marionette BDFL) is more of a framework where as Marionette is a library.
Two way data binding with , , NYTimes backbone.stickit “is a Backbone data binding plug-in that binds Model attributes to View elements with a myriad of options for fine-tuning a rich application experience”. What looks to be nice about this is that unlike most model binding plug-ins I’ve seen, it doesn’t require you to add any extra tags like Angular to your view. In fact your views are .
Backbone.routefilter plug-in allows you to add behaviour that will be executed immediately before and/or after a route (Backbone.Router or Marionette.AppRouter) executes.
Useful Tools
“Backbone Debugger” for Chrome browser (it’s an extension)
Frameworks that leverage backbone and provide more functionality
(adds handlebars integration plus other functionality)
Now a few more concepts that I think are important to know about if your serious about using a client side JavaScript MV* framework/library and in regards to module loading, this applies to the server side also.
Templating
Blog Posts etc.
Some Offerings
templates are compatible with handlebars. handlebars just has more functionality
I covered some of the template engines
under “Templating Engines evaluated”, or just use the likes of the
Coupling Domain with Framework
As Boris Smus has
and I think it’s right on the money (although I disagree with his comments around JavaScript class as per my comments above):
Once you bite the bullet and decide to invest in a framework, you often have no easy way to move your code out of it.
If you pick Backbone, but decide mid-cycle that it’s not for you, you are in for a world of hurt:
If you have core functionality that you want to release, release it in pure JavaScript, not as a jQuery plug-in, or some MV* module.
Because there are so many JavaScript frameworks coming and going, and we don’t want to invest to heavily into any one of them,
we really need to keep our investment separate from the library/framework code.
To avoid library/framework and class-system lock-in, a good approach in regards to JavaScript MV* libraries/frameworks,
Is to keep the core functionality separate from the user interface code, thus giving us two separate layers.
This gives us flexibility to swap user interfaces as they come and go, yet still keep the majority of our code in an API layer.
The API layer being a logical single layer, but can be modularised, and loaded as needed, AMD style.
With this separation, we can implement the two layers in the following manner.
1) Build the base layer using pure JavaScript prototypal inheritance.
This is the part you write with the intention of keeping and possibly using parts for other projects also.
This base layer will implement an API that you will want to spend a bit of time getting right.
This is the code that will make the most use of unit tests.
To get the separation clear in your head, think of the user interface code as a client that uses this API as if it was service API sitting on the server.
This way you can avoid creating leaky abstractions.
2) Use an MV* library/framework to implement the user interface, and call into the base layer directly.
This lets you move quickly and focus entirely on writing the user interface.
This architecture should facilitate building your user interface on a solid foundation and avoid investing heavily into an offering that you may want to swap out further down the track.
In most browsers, just including a script tag will cause the rest of the page to stop rendering until the script has loaded then executed.
Which is why if loading scripts synchronously, they should be concatenated, minified, compressed and included at the bottom.
Loading scripts asynchronously don’t block, which is why you can load multiple scripts in parallel where ever you want (any more than 2-3 concurrently and performance will degrade). Make sure to concatenate your scripts though.
What we see as our projects get larger, is that scripts start to have many dependencies in a way that may overlap and nest.
The simplest way to load asynchronously is to create a script tag and inject it into an existing DOM element on your page.
Because the DOM element already exists, the rendering is not blocked.
See the first code example
// Create a new script element.
var script = document.createElement('script');
// Find an existing script element on the page (usually the one this code is in).
var firstScript = document.getElementsByTagName('script')[0];
// Set the location of the script.
script.src = &/myscript.min.js&;
// Inject with insertBefore to avoid appendChild errors.
firstScript.parentNode.insertBefore( script, firstScript );
If you want or need to get serious about script loading (which you’re probably going to have to do at some stage), use a best-of-breed script loader. This will also push you down the path of defining modular JavaScirpt (AKA modules).
Next we look at employing script loaders to load our modules…
Formats available for Writing and Using Modular JavaScript
Asynchronous Module Definition (AMD)
For writing modular JavaScript in the browser. To save re-writing what’s already been done…
see “AMD” section, explains it well. What does AMD actually give us?
Separation of Concerns, essentially placing value on interface rather than implementation. Mapping of module IDs to different paths. Lots more. Allows asynchronous loading of modules and their dependencies, which is something we need on the client side, but is not generally a requirement for the server side. For getting started, see “Getting Started With Modules” under the AMD section . Also check out the
and of course the most common AMD implementation: . Then at some stage you’re probably going to want to
your modules and that’s where the likes of
comes in. r.js also has a node.js adapter which allows you to use node’s implementation of
Tom Dale (core team member on Ember) also has some interesting ideas around why he thinks .
API (Optimised for the server)
Although we have the likes of
a CommonJS module implementation that can run in the browser or … makes CommonJS modules available in the browser and is very fast. Ryan Florence discusses module loaders in the pod-cast listed above “JavaScript Jabber Ember Tools” where he decided to move to CommonJS rather than RequireJS for his Ember Tools mostly due to speed. So it’s horses for courses. Decide what your requirements are, then decide which module loader satisfies the most of them. Also see “” under the “CommonJS” section.
Providing a rich standard library. The intention is that an application developer will be able to write an application using the CommonJS APIs and then run that application across different JavaScript interpreters and host environments. With CommonJS-compliant systems, you can use JavaScript to write:
Server-side JavaScript applications
Command line tools
Desktop GUI-based applications
Hybrid applications (Titanium, Adobe AIR)
Why it doesn’t excel in the browser “out of the box”:
ES Harmony (Modules implemented in the language. were not quite there yet, but the current offerings look to be a pretty good step in the right direction).
(specifically “ES Harmony” section) discusses where TC39 are going in regards to implementing modules in ES.next.
So AMD and CommonJS can be used on server side or client side. In some cases one will work better for you than the other. You’ll need to do your homework as to what to use in which scenarios. Both have advantages and disadvantages that may work for or against you.
I’m keen to get a discussion going here on peoples experiences with the three MV* offerings mentioned. Especially those that have experience with two or more.
Share this:Like this:Like Loading...
Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , ,
This entry was posted on December 28, 2013 at 10:00 and is filed under , , , , , .
You can follow any responses to this entry through the
You can , or
from your own site.
Connecting to %s
Follow &Binarymist&
Get every new post delivered to your Inbox.
Join 333 other followers
Send to Email Address
Your Email Address
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.
%d bloggers like this:利用 BackboneJS 更好的组织 jQuery 应用的架构 - 技术翻译 - 开源中国社区
当前访客身份：游客 [
已有文章 2351 篇
当前位置：
利用 BackboneJS 更好的组织 jQuery 应用的架构
英文原文：
0人收藏此文章,
推荐于 3年前 (共 48 段, 翻译完成于 11-12) ()
参与翻译(7人)：
, , , , , ,
在构建高交互度的Web应用程序方面，JavaScript发挥出越来越重要的作用。如Backbone.js，Marionette.js，Ember.js 和Angular.js 这些库和框架，在流行度和功能方面快速成长。对于建立复杂和强大的浏览器应用这件事，这些库和框架使之变得容易了。它们帮助我们迎来了一个单页应用时代（SPAs），使网页上的交互性和实用性达到了前所未有的程度。
但为了达到互动的目的，并不是每个Web应用程序或网站上的每个页面都需要通过SPA框架来创建。很多应用程序更适合于小规模的功能。对于这些页面，需要有一种高层次的交互性，同时又不需要客户端路由和其他的SPA功能属性。随着小页面在功能需求方面的减少，在创建页面时，将适当的框架和库的列表减少也顺理成章。例如，如果只是添加表单验证，你并不需要一个完整的MVC框架。要是不需要一个完整的SPA框架，而且有很好的理由的话，许多开发者编写代码时只会用到jQuery。而为了创建进一步的交互动作，可以很容易地通过 plug-ins 和add-ons扩展jQuery提供的交互性。
&翻译的不错哦!
在建造大型的jQuery应用时，所面临的困难之一是保持代码有条理。它很容易迷失于世界末日的一棵圣诞树——一个深层嵌套的回调函数列表，这个列表看起来似乎掌控着每一个功能和交互。事实上，对于代码的组织或结构，jQuery不提供任何指导。
好消息是，你不需要在jQuery和结构良好的代码之间做出选择，后者由SPA库和框架帮你书写。借助Backbone.js提供的结构良好的创建模块，你可以把基于jQuery应用的简单性和交互性结合起来，以便创建同样具有很好代码组织结构的高互动性的网页。
&翻译的不错哦!
什么是Backbone.js
Backbone.js是一个帮助开发者在Web应用程序中向Javascript代码添加架构的组件库。来自BackboneJS.org的描述是这样的：
“Backbone.js通过提供带有键值绑定的模型和定制的事件，带有枚举功能的丰富的集合API，带有声明式事件处理的视图，而且将它所有这些东西通过一个RESTful JSON接口连接到你现有的API上面，来向Web应用程序提供架构。
Backbone.js包含了提供不同组特定功能集合的构造块，包括：
Model：包含由键值对组成的属性的对象。Model封装了应用程序中的数据以及同数据相关的行为。
Collection：是一个模型的集合。Collection可以让相关模型的集合共同工作并且作为一个整体被管理。通用的集合特性诸如新增和移除，迭代，过滤等都有提供。
View：用于管理和操作DOM的通用方法集合与配置，并且显示来自Model和Collection的数据。View提供了使用jQuery DOM 事件的一种结构良好的方法，它们可以很容易的对HTML模板以及更多的其它东西进行渲染。
Event：它是对面向Javascript对象的观察者设计模式的一个小巧但强大的实现。事件将Backbone.js应用粘合在一起。Backbone.js中的每一个对象都包含事件系统，它让每一个Backbone.js对象都能触发事件并能得到处理。
Router和History：使用URL哈希片段或者HTML5的pushState技术来管理浏览器历史的对象集合。Router和History对象允许对一个应用程序的对象打上书签或者链接，重载页面的时候精确的回到上一次最后留下的样子。&&&&
&翻译的不错哦!
尽管Backbone.js有其它小的部分，但如果需要定制它们的时候，理解这些很重要。不过从一个高层次观察，对于大多数应用程序来说，这六个对象是最重要的。
这些 Backbone.js 单个部分之外，从模式与架构的视角，有一些关于如何称呼它的争论。
显然Backbone.js符合Model-View-* (MV*)模式家族。
毕竟它提供了一组对象，帮助你组织模型和视图。
但这并不完全符合MVC模式，或MVVM模式，或MVP，或别的什么。 称
Backbone.js为MV *家族的一个成员是最简单的。在此基础上
人们叫它什么并没有多大
&翻译的不错哦!
建立联系人列表
许多应用类型需要为他人存储和查询联系人信息，比如一个CRM系统，一个时间追踪应用，账单或者其他的一些东西。尽管联系人应用可能还没有最令人激动的特性集合，但它提供了一个使用高级交互性的很好的例子，但不需要成为SPA。
一个简单的联系人列表仅仅需要少量的特性：
联系人列表
添加联系人
编辑联系人
删除联系人
联系人数据
它也需要与这些特性相配的数据，包括：
在学习Backbone.js过程中使用的简单联系人列表仅仅需要处理一个单独的邮件地址和电话号码。在真正的应用中，你会想要允许多个电话号码和邮箱地址，但Backbone.js没有内建的嵌套或者分层的模型。这让处理多值或者嵌套对象和集合变得有些更具挑战性，尽管通过插件添加这项功能并不困难。一个简单的邮件地址和电话号码可以满足这个应用。
&翻译的不错哦!
这个应用的布局相对简单，可以如图片1和图片2的样子。只需要一个列表视图而且有一个表单来添加和编辑联系人。
图片 1: 这是添加联系人表单
图片2: 这是联系人列表例子。
当你点击添加按钮，表单将显现，并允许你添加一个新的联系人。点击保存将联系人信息发送到服务器。点击取消清除表单并隐藏表单。
在联系人列表中，点击编辑按钮可以显示同添加过程一样的样子，但是表单里将有存在的联系人信息。点击保存并发送编辑信息给服务器。保存还是用最新的信息来更新联系人列表。取消将抛弃任何改变并不会更新列表。
&翻译的不错哦!
一个API服务器
Backbone.js为数据提供一个如REST的API，并能和服务器端很好的交互。这个在很多语言中都能很容易的安装，包括Ruby on Rails、NodeJS、ASP.NET MVC(包括WebAPI)、Python Django和各种PHP框架等等。最重要的方面不是服务器使用的技术架构。当然，其重点是如REST的API并能提供各种资源。
Backbone.js是在Rails的世界中开发的，所以它的API使用起来如一个Rails生成的API。Backbone.js工作使用的每一个资源应该对应一个在Web服务器上的API，这个API可以接受和返回JSON，而且符合Rails URL和HTTP的约定动作。
&翻译的不错哦!
在某个联系人列表里，其API可能如下：
GET /contacts:返回所有联系人
POST /contacts: 从表单数据中创建一个新的联系人，其数据用JSON格式
GET /contacts/:id: 通过参数id得到指定联系人
PUT /contacts/:id: 通过得到表单传来的JSON格式数据来更新一个存在的联系人。通过id参数来标识更新的联系人
DELETE /contacts/:id: 通过指定id来删除联系人
这篇文章中构建联系人应用是一个技术而且对于服务器框架来说是未知的，直到服务器符合了基本API结构。至于你怎样才能实现服务器框架则完全取决于你。
&翻译的不错哦!
在为这个app准备的javascript中首先要做的，是处理新增按钮的点击。添加一个标准的jQuery DOMReady 回调函数，以确保DOM已经准备好并且可用了。然后，在DOMReady回调函数里面，添加一个找到#add元素的选择器还有对点击事件的侦听。在事件参数上调用preventDefault以确保按钮的点击不会传到服务器。
$(function(){
$("#add").click(function(e){
e.preventDefault();
showAddForm();
// other code will go here ...
在事件的回调函数里面制造了一个对showAddForm的调用，以展示添加表单。这个函数找到#add-edit-form元素，并且使用动画来展示它。
function showAddForm(){
var form = $("#add-edit-form");
form.slideDown();
} 接下来，为#save按钮的点击事件添加一个事件处理器。这个按钮存在于#add-edit-form里面，但它也可以通过ID被选择器找到。在点击处理器中，从表单中所有的输入元素中抓取数据并且将其发送到服务器以创建一个新的contact。当这些都做好以后，就用新的contact信息更新contact的列表，就像列表1所展示的那样。&
&翻译的不错哦!
当向服务的传送成功时，它会调用updateList和clearForm函数，它们会做你所希望做的事情（&简洁起见，这些断码从略）。
不需要完成这个简单应用的整个功能，你就能看明白现在代码能够很快的变成一揽子可用的功能挂在上面。这种结构松散的代码被相当典型的用在使用jQuery的小型页面上。几乎每一个Javascript和jQuery开发者都写过类似的代码，而这一风格由于其能让一些小型的任务得以完成，因此会持续流行下去。
编写结构良好的jQuery代码是可能的，当然，即使你使用了提供那种架构的框架或者库也可以。&&那会变得像是你在重复制造轮子，所以你应该专注于如何让业务运作起来。不要在构建基础架构上花时间，就使用模型，集合，视图和其他Backbone.js能够提供的类型，将你的应用程序迁移到这样一个更好的架构上，然后一步一个脚印。
&翻译的不错哦!
我记得外国有个教程很简短的 就讲完了 backbone.js
为啥这篇罗嗦了 这么多.}