在线课堂 - 汇智网我为什么选择 Angular 2？ - WEB前端 - 伯乐在线
& 我为什么选择 Angular 2？
没有选择是痛苦的，有太多的选择却更加痛苦。而后者正是目前前端领域的真实写照。新的框架层出不穷： 它难吗？它写得快吗？可维护性怎样？运行性能如何？社区如何？前景怎样？好就业吗？好招人吗？组建团队容易吗？
每一个框架都得评估数不清的问题，直到耗光你的精力。这种困境，被称为“布利丹的驴子” —— 一只 驴子站在两堆看似完全相同的干草堆中间，不知道如何选择，最终饿死了。
当然，那只是一个哲学寓言。现实中，大多数人采用了很简单的策略来破解它：跟风，选择目前最流行的那个。这是一个低成本高收益的策略， 不过也有风险：成为现实版的《猴子下山》。最理想的方案还是要看出这两堆“干草”之间的差异，选择更适合自己的那个。
本文就将带你了解Angular 2这个“干草堆”的各种细节。
ALL-IN-ONE
不管是1还是2，Angular最显著的特征就是其整合性。它是由单一项目组常年开发维护的一体化框架， 涵盖了M、V、C/VM等各个层面，不需要组合、评估其它技术就能完成大部分前端开发任务。 这样可以有效降低决策成本，提高决策速度，对需要快速起步的团队是非常有帮助的。
让我们换一种问法吧：你想用乐高搭一个客厅，还是买宜家套装？
Angular 2就是前端开发领域的“宜家套装”，它经过精心的前期设计，涵盖了开发的各个层面，层与层之间都经过了精心调适， 是一个“开箱即用”的框架。
当然，你可能还记着Angular 1带给你的那些快乐以及……痛苦。这是有历史原因的。由于它是从一个用来做原型的框架演化而来的， 加上诞生时间很早(2009年，作为对比，jQuery诞生于2006年)，生态不完善，连模块化机制都得自己实现 （这就是angular.module的由来，也是Angular 2中抛弃它的理由）。在长达七年的演化过程中，各种进化的遗迹非常明显，留下了不少“阑尾”。
但Angular 2就不同了，它的起点更高，整合了现代前端的各种先进理念，在框架、文档、工具等各个层面提供了全方位的支持。 比如它的“组件样式”能让你在无需了解CSS Module的前提下获得CSS Module的好处，它的Starter工程能让你在无需了解Webpack的 前提下获得Hot Module Replacement等先进特性，它能让你从Web Worker(你知道这是什么吗？)中获得显著的性能提升。
你只管在前台秀肌肉吧！剩下的，让Angular在幕后帮你搞定！
逃离“版本地狱”
如果是一两个人开发一个预期寿命不到一年的系统，那么任何框架都可以胜任。但，现实中我们都把这种系统称之为“坑”。 作为一个高度专业、高度工程化的开发组，我们不能把“坑”留给友军。这些坑中，最明显的就是“版本地狱”。
想象一下，你仅仅升级了库的小版本号，原来的软件就不能用了，损坏了N处单元测试以及M个E2E场景。 这种情况对于开发组来说简直是一个噩梦 —— 毕竟，谁也不想做无用功，更何况是一而再、再而三的。 或者，它每次小的改动都会修改大版本号 —— 对，我就是不向后兼容，你能咋地？你所能做的就是每一次决定升级都如临大敌， 不但要小心翼翼的升级这个库本身还要升级与它协作的几乎所有库。
可见，乱标版本号可能会让使用者付出巨大的代价。这不但体现在工作量上，还会体现在研发团队的招募与培养上，想象一下， 对小版本之间都不兼容的框架，研发团队都需要记住多少东西？那简直是噩梦！
但是，版本号的问题在业内早就有了事实性标准，那就是SemVer语义化版本标准。 唯一的问题是，作为框架/库的作者，遵循SemVer标准需要付出的努力是巨大的。是否愿意付出这些代价， 是一个框架(及其开发组)是否成熟的重要标志。
Angular就是这样一个框架，其开发组曾作出的努力是有目共睹的。如果你是从Angular 1.2开始使用的，那么你为1.2所写的代码 都可以毫无障碍的迁移到最新的1.5版，新的版本只是引入了新特性，而没有破坏老特性。 这是因为Angular开发组写了大量单元测试和E2E测试，借助CI来保障这种平滑过渡。只有在从1.0到1.2的迁移过程中(1.1一直是beta，忽略不计)， 出现了一系列破坏性变更，这些变更被明确的记录在文档中，并且解释了做出这些变更的理由 —— 大多数是因为提升前端代码安全性。 即使你恰好遇到了这些破坏性变更，它也会给出明确的错误提示。
这些必要而无聊的工作，正是帮助我们逃离“版本地狱”的关键。是否愿意做这些无聊而琐碎的工作，是一个框架的开发组是否成熟、专业的关键特征。
模块化的技术
虽然Angular是一个ALL-IN-ONE的框架，但这并不妨碍它同时是一个灵活的框架。还记得OCP(开闭原则)吗？ 一个好的设计，对扩展应该是开放的，对修改应该是关闭的。
Angular 2很好的践行了OCP原则以及SoC(关注点分离)原则。
它非常有效的分离了渲染与交互逻辑，这就让它可以很好的跟 包括React在内的渲染引擎搭配使用，除此之外，它还可以使用内存渲染引擎，以实现服务端渲染；还可以使用Native渲染引擎， 以编译出真正的原生程序(NativeScript)。
它还分离了数据供应与变更检测逻辑，从而让它可以自由使用包括RxJS以及ImmutableJS在内的第三方数据框架/工具。
不仅如此。
在Angular 1和Angular 2中最具特色的应该算是依赖注入(DI)系统了，它把后端开发中用来解决复杂问题、实现高弹 性设计的DI技术引入了前端。Angular 2中更是通过引入TypeScript赋予它更高的灵活性和便利性。
不过，Angular 2并没有敝帚自珍，把它跟框架本身紧紧黏结在一起，而是把它设计成了一个独立可用的模块。 这就意味着，无论你正在使用什么前端框架，甚至NodeJS后端框架，都可以自由使用它，并从中获益。
开放的心态
当年的浏览器大战，让人记忆犹新，Chrome的出品商Google和IE的出品商微软正是浏览器大战的两大主角。
俗话说：没有永远的朋友，也没有永远的敌人，只有永远的…… 精益求精。
正是在这样的“俗话”指导下，Google与微软相逢一笑泯恩仇，撤销了很多针对彼此的诉讼，甚至在一些领域开始合作。 而实际上，在他们公开和解之前，就已经开始公开合作了，其契机就是Angular 2。
这就要扯出一点小八卦了。
在Angular 2开发的早期阶段，由于传统JS(ES5)以及当时的ES6草案无法满足项目组的开发需求，项目组有点烦。 后来有人灵机一动开发了一种叫做AtScript的新语言，它是什么呢？一个带类型支持和Annotation支持的升级版JS。 其实在类型支持方面，TypeScript早就已经做了，而且那时候已经比较成熟，唯一的遗憾是不支持Annotation， 也就是像Java中那样通过@符号定义元数据的方式。
Angular开发组就这样孤独的走过了一小段儿时间，后来也不知道怎么这两个欢喜冤家就公然牵手了。 总之，最后的结果是：TypeScript中加入了Annotation特性，而Angular放弃了AtScript改用TypeScript。
这次结合无论对两大厂商还是对各自的粉丝，都是一个皆大欢喜的结局，称其为世纪联手也不为过。 此后，Google与微软不再止于暗送秋波，而是开始了一系列秀恩爱的动作。无论如何，对于开发者来说，这都是一个好消息。
软粉们可能还记得在6.1的微软开发者大会上，微软曾公开提及Angular 2。事实上，TypeScript目前虽然已经相当完备，但应用度仍然不高。 就个人感觉来说，Angular 2将是TypeScript的一个杀手级应用。TypeScript如果当选TIOBE年度语言，Angular 2的推出功不可没。
为什么我要特意插播这段儿故事呢？那是因为我认为一个产品的未来最终取决于开发组的未来，而不是相反。 软件的本质是人！一个心态开放、讲究合作、勇于打破陈规陋习的开发组，才是框架给人信心的根本保障。
全生命周期支持
除非你打算写一个一次性的代码，否则软件的生命周期会很长。宏观来看，真正的挑战来自多个方面，而且在不断变化。 开始的阶段，我们需要非常快速的建立原型，让它跑起来，引入最终用户来试用，这个时候，挑战来自开发速度以及可复用资产。
之后，会建立一个逐渐扩大的项目组，来完善这个原型的功能。主要的挑战是让这个原型通过重构不断进行演化， 特别是在演化的后半个阶段，产品需要保持随时可以上线的状态。但技术上的挑战那都不是事儿！关键是人。
如何让新人快速融入项目组，贡献生产力？这可没那么简单。“你先去学xxx 0.5、yyy 0.9、zzz 5.3… 还要了解它们前后版本之间的差异，我再给你讲代码”，这种话，我可说不出口。 一个优秀的框架需要对分工提供良好的支持，每个人都可以先从一些简单任务开始，逐步的从修改一个文件扩大到修改一个目录再到独立实现一个特性。
有了这种分工，每个团队成员就可以从一个成功走向一个更大的成功。这就需要框架在设计上具有良好的局部性： 你可以放心大胆的修改一部分，而不用担心影响另一部分。你可以只修改CSS，可以只修改HTML，可以只修改TS/JS， 而不用担心自己的修改破坏了其他部分。而Angular 2通过声明式界面、组件样式以及独立模板文件等对这种安全感提供了有力的保障。
再然后，如果你的软件顺利的进入了线上维护阶段，那么恭喜你，你终于迎来真正的大Boss了！这个大Boss就是可维护性。 Angular开发组有很多程序员来自Google，如果要问谁的软件维护经验最丰富，Google和微软必然位列其中。 微软通过TypeScript的强类型机制体现了自己的经验，而Google则通过将OCP、SoC、SRP等一系列软件设计原则融入Angular体现了自己的经验。 具体技术上则体现为：DI、生命周期钩子、组件等等。
最后，如果你的软件完成了历史使命需要逐步退出，是不是就能松口气了？不行，你还得继续留人维护它。 如果你选择的是一个闭源的或某个社区很羸弱的开源技术，你就把以前的主力架构师、资深程序员留下来继续维护它吧。 或者你就得鼓起勇气跟用户说：你们玩儿，我先走了。而Angular是一个大型开源项目，并得到了Google的鼎力支持。 即使经历过Angular 2项目组初期的公关失败，它仍然有着其它竞品无法企及的繁荣社区 —— 无论在全球还是在中国。 显然，无论是对传统社区资源的继承，还是对新社区资源的开拓，我们都有理由相信，Angular社区仍将一如既往地繁荣。 至少，如果你不想让自己的软件建立在一大堆由个人维护的核心库上，那么Angular毫无疑问是最好的选择。
遇见未来的标准
编程领域，创新无处不在。但对一个工程团队来说，最难得的是标准。标准意味着：
招人容易。因为标准的东西会的人最多，而且人们愿意学它 —— 因为知道学了就不会浪费。
养人容易。因为网上有很多教程可用，即使不得已自己做教程，性价比也是最高的。
换人容易。标准就意味着不是私有技术，一个人离开了，就能用另一个人补上，而不会出现长期空缺，影响业务。
但是，标准永远会比创新慢一拍或N拍。这就意味着如果你追新，那么在获得技术上的收益的同时，也要付出工程上的代价。 固然，两者不可兼得，但是还是有一些策略能够调和两者的。最简单的策略就是：遇见未来的标准。
所谓未来的标准，就是某个标准的草案，它很有希望成为未来的标准，这代表了行业对某项技术的认可，于是，即使它还不成熟，人们也愿意为之投资。 比如虽然Google曾经提出过N种自有技术，包括SPDY、Gears、OGG等，但却并没有把它们变成私有技术，而是对社区开放以及并入W3C的标准草案。
Angular 2采用的就是这种策略。它所参照的标准草案比较多，一个是WebWorker，它借助WebWorker来把繁重的计算工作移入辅助线程， 让界面线程不受影响；另一个是WebComponents，Angular 2的组件化体系就是对WebComponents的一种实现；最后是CSS scoping， 现在虽然市面上有了很多CSS模块化技术，但事实上最终还是会被统一到CSS Scoping标准上， 届时，如果:local等关键字无法进入标准，就会成为私有技术。而Angular 2选择的方式是直接实现CSS scoping标准草案， 比如:host伪类、:host-context伪类等。 显然，采用这种策略，“遇见未来的标准”的成功率会高得多。
可以看到，Angular 2的设计哲学中贯穿着对标准化的热烈拥抱，这是我判断它将赢得未来的另一个信心来源。
速度与激情
Angular 2终于摆脱了旧的技术框架束缚，开始了对速度的极致追求。在Angular 1中，虽然绝大多数场景下性能都不是问题， 不过还是因为其代码中存在的一个用来实现脏检查的三重循环而饱受抨击 —— 似乎真有人能感受到30毫秒和100毫秒的差异似的。
不过，有软肋总是不太好。于是，在Angular 2中，通过重新设计和引入新技术，从原理上对速度进行了提升， 据官方以前提供的一个数据说是把“变更检测”的效率提升了500%。
它在“变更检测”算法上做了两项主要的改进：
在设计上，把以前的“多轮检查、直到稳定”策略改成了“一轮检查、直接稳定”策略。 当然，这会对自己的代码产生一定的限制，但实际上只在有限的少数几个场景下才会遇到这个限制，而且官方文档中也给出了明确的提示。
在实现上，把“变更检测”算法移入了由WebWorker创建的辅助线程中执行。 现代的家用电脑基本都已经是多核超线程的，但是浏览网页时实际上无法充分利用全部线程，而WebWorker提供了一个全新的机制， 让一些相对繁重的计算工作运行在辅助线程中，等执行完了再通知主线程。即使你不明白WebWorker的工作原理， 至少也能知道Ajax请求是不会阻塞界面响应的，WebWorker也一样。
除此之外，Angular还对数据源进行了抽象，你完全可以用ImmutableJS来作为Angular的数据源，获得其在提升“变更检测”速度方面的所有优势。
除了“变更检测”外，Angular以及所有前端SPA程序，都有一个通病：首次加载太慢，要下载完所有js和css才能渲染出完整的界面来。 React通过虚拟DOM解决了此问题，而Angular 2则通过独立的服务端渲染引擎解决了这个问题。 我们前面说过，Angular 2把渲染引擎独立了出来，因此可以在NodeJS中实现服务端的内存渲染。 所谓内存渲染就是在内存中把DOM结构渲染出来并发回给浏览器，这样，客户端不需要等JS代码下载完就可以显示出完整的界面了。 这种分离还带来了另一个好处，那就是SEO。SEO同样是传统SPA的一个难点，它和服务端渲染是同一个问题的两个方面， 因此随着服务端渲染的完成，SEO问题也被顺便解决了。
让你无缝升级
Angular 2开发组在早期阶段曾犯下一个严重的公关错误：过早宣布不兼容Angular 1，也不提供从Angular 1到2的升级方案。
这让Angular 2开发组付出了沉重的代价，可谓伤透了粉丝的心。作为技术人员，这种失误固然是可以理解的，但却需要付出更多的努力来弥补它。 而Angular 2确实这么做了。
在Angular 2中，开发组提供了一个UpgradeAdapter类，这个升级适配器让Angular 1.x的所有部件都能和Angular 2.x中的所有部件协同工作。
而最牛的地方在于，它让你可以一个文件一个文件的逐步升级到Angular 2，而在整个升级过程中，应用可以继续在线上跑！看着神奇吗？ 其实也算不了啥，Google做这种事早就是轻车熟路了。这只不过是对Angular开发组出色的工程化开发能力的一点小小证明而已。
不过，既然如此，当初又何必急匆匆宣布不兼容呢？可见， 再出色的工程团队，如果缺少了和社区沟通的产品运营技巧，也会付出巨大代价。希望Angular开发组以后能谨言慎行，多用行动来平息质疑。
后面我还会有专门的文章以亲历者的视角讲述这个故事。
关于作者：
可能感兴趣的话题
关于伯乐前端
伯乐前端分享Web前端开发，包括JavaScript，CSS和HTML5开发技术，前端相关的行业动态。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线Angular 2五分钟快速教程 - 简书
Angular 2五分钟快速教程
让我们从零开始用JavaScript创建一个Angular 2应用。（教程同时也有TypeScript版和Dart版。）
看一下运行效果
运行是最快的看Angular 2应用演示的方法。点击链接会打开浏览器，载入,并显示一个消息。
Paste_Image.png
下面是文件结构
angular2-quickstart
L------app
L------ponent.js
L------boot.js
L------index.html
L------license.md
从功能上说，它就是一个index.html文件和app/文件夹下的两个JavaScript文件。我们完全可以搞定。当然我们也不会构建许多只能在plunker运行的应用的。让我们跟随一个实际中的流程。
搭建开发环境
写我们的应用的Angular根组件
启动它控制主页面
书写主页面(index.html)
如果我们按照下面的步骤，忽略解释，我们完全可以在5分钟内构建Quickstart这个应用。但大多数人还是对why和how比较感兴趣的，这个会多花一些时间。
我们需要一个立足之地（应用的项目文件夹），一些库还有一个编辑器。
创建一个项目文件夹
mkdir angular2-quickstart
angular2-quickstart
添加我们需要的库文件
我们推荐使用npm包管理器来获取和管理我们的开发库。添加一个package.json文件到项目文件夹。
package.json
"name": "angular2-quickstart",
"version": "1.0.0",
"scripts": {
"start": "npm run lite",
"lite": "lite-server"
"license": "ISC",
"dependencies": {
"angular2": "2.0.0-beta.0",
"systemjs": "0.19.6",
"es6-promise": "^3.0.2",
"es6-shim": "^0.33.3",
"reflect-metadata": "0.1.2",
"rxjs": "5.0.0-beta.0",
"zone.js": "0.5.10"
"devDependencies": {
"lite-server": "^1.3.1"
想详细了解？看下面附录的解释。
通过npm install命令安装所有包。遇到红色的出错信息直接忽略，安装会成功的。详细看附录。
我们的第一个Angular组件
组件是最基本的Angular概念。一个组件管理一个视图（视图也就是我们向用户展示信息并对用户反馈作出回应的一块网页）从技术上讲，组件就是一个控制视图模板的类。在创建Angular应用的时候，我们会写许多组件。这是我们第一次尝试，很简单。
创建一个应用源码子文件夹
我们要把我们的应用代码放到根目录下的app/子文件夹中。执行下面的命令：
添加组建文件
添加一个名为ponent.js的文件:
(function(app) {
app.AppComponent =
selector: 'my-app',
template: '&h1&My First Angular 2 App&/h1&'
constructor: function() {}
})(window.app || (window.app = {}));
我们通过链式调用全局Angular core命名空间ng.core中的Component和Class方法创建了一个名为AppComponent的可视化组件。
ponent.js (component schema)
app.AppComponent =
Component方法接受一个包含两个属性的配置对象；Class方法是我们实现组件本身的地方，在Class方法中我们给组件添加属性和方法，它们会绑定到相应的视图和行为。
Angular应用都是模块化的。包含的每个文件都有相应的功能。ES5没有内置的模块化系统。但第三方提供的模块系统有几个可以使用。但是，为了简单并免于为选择纠结，我们会为我们的应用创建一个单独全局命名空间。我们把它命名为app，并且会把所有的代码包都添加到这个全局对象上。我们不想用任何东西污染全局命名空间。因此在每个文件内我们都把代码包裹在一个IIFE（立即执行函数表达式）中。
ponent.js (IIFE)
(function(app) {
})(window.app || (window.app = {}));
我们将全局app命名空间对象传入IIFE中，如果不存在就用一个空对象初始化它。大部分应用文件通过在app命名空间上添加东西来输出代码，我们在ponent.js文件中输出了AppComponent。
ponent.js (export)
app.AppComponent =
一个更加复杂的应用会有以树形结构继承自AppComponent的子组件。一个更加复杂的应用会有更多文件和模块，至少和它的组件数一样多。Quickstart并不复杂，我们只需要一个组件。然而即使在这么小的应用中模块依然扮演一个组织角色。模块依赖其他模块。在JavaScript Angular应用中，当我们需要其他组件提供的一些东西时，我们从app对象中获取它。当其他组件需要引用AppComponent，它用下面方法从app.AppComponent获取。
app/boot.js (import)
ng.platform.browser.bootstrap(app.AppComponent);
Angular也是模块化的，它是一个库模块集合。每一个库本身就是一个由多个相关功能模块构成的模块。当我们需要Angular的东西时，我们使用ng对象。
Class定义对象
文件底部是一个空的AppComponent的类定义对象。当我们要创建一个是有实际意义的应用时，我们可以使用属性和应用逻辑来扩展这个对象。我们的AppComponent类只有一个空的构造函数，因为在Quickstart这个例子中我们不需要它做什么。
<ponent.js (class)
constructor: function() {}
Component定义对象
ponent()告诉Angular这个类定义对象是一个Angular组件。传递给ponent()的配置对象有两个字段：selector和template。
<ponent.js (component)
selector: 'my-app',
template: '&h1&My First Angular 2 App&/h1&'
selector为一个宿主HTML元素定义了一个简单的CSS选择器my-app。当Angular在宿主HTML中遇到一个my-啊、pp元素时它创建并显示一个AppComponent实例。
一定要记住my-app选择器，我们在创建index.html时需要这个信息。
template属性容纳着组建的模板。一个模板以HTML的形式告诉Angular如何渲染一个视图。我们的模板是一行显示“My First Angular App”的HTML代码。现在我们需要一些东西告诉Angular来加载这个组件。
给app/文件夹中添加一个新文件boot.js
app/boot.js
(function(app) {
document.addEventListener('DOMContentLoaded', function() {
ng.platform.browser.bootstrap(app.AppComponent);
})(window.app || (window.app = {}));
我们需要两件东西来启动应用。
Angular的browser bootstrap函数
我们刚刚写的应用根组件
我们把他们都放到我们的命名空间下。然后调用bootstrap，将根组件类型AppComponent作为参数传进去。
在下面的附录中学习为什么我们需要ng.platform.browser的bootstrap方法以及为什么我们要创建一个单独的boot.js文件。
我们已经让Angular在浏览器中用我们在根部的组件启动应用了。Angular会把它放到哪里呢？
添加index.html
Angular在我们的index.html上的特定位置显示我们的应用。现在是创建它的时候了。
index.html
&title&Angular 2 QuickStart&/title&
&!-- 1. Load libraries --&
&!-- IE required polyfill --&
&script src="node_modules/es6-shim/es6-shim.min.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-polyfills.js"&&/script&
&script src="node_modules/rxjs/bundles/Rx.umd.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-all.umd.js"&&/script&
&!-- 2. Load our 'modules' --&
&script src='ponent.js'&&/script&
&script src='app/boot.js'&&/script&
&!-- 3. Display the application --&
&my-app&Loading...&/my-app&
以上代码有3部分值得注意：
载入我们需要的JavaScript库；在下面学习它们。
载入我们自己的JavaScript文件，注意它们的顺序（boot.js需要ponent.js文件在前面）。
我们在&body&标签中添加&my-app&标签。这就是我们的应用生活的地方。
当Angular在boot.js中调用bootstrap函数时，它读取AppComponent的元数据，找到my-app选择器，定位到一个名字为my-app的元素，然后再这个标签之间载入我们的应用。
打开一个终端，输入以下命令
这个命令运行了一个叫做lite-server的静态服务器。它在浏览器中加载index.html页面并在应用文件改变时刷新浏览器。
稍等片刻，浏览器标签就会打开并显示
Paste_Image.png
恭喜！我们已经上手了。
如果你看到显示的是Loading...查看一下浏览器ES2015支持附录。
做一些改变
试着将消息改成“我的第二个Angular 2应用”。lite-server一直在监听，因此它会知道这个改变，并刷新浏览器，然后显示修改后的消息。这是一个有趣的开发应用的方法。结束后关掉终端窗口就关掉了服务器。
我们最终的文件结构是这样的：
angular2-quickstart
L------node_modules
L------app
L------ponent.js
L------boot.js
L------index.html
L------package.json
下面是对应的文件代码。
(function(app) {
app.AppComponent =
selector: 'my-app',
template: '&h1&My First Angular 2 App&/h1&'
constructor: function() {}
})(window.app || (window.app = {}));
app/boot.js
(function(app) {
document.addEventListener('DOMContentLoaded', function() {
ng.platform.browser.bootstrap(app.AppComponent);
})(window.app || (window.app = {}));
index.html
&title&Angular 2 QuickStart&/title&
&!-- 1. Load libraries --&
&!-- IE required polyfill --&
&script src="node_modules/es6-shim/es6-shim.min.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-polyfills.js"&&/script&
&script src="node_modules/rxjs/bundles/Rx.umd.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-all.umd.js"&&/script&
&!-- 2. Load our 'modules' --&
&script src='ponent.js'&&/script&
&script src='app/boot.js'&&/script&
&!-- 3. Display the application --&
&my-app&Loading...&/my-app&
package.json
"name": "angular2-quickstart",
"version": "1.0.0",
"scripts": {
"start": "npm run lite",
"lite": "lite-server"
"license": "ISC",
"dependencies": {
"angular2": "2.0.0-beta.0",
"systemjs": "0.19.6",
"es6-promise": "^3.0.2",
"es6-shim": "^0.33.3",
"reflect-metadata": "0.1.2",
"rxjs": "5.0.0-beta.0",
"zone.js": "0.5.10"
"devDependencies": {
"lite-server": "^1.3.1"
我们的第一个应用并没有做太多事情。它基本上就是Angular 2版本的“Hello World”。我们在第一次尝试中尽量简单：我们写了一个小Angular组件，向index.html添加一些JavaScript库，并启动一个静态文件服务器。这就是我们对一个“Hello World”的期望吧。我们有更远大的目标。好消息是我们已经入门了。我们可能仅仅碰了一下package.json文件来更新库。添加我们的应用模块文件之后，我们仅仅在需要添加库和样式表时打开index.html。我们要进行下一步学习，并使用Angular 2创建一个有很棒功能的小应用。加入我们的英雄教程之旅吧！
附录的作用就是对上面一些简单略过的点详细讲解。这里没有必要的资料。如果好奇可以往下看。
我们载入下面的脚本：
index.html
&!-- IE required polyfill --&
&script src="node_modules/es6-shim/es6-shim.min.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-polyfills.js"&&/script&
&script src="node_modules/rxjs/bundles/Rx.umd.js"&&/script&
&script src="node_modules/angular2/bundles/angular2-all.umd.js"&&/script&
我们首先载入了一个IE polyfill。IE需要一个polyfill来运行那些依赖ES2015 promise和动态模块加载的应用。大部分应用都需要这些功能，而且大部分应用都能在IE中运行。然后是Angular 2的polyfill，angular2-polyfills.js，再然后是Reactive Extensions RxJS库。
我们的Quickstart并不使用Reactive Extensions，但后面的实用的应用要用到它。所以我们提前加入。
最后我们加载Angular 2的网络开发版本。当我们经验丰富并对加载时间内存使用等产品性能比较关注时我们可以选择不同的库。
附录：package.json
npm是一个流行的包管理器，Angular应用开发者依靠它来获取和关系应用需要的库。我们在一个npm package.json文件中指明我们需要的包。Angular团队建议我们使用在dependencies和devDependencies部分列出的包。
package.json (dependencies)
"dependencies": {
"angular2": "2.0.0-beta.0",
"systemjs": "0.19.6",
"es6-promise": "^3.0.2",
"es6-shim": "^0.33.3",
"reflect-metadata": "0.1.2",
"rxjs": "5.0.0-beta.0",
"zone.js": "0.5.10"
"devDependencies": {
"lite-server": "^1.3.1"
也可以选择其他包。我们推荐这些包是因为这些在一起工作的很好。现在和我们一起摇摆吧。之后你可以根据自己的爱好和经验随意替换。
package.json文件有一个可选的scripts部分，在这里我们可以定义一些帮助命令来执行开发和构建任务。我们已经在我们的package.json文件中包含了一些这样的scripts。
package.json (scripts)
"scripts": {
"start": "npm run lite",
"lite": "lite-server"
我们已经知道使用npm start来运行服务器。我们指定的是npm start命令，但实际运行的是npm run lite命令。我们用如下形式执行npm scripts：npm run + script-namenpm run lite的作用-运行lite-server，它是John Papa书写并维护的一个轻量的静态文件服务器，对使用路由的Angular应用支持很好。
附录：npm错误和警告
如果在执行npm install命令时没有出现npm ERR!，一起都好。可能会有几个npm WARN消息，这也没有影响。我们会经常在一连串的gyp ERR!（gyp: generate your project）消息后看到一个npm WARN消息。不用管他们。一个包会使用node-gyp重新编译自己。如果重新编译失败，包会恢复（场使用一个预编译版本），一切正常工作。只要保证在npm install命令最后面没有npm ERR!就好。
附录：boot.js
启动是平台相关的。我们使用的bootstrap函数来自ng.platform.browser而不是ng.core。这是有原因的。创建一个单独boot.js的原因：
这是容易的分离boot.js很容易。这对大多数应用都有益处，虽然在Quickstart中没什么用。让我们从最开始就养成好习惯。
可测试性即使我们不用测试Quickstart我们也因该总一开始就考虑可测试性。如果同一个文件中有一个对bootstrap的调用，要测试这个组件就比较困难。只要我们载入组件文件来测试组件，bootstrap函数就会尝试着在浏览器中载入应用。它会抛出一个错误，因为我们只想测试组件而不是运行整个应用。在boot.js文件中找到bootstrap函数，删除这个似是而非的错误，留下一个干净的组件模块文件。
重用性在应用的演化过程中，我们要重构、重命名和重定位文件。当文件调用bootstrap时我们对这些文件不能做上面任何操作。我们不能移动，不能在其他应用中重用组件。我们不能为提升性能在服务器端预渲染组件。
关注分离一个组件的责任就是展示和管理一个视图。启动应用和视图管理没有一点关系。这是一个分离的关注点。我们在测试和重用中遇到的很多问题都源于这种责任的混淆。
引入/输出当分离boot.js时我们学会了Angular一个关键技能：如何通过简单的命名空间抽象输出一个模块和如何导入另一个模块。在后续学习中会经常这么做的。