Tag Archives: Angular.js

[repost ]Learn to build an application using Angular.js

original:http://campus.codeschool.com/courses/shaping-up-with-angular-js/

[repost ]Why I Chose Ember.js

original:http://ryantablada.com/post/why-i-chose-ember-js

Clarification This article has been edited to reflect time spent with each framework and a few other relevant facts

I have finally made the plunge to really dig into Ember.js. But, if you are familiar with the vast landscape of Javascript frameworks, you may wonder why I chose Ember.js. This isn’t a light decision and Ember.js is thought to have quite a steep learning curve. However, I think that there are some reasons behind this that I will cover in a later post.

So to start, let’s look at the various frameworks and my own relations to them in my track to eventually set upon Ember.js.

Backbone.js – 8 Months Experience

When looking at front-end frameworks, many first happen upon Backbone. However, I find that Backbone is more of a library than a framework. Think of it as a bit more structure than jQuery. But, it is far from an experience of being what MVC, Rails, Django, or Laravel are in the server.

Backbone is an incredible bit of kit for managing some light data binding but soon becomes hard to manage. The patterns that arise become, if you would pardon the pun, back-breaking. But, this being said, Backbone clearly has a use case in form validation where jQuery alone can become a bit awkward.

Marionette.js – ~4 Months Experience

Of you work on Backbone projects you quickly become tired of the boilerplate that is associated with Backbone apps. To answer this, Marionette was created to manage some of the common issues with Backbone. It is a valiant effort and live bindings definitely becomes more of a possibility with Marionette. But, after working with Marionette, there were things that were a bit awkward and there was always a good deal of boilerplate.

Working with Marionette was a nice improvement, but I felt that it was a bit bulky for the gains. Making full interactive sites was still strange. Marionette does a great deal to try and make Javascript web apps closer to server or desktop development, but it doesn’t quite make it all the way.

Ember.js – Take One 1 Month

My first experience with Ember.js was about six months ago, and it was a love hate relationship. Looking at the documentation and a few talks about Ember, I was really intrigued. It looked like it was as simple as many of the server-side frameworks in the way that it worked.

After trying to get started, it was pretty clear that Ember was more to take on than I had thought. There were version conflicts and huge API swings that made creating simple starter apps difficult. Since there were these large API changes, Ember tutorials were few and what was out there always seemed to conflict with newer conventions.

However, in trying to learn Ember for the first time, I had a few take aways. First, I really wanted it to work! From the demonstrations given by Tom and Yehuda I knew that Ember was going to be awesome, but it had a learning curve. Second, front-end frameworks needed tooling. While it is all well and good to write templates in the HTML rendering pages, this didn’t scale. And working for a CTO that made me write JST’s by hand made me sour to that idea as well. Third, I needed more examples outside of using rails. Ember still to this day has far too many tutorials saying “use serializer here” and “gem install ember-rails”.

Angular.js – 1-2 Weeks + Hackathon

It’s hard to mention a framework battle without mentioning Angular. It is the Google-backed uber framework for front-end development. However, after going through an introductory course, I found that while it was cool for making a live-markdown parser or a todo list, going beyond that felt like a whole foreign environment.

On top of this, Angular killed the idea of the DOM. Various ng-attribute references cluttered the page around and this was mixed with what is called “mustache-esque” template bindings. It was all quite confusing.

Beyond this, Angular seemed to use some type of Klingon for tasks that seemed quite common, and while I spent a good deal of time in University studying Computer Science, I rather don’t like trying to figure out directives, scope, or transclusions.

Even past then, Angular did not do well with nested resources which are quite common in my applications. I just didn’t figure out how you could have a shopping cart with many orders each with many items and yet keep all that from becoming an absolute mess. And to make things worse, I haven’t had first hand experience with this, but I hear that uglifying or minifying angular is a bit like the Aisle of Terror. Maybe I didn’t give Angular the time it required, but I’d rather go do something fun than sit around writing dissertations within my code.

Knockout.js – A few tutorials

My experience with Knockout.js is quite limited, this is just my quick opinions that made me shy away from it.

After looking around for more live-binding frameworks I found Knockout.js. Honestly, in my quick glance at Knockout, it seemed a bit like Angular lite. There were some things that I liked but I still found myself yelling at a framework that reinvented the wheel of templating and even said “you can substitute our version of handlebars with handlebars”. If you base your software off of another software then just go full tilt and use that (especially something as flexible as handlebars). This once again cluttered the DOM and had me scratching my head with what to do to move the files out of my markup and into separate template files.

All of this was only compounded by the fact that Knockout is really tightly coupled to .NET implementations. It’s so bad that Knockout users joke “oh I see you loaded Knockout, what version of MVC are your running”. Just stop! If your front-end framework won’t work with any server-side framework, go back to using turbolinks.

It should be noted that Knockout is able to work outside of .NET, from what I looked at, the community was extremely heavily weighted to .NET users as was the tooling available. This was a major con for me due to my limited access to .NET in order to compare what was going on in terms of server interaction.

Batman.js

Ok, honestly, I haven’t tried, looked at, or even coughed in the general direction of this framework. But… It’s called BATMAN so how could I not mention it! From the front page it looks a bit angular-ish with HTML5 compliant data attributes instead of of ng-garbage.

Ember.js – Take Two

Fast forward to a few weeks back and I was caught up in watching the Ember vs Angular cage match. Watching the video, I saw that Ember had solidified and was easier to start up than before. Listening to the Ember Hot Seat, by suspicions were confirmed: Ember was getting close to what we had dreamed about. To make things even better the tooling was light-years ahead of where it had been and started to become a bit more detached from the Rails Asset Pipeline. Things like Emberscript, Ember-Tools, and grunt tasks have made Ember much more framework agnostic.

So, I took it upon myself to really look at the documentation and work through the getting started guide. After finding a few kinks in the system, I soldiered on and then ported the Fixture (think DB seed data) to local storage and then to a RESTful client using Laravel as a backend. From there, I decided to really look at relational data as it was the final thing keeping me from really moving to a front-end framework. Sure enough, I looked at Ember Data’s relationships and they worked really solidly. So, now I have made the switch and have joined the Ember fan club.

Conclusion

In my experience, if you are creating heavy RESTful front-end apps, Ember is your framework. It cuts out almost all boiler plate and makes many convention based decisions for you. This cuts out on time when developing an app once you learn what Ember wants to do by default. What makes it even more powerful is the fact that the Ember Object Model makes the entire framework easy to modify.

However, when you are running smaller apps or widgets, I would suggest running regular Backbone. It gives you just enough abstraction around jQuery to make data binding and view based event handlers really easy. But if you find yourself reaching for Marionette or Chaplin, I’d seriously consider making the switch to Ember It’s just better to work with something that was built for the kind of work you were doing from the start instead of using an extension of Backbone.

I still would like to see more non-rails developers adopt Ember and share their experience. I think this will benefit the community as a whole and will start to demystify some of the complaints on HackerNews and the like.

In terms of spending time in other frameworks or “looking at X” again, while I wish I had the time to do so, every developer eventually needs to stop and just get work done. Ember filled the needs for many of my larger applications. I continue to keep my eyes out every few weeks to see how the landscape changes, but I am rather set for now.

[repost ]Angular.js VS. Ember.js:谁将成为Web开发的新宠?

original:http://www.admin10000.com/document/2858.html

本文源自于Quora网站的一个问题,作者称最近一直在为一个新的Rails项目寻找一个JavaScript框架,通过筛选,最终纠结于Angular.jsEmber.js

这个问题获得了大量的关注,并吸引到这两个框架的开发者参与回答。如果你也纠结JavaScript框架的选择,那么本文对你来说也是一个非常好的参考资料。

  Angular.js和Ember.js介绍

Angular.js是一款开源的JavaScript框架,由Google维护,其目标是增强基于Web应用,并带有MVC功能,使得开发和测试变得更加容易。

Angular.js读取包含附加自定义(标签属性)的HTML,遵从这些自定义属性中的指令,并将页面中的输入输出与由JavaScript变量表示的模型绑定起来。这些JavaScript变量的值可以手工设置,或者从静态或动态JSON资源中获取。

项目地址:http://angularjs.org/

Ember.js同样是一个用于创建web应用的JavaScript MVC 框架,其采用基于字符串的Handlebars模板,支持双向绑定、观察者模式、计算属性(依赖其他属性动态变化)、自动更新模板、路由控制、状态机等。

Ember.js使用自身扩展的类来创建Ember.js对象、数组、字符串、函数,提供大量方法与属性用于操作。每一个Ember.js应用都使用各自的命名空间,避免冲突。

项目地址:http://emberjs.com/

  Angular.js开发者:Angular.js最能体现HTML的精髓

Angular.js其中一位开发者Misko Hevery回复了提问者的疑问,内容如下。

我是Angular团队中的一名开发者,我还不太了解Emeber.js,因此我的观点可能会有些偏颇。

有人说,Angular.js和Ember.js都在HTML中放入了太多的逻辑。当然,将逻辑放入HTML是一个不好的做法,我们也不建议这么做。事实上,Angular.js只放置绑定,而不是逻辑,我们建议把逻辑放入控制器中。但绑定同样是信息,这些信息可以放在一些地方,你有三种选择:

  1. 代码。但这使得程序模块化很成问题,因为HTML与代码紧密耦合,要想重新组成一个应用程序非常困难。
  2. HTML。这正是Angular.js所做的。我们认为,除了放置连接信息外,你不应该在HTML中做任何事情。任何逻辑都不应该出现在这里,因为它会导致各种问题。我认为Angular.js做的绑定相当好。
  3. 元数据文件:虽然我不知道是否有人这样做,但基本上这是一个双重问题,因为你将不得不在代码中连接HTML位置和模型位置。

当然,在构建一个应用程序时,你也可以不使用框架,但不可否认,使用框架将使得你的开发工作变得更容易。

我个人认为Angular.js的独特之处在于它拥抱HTML/CSS,遵循“HTML是什么”的精神。其他一些框架提供了它们自己的API,偏离了HTML。Angular.js在所有框架中是最能体现声明式的。我相信声明式非常适合用来构建用户界面,而JS非常适合用来编写逻辑。

Angular.js允许你扩展HTML,所以你在使用Angular.js过程中遇到的任何问题都可以很容易地克服。你可以在Angular.js官网中http://angularjs.org找到一些能够展示其特性的例子。

  Ember.js开发者:Ember.js是构建“雄心勃勃”的应用程序的不二选择

Ember.js的一位开发者Tom Dale对Angular.js和Ember.js进行了详细对比,具体内容如下。

作为Ember.js的作者之一,我经常会被问道:应该使用Angular.js还是Ember.js?

我认为在做出选择之前,需要考虑:要构建什么样的应用?那么Ember.js是不是比Angular.js更好呢?

虽然两者在表面上有一些相似之处——它们都使用绑定,都比其他框架(比如Backbone.js)更有利于编写Web应用程序。

我首先来介绍一下Ember.js项目的由来。从2009年开始,我就一直在苹果公司参与SproutCore的开发,这是一个开源的类似于Cocoa的JavaScript框架,后来演变成了你现在所看到的iCloud。当时,我的周围是一些世界上最好的Cocoa开发者。

问题是,多少年来在客户端应用程序方面,似乎并没有真正新的突破。自80年代以来就一直遵循的基本模型——代码运行在本地计算机上,从网络上获取数据,然后在本地处理,并显示在屏幕上;而如今唯一改变的是——代码运行在浏览器的沙箱环境中,然后加载所需的“二进制”文件,而不是由用户安装到硬盘上的文件。

在考虑这些问题是,我会首先想到:在我们之前,人们已经做了什么?我认为很难去争辩框架的成功,比如Cocoa,无论在Mac还是iOS上,Cocoa都可以让开发者轻松编写受用户喜爱的应用程序。

我们希望开发者能够创建雄心勃勃的、能够与本地应用竞争的Web应用程序。要做到这一点,开发者首先需要先进的工具和正确的概念,以帮助他们沟通和协作。

在开发Ember.js过程中,我们花了大量时间从其他一些本地应用程序框架(如Cocoa)中引入一些概念,但后来我们感觉到这些概念带来的困扰多于帮助,或它们并不适合用来构建Web应用程序。因此,我们开始转向其他流行的开源项目,比如Ruby on Rails和Backbone.js,从它们中来找灵感。

因此,Ember.js最终成为了一个综合的、强大的、符合现代Web特性的、轻量级的工具。

在我看来,与Ember.js相比,Angular.js更像一个研究项目。比如,来看看它们的学习文档:Ember.js主要讨论模型、视图和控制器,而Angular.js指南要求你去学习一些类似于范围、指示符和transclusion方面的内容等。

我完全支持一些研究型项目,并希望它们能够变成最好的。但是,要记住,要在生产环境中看待应用程序。

一些大公司已经在Ember.js上投入了时间和精力,比如新版ZenDesk已经使用Ember.js重写(在他们对Backbone.js失望后,决定放弃它改用Ember.js),Square的整个Web层面也是基于Ember.js的(因为他们想要一个漂亮、响应式的UI),Groupon的移动版Web应用也是使用Ember.js开发的。此外,还有很多初创型公司通过Ember.js获得了成功,并开始对Ember.js社区进行贡献。

而我目前所看到使用Angular.js开发的大多数应用程序只是演示项目,或是Google的内部项目。

Yehuda(Ember.js开发者之一)和我也一直积极邀请真正的用户参与Ember.js框架的设计和维护,这可以确保我们在Ember.js中添加的功能对于实际开发是有用的。

事实上,在过去的几个月中,大多数Ember.js开发工作都是由Ember.js社区的核心贡献组完成的,他们来自不同的公司。如果Yehuda和我哪天有什么事情,或者我们的公司倒闭了,Ember.js还将会持续发展。这是一个真正的社区项目,而不是“Google”项目。

回到技术细节。Angular.js官网上写道“Angular.js是HTML的未来,它被设计用于构建Web应用程序。”我认为当看他们的应用程序时,这种理念是显而易见的——用户界面由HTML标记定义,使用有语义意义的属性(比如data-ng-repeat)来装饰。

而Ember.js使用Handlebars来描述HTML,来展现你的应用程序界面。从美观角度,我们可以谈谈你是更喜欢Handlebars语法(使用类似于{{#each}}的helper),还是喜欢像Angular.js那样通过额外的属性来注释HTML。我个人认为,HTML属性方法有点杂乱,难以阅读。当然,你可以使用其中任何一种方式。如果Ember.js不存在,而我又必须使用一个使用了数据属性的框架,那么我会考虑Angular.js。

抛开美观不谈,我相信,Ember.js使用基于字符串的模板的方式也为我们带来了一些优势:

  • 基于字符串的模板可以在服务器上预编译。这样可以减少启动时间,也意味着渲染一个模板可以像调用一个函数一样简单。
  • Angular.js需要你在应用程序启动时遍历整个DOM,你的应用程序越大,启动速度越慢。
  • 如果你想在服务器上渲染你的应用程序(用于Google爬虫索引或让首次加载时显示速度更快),Angular.js需要你去启动整个浏览器环境,像PhantomJS,这是资源密集型的。而Handlebars是100%的JavaScript字符串,所有你需要的只是像node.js或Rhino之类的东西。
  • 如果你的应用程序变得越来越大,那么字符串模板可以很容易地被分割和懒加载。

此外,Handlebars只让你绑定属性,而Angular.js允许你嵌入实时更新的任意表达式。很多人最初将这个视为Ember.js的局限性,但实际上:

  • Ember.js允许非常容易地使用JavaScript来创建可计算属性,它可以包含任意表达式。我们只要求你指定你的依赖,这样在更新时可以智能些。
  • Angular.js在每次有新的变化时,必须重新计算这些表达式,这意味着需要在你的应用程序中绑定更多的元素,速度会变慢。
  • 因为Ember.js只允许你绑定属性,我们将可以很容易地利用ECMAScript 6的性能优势,如Object.observes。由于Angular.js发明了自己的带有自定义解析器的JavaScript子集,这对于浏览器来说,优化代码变得比较困难。

在一般情况下,Angular.js依靠一种叫做“脏检查(dirty checking)”的机制来确定对象是否已进行更改。“脏检查”的方式是,在你扫描每个对象和其所有绑定属性时,比较当前值和之前已知的值。如果它发生了变化,你就需要去更新其绑定。正如你能想到的那样,代码中对象越多,成本将越昂贵。

但Angular.js开发者非常聪明,他们非常仔细地进行了折中。他们的方案是:

  • 使用“脏检查”,你不需要使用accessors。你可以用person.name = “Bill”来代替person.set(‘name’, “Bill”),就像在Ember.js 或 Backbone.js中的一样。
  • 为什么在DOM中你会有这么多的对象?这最终将会成为一个瓶颈的。

Miško Hevery在StackOverflow上介绍了这种折中方式。他指出,使用“脏检查”,你无法一次有超过2000个绑定对象。

我认为这很好地说明了Ember.js 和 Angular.js理念上的区别。Ember.js 和 Angular.js都力求简单和易用。而Ember.js使你不必担心代码中是否有超过2000个绑定。如果你正在编写大型应用程序,那么你已经解决了你所担心的最大的事情。对于中小规模的应用程序来说,Angular.js同样是伟大的,因为这些应用程序不会触及Angular.js的限制区。

在Ember.js中,我们总是希望利用浏览器和语言中的新功能,以便使事情变得更容易。例如,一旦ES6中代理对象(proxies)可用,我们不会再要求你使用get()和set()。

所以这就是为什么我认为——如果你想构建雄心勃勃的应用程序,你应该选择Ember.js。

我们从不拒绝从其他一些框架中吸取一些知识,因为这些框架已经知道如何最好地去构建大型应用程序。

我们已经有了一个梦幻般的社区,有一群最聪明的Web开发人员,他们致力于解决现实中遇到的最难的一些问题。

此外,在开发过程中,我们对于性能方面和如何利用语言新特性方面也考虑了很久。Yehuda Katz和我一起开发Ember.js,他同时也是TC39(负责JavaScript下一个版本的制定)的成员,在此方面相当有经验。

我们已经发布了1.0版API,因此你可以开始学习,而不用担心有大的变化。

你可以通过这个视频来了解如何通过Ember.js从头开始构建一个应用程序:Building an App with Ember.js

下面是一些非常棒的学习资源:

如果你想构建一个雄心勃勃的应用程序,你一定要考虑Ember.js。

  angularjs_scaffold开发者:Angular.js符合Web的未来

angularjs_scaffold的开发者Patrick Aljord也参与了讨论,内容如下。

我是angularjs_scaffold(基于Angular.js编写的针对scaffolding视图的Rails插件)的开发者,我来说说为什么我会选择Angular.js。

事实上,我原本打算在项目中使用Ember.js,因为我比较信赖Yehuda(Ember.js开发者之一)在Rails和jQuery方面的工作。但是Ember.js中随时会变化的API和匮乏的文档,使我一再推迟使用它。我偶然发现了Angular.js,就被它吸引了。

像Tom Dale(Ember.js开发者之一)所说,Ember.js受Cocoa 和Rails启发。但问题是,通过Ember.js,我并没有真正感觉到像在写一个Web应用程序,它就像一堆抛出的概念。而在Angular.js中,我感觉像在写一个Web应用程序,它真正支持所有的Web概念,并以一种非常自然的方式来扩展HTML。

事实上,Angular.js并没有使用自己的对象或重写JS方法,当你使用Angular.js时,你就使用了纯JS,并且Angular.js实现的许多概念都将直接进入下一个版本的Javascript中。

学习Angular.js,就意味着学习未来的Javascript,而学习Ember.js,你只是学习到了Ember的特定概念。

来看个例子。HTML是伟大的,因为它是声明式的,如果想要定义一个段落,你只需写如下代码:

1
<p>Hello world</p>

但是如果你想非常动态地实现?你需要通过类似于下面的代码来引导浏览器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<p id="greeting1"></p>
 <script>
  var isIE = document.attachEvent;
  var addListener = isIE
  ? function(e, t, fn) {
  e.attachEvent('on' + t, fn);}
  : function(e, t, fn) {
  e.addEventListener(t, fn, false);};
  addListener(document, 'load', function(){
  var greeting = document.getElementById('greeting1');
  if (isIE) {
  greeting.innerText = 'Hello World!';
  } else {
  greeting.textContent = 'Hello World!';
  }
  });
 </script>

来看看Angular.js如何实现:

1
<p>{{hello}}</p>

它通过HTML声明来编写动态代码。再来看一个示例,如果你要遍历一个数组,只需:

1
2
3
4
5
<ul>
  <li ng-repeat="element in array">element</li>
</ul>

这个语法看起来像新的MDV标准。这看起来比Ember.js更加简洁。另外,Angular.js被优化得非常快,开发团队通过如下措施来实现:

  • 脏检查
  • 只检查当前视图
  • 只在变化发生时检查
  • 通过和Chrome团队协作来利用JIT

在一些基准测试中,结果显示Angular.js的速度要快于Ember.js,具体可见Angular VS Knockout VS Ember

Angular.js未来会拥有可重用的组件,这允许你编写非常简洁的代码,并轻松重用一些部件。这不是Angular.js特定的需求,而是Web的未来。

此外,Angular.js还拥有一个庞大的社区和大量的贡献者

  原帖中还有很多开发者也参与了讨论,详细内容:Is Angular.js or Ember.js the better choice for Javascript frameworks?