Open vthinkxie opened 4 years ago
不知道大家最近有没有注意过这条新闻：GitHub封禁自家开源项目Aurelia引众怒。我看到这条新闻的第一反应是： Aurelia 还有人维护？被封禁还会引起众怒？
实际上，作为早期从 Angular 项目组跳槽后独立开发的 Aurelia 不仅正常运转，还运转的挺不错。不仅不停的有 backer 对其进行赞助，还有独立的 Blue Spire 公司在对其进行管理，Github Star 也早就过万。在大家认定“火”的框架之外，Polymer 也运转的挺好，今年 1 月份还激动地宣布终于所有的主流浏览器都支持了 webcomponents 规范。
还有 Svelte，它在 2018 年底发表了一篇向 Virtual DOM 宣战的檄文，一夜之间热度暴增，但是在这之前，Svelte 已经不温不火了好几年的时间。按照有些前端的评判标准，Aurelia，Polymer 和 Svelte，对了，还要加上 Angular 应该都是过时技术。
Angular 在国内很火吗？显然不够火，现在国内还有相当多的前端开发者分不清 angular.js 和 Angular，喜欢拿着 angular.js 的缺点批判 Angular 一番
但是国内看起来不火的技术就是过时的吗？
显然不是
如果把时间推回 2016 年 9月，在这个时候诞生了一款前端框架，它有着以下众多特性：
以上任何一条，在 2020 年有框架支持其中任意一条应该都会引起不小的热度和讨论，但是以上的这些，2016 年的 Angular 就已经支持了
Angular 在 2016 年就已经支持的几个技术方向，在 4 年后的今天看起来都是超前的
大概两年前 Angular CLI 还是被各种社区诟病的对象，CLI 太重，不灵活，等等等等。
到 2019 年的时候各个框架也有了自己的 CLI，看来大家虽然嘴上不承认，用起来还是真香的。无论是只要运行一次可以将所有的 Angular 环境升级至最新，并且会自动修正掉所有的不兼容代码的 ng udpate，还是默认零配置并且隔绝了底层 webpack 升级，让用户从webpack config 中直接解放出来（当然用户还可以通过自定义 builders 获得 webpack 的自定义能力）的 angular.json，不管你是否承认，Angular CLI 仍然是目前所有框架中最强大的脚手架。
三方组件初始化
ng add @angular/material // 初始化 material design 工程 ng add @angular/pwa // 为当前项目增加 pwa 支持
打包与部署
ng add angular-cli-ghpages && ng deploy // 部署到 Github Pages ng add @netlify-builder/deploy && ng deploy // 部署到 Netlify
Schematics 支持的本质上就是一种 low code platform，由于 Angular 的 Template 本身就代表着 View 层，或者可以当做 config 文件，Angular 做这种低代码生成工具格外得心应手。
在 Angular 生态下直接直接通过 ng generate 命令就可以随意的搭建出来整个项目，也是所有的组件库基本都支持。
ng generate @angular/material:dashboard // 直接生成 material dashboard ng generate ng-zorro-antd:table-row-selection-and-operation // 直接生成 ng-zorro 表格页面
Angular 官方提供了一整套 Schemantic 系列 low code 的搭建文档，企业可以很容易根据自己的业务需要，自定义各种企业 Layout 和 Component 的快速生成器，快速提升企业开发效率。
Angular 从第一个版本开始就是based on RxJS，无论是 HttpClient 还是对 View 的操作，如果你愿意可以随意用 RxJS 的 operator 发挥他们的最大作用。最近还有 RxJS 社区的 Michael 搞出来了 rx-angular， 让 Angular 直接可以充当 RxJS 的 View 层使用，配合刚发布的 RxJS 7.0 beta 的调试工具，也会让数据的中间过程更加透明。
再提一句 Typescript，记得前几年 Angular 刚开始用 TypeScript 的时候还有人说前端不要学后端那套，到今年的时候有人居然会觉得 Angular 只是 TypeScript 的用户，TypeScript 的普及没有 Angular 的功劳。
即使不说后续 Angular 团队贡献的代码，只提 TypeScript 是 AtScript 和 TypeScript 合并的产物，Angular 团队怎么也能算 TypeScript 的半个亲爹，没想到不到几年的时间在知乎就已经被人喷成过时技术的代表了。
此外，脱离第三方包谈 TypeScript 支持完全是空中楼阁，Angular 是目前所有前端框架中，唯一所有的三方库 100% 支持 Typescript 的 ，不知道大家有没有被各种有问题的 d.ts 误导过，这件事情在 Angular 社区中是根本不可能发生的。
Ivy 其实从好几年之前就开始立项了，核心思想是通过 Compiler 静态编译减少实际运行时的代码量，之所以做了这么久是因为 Ivy 要保证与之前 Angular 版本的所有兼容情况，相当于在给一辆高速公路上运行的车辆换Engine。
其实所有的 Compiler + Template 的框架想要发挥最大优势基本这是必经路线。Minko 在 Ivy 正式发布之后发布了这样一条 twitter，如果你感兴趣这部分的话，可以直接在 Angular 9.0 之后的项目中运行 npx ngc，结果一定会让你对整个 Angular 项目组的技术实力刮目相看。
如果你认为 Svelte 的技术方向够 fancy，就没有任何理由去贬损 Angular，要不然就是真正的大型双标现场。
当然，先进不一定代表 100% 的会火，每一种框架都有自己的取舍，不同的场景的使用者、不同的背景的程序员对于 Angular 可能有完全不一样的感受。
我认为 Angular 在国内不够"火"的原因有以下几点：
Angular 的 发布时间（2016年9月）是 晚于 Vue（2014年2月）两年 和 React（2013年3月） 三年半的，所有的第三方生态的建立都需要时间。
另外晚于 React 和 Vue 发布，实际上大量的国内前端开发者在那个时刻已经更换到 React 或者 Vue，Angular 能够带来的工程化收益又不足以让很多开发者更换框架（现在让很多 Angular 用户切换到 React 自然也是不愿意的，同样的原因）。如果把 Angular 作为一款在售产品的话，这个产品的发布时间显然有待考量。
Angular 早期市场定位把所有关心 bundle size 的用户都排除在外了，Angular 4.0 之前 bundle size 轻松超过 1MB，对于很多移动端开发是不可接受的。
虽然这个问题在 Angular 最近几个版本中已经得到了彻底解决（目前 Hello World 包含所有必须套件的情况下 gzip 后的尺寸在 30KB 以内，与 vue 或者 react 增加必须套件 gzip 之后体积没有区别），但是仍然给很多早期用户留下了 Angular 应用打包太大的印象。
如果你只需要一款简单的应用，而不是直接要做一款大型应用，Angular 应该 100% 会给你一种 over design 的假象。甚至官方文档也是直接默认把用户当做要开发大型项目来对待，直接从 Router 开始教学（唯一一个这么做的前端框架），应该让很多入门者当场弃坑。
Angular 直接用户定位一直在大中型项目上，规范一直是 Angular 团队最看重的东西，Angular 从各种行为模式上限制了开发者的自由度，很多操作不是不能做，而是 Angular 从最佳实践上限制了你的花式写法，官网文档压根不给用户提供超出最佳实践范围的写法指南（比如runtime compile template），直接从源头避免了 100 个开发者的 101 种开发姿势，这很容易给很多人一种 Angular 官网大而不全的错觉。说直白一些就是“这也不准做，那也不准做”，这真的太容易被很多热爱自由的前端开发者的攻击了，是典型的吃力不讨好的操作。
而实际上前端框架的 用户/开发团队 选型转换无非有两种情况，一种是从 大型项目-》小型项目，有些 用户/开发团队 感受到了一个框架企业级的好处，然后在小型的项目中也会采用。而另一种是从 小型项目 -》大型项目，用户/团队 在小型项目中熟悉了某种框架的使用，然后在大型项目中采用。
在后一种路径下，用户和部分团队可以通过自己的努力开发出来能满足大型项目的三方库，虽然大部分不会像 Angular 官方提供的这样稳定，但是从另外一个维度也必定激活了大量社区开发者与团队的热情与KPI（非贬义），变得很火。
Angular 整个开发团队都有服务端的背景，从起名到营销上都比其他框架差了不是一点半点。举个栗子，Angular 底层的所谓 DirtyCheck 与所谓的 Virtual DOM 相比，从原理上无论如何 DirtyCheck 是要更快的（当然这是在牺牲了灵活性的基础上），但是估计大家听到 DirtyCheck 第一反应就是 angular.js 那套（根本不是一回事）。
今年大火的微前端的概念，95% 微前端要解决的问题，在 Angular 体系内都可以通过 module + DI + submodule 解决，我们两年前在业务中解决这些问题的时候，完全没有意识到整套 Angular 提供好的解决方案，事实上就是微前端。
最近社区搞出来的那套可以全 Reactive Programing 的方案，直接起名叫 ngrx/components，营销效果 0 分。这几年整个 Angular 团队在营销上最好的表现，应该就是给新的 Compiler + Render 起了个新名字。其余的 Dependency Injection，装饰器等等 100% 会劝退很多追求 fancy 的前端开发工程师。
从公司背景来说，我们维护 Angular 开源库已经有超过 3 年的时间，根据我们的用户统计，大量的 toB 的企业使用 Angular 并且有内部组件库的，但是这些传统 toB 企业受限于各种原因，又不会开源内部的组件库（非贬义）。甚至有大量的国内企业使用了 ng-zorro-antd 但是由于 toB 企业内部审批的原因不能对外公布，这可以解释为什么你在国内很少看到国内 Angular 开发者发声的原因。
从开发者背景来说，大量的 Angular 开发者与 Angular 官方都有着相同的服务端背景，如果你关注过 Github 的 trends 就能理解服务端项目的人有多么不善于创造“火”的概念。
Angular 官方负责维护了大量的官方库，并且保障了每次升级的兼容性（Angular 甚至保障了很多非 Angular 官方开发包的兼容性）。
范围广泛的官方职责对于需要长期维护的前端项目自然是好事情，但是这也必定社区的第三方库看起来不那么“火“，比如 router ，在 Angular 提供了官方 router 的前提下，社区的 router 很难再有独立发展并且火爆的可能性，说白了就是官方的职责太广，反而减少了社区的表面繁荣的现象。
按照 KANO 模型， Angular 有些功能对于企业开发者来说都是 Basic Needs，然而对于期盼自由度的开发者却很容易成为 Reverse Quality。甚至很多对 Angular 工具库的不满也会直接影响被指向 Angular 本身。
react-router 不兼容升级的时候不会有人怪罪 react，但是 @angular/router 如果不兼容升级（是一个假设），一定在社区会被拉去祭天。同样的，Angular CLI 即使提供了 webpack 的自定义方式，也总会有人指责 Angular CLI 没有一键满足他们的需求，虽然 Angular 一样可以手写 webpack config 编译，即使回退到最原始的情况下也没有比其他框架更差。
官方的职责范围一旦覆盖了太多领域，就很难让所有用户满意，甚至会让很多用户产生敌意。这也可以用来解释为什么同样使用 Angular，不同用户的感受会差别很多。
如果你在前端框架上追求的更多是：升级稳定、标准统一、长期维护成本低、协作方便，不需要频繁重构，Angular 的使用感受应该还是相当不错的，这也是为什么目前大量企业用户会选择 Angular 的原因。
反过来，如果你追求的是绝对的自由，那你使用 Angular 的时候感受到的一定会是各种限制。
不过 Angular 在 Ivy 项目开启的时候就已经开始为追求自由/小型应用的程序员提供更多的支持，比如First-Class LazyLoad Component，renderComponent 这些新的 API 也会让 Angular 在小型化应用上更加得心应手，甚至可以直接 renderComponent from Scratch。
这些都是不同框架职责范围的取舍而已，希望这篇文章能给大家框架选型带来更多思路。
支持，我也用angular，虽然我是个菜鸟
winson08Li
commented
3 years ago winson08Li
commented
3 years ago
不知道大家最近有没有注意过这条新闻：GitHub封禁自家开源项目Aurelia引众怒。我看到这条新闻的第一反应是： Aurelia 还有人维护？被封禁还会引起众怒？
实际上，作为早期从 Angular 项目组跳槽后独立开发的 Aurelia 不仅正常运转，还运转的挺不错。不仅不停的有 backer 对其进行赞助，还有独立的 Blue Spire 公司在对其进行管理，Github Star 也早就过万。在大家认定“火”的框架之外，Polymer 也运转的挺好，今年 1 月份还激动地宣布终于所有的主流浏览器都支持了 webcomponents 规范。
还有 Svelte，它在 2018 年底发表了一篇向 Virtual DOM 宣战的檄文，一夜之间热度暴增，但是在这之前，Svelte 已经不温不火了好几年的时间。按照有些前端的评判标准，Aurelia，Polymer 和 Svelte，对了，还要加上 Angular 应该都是过时技术。
Angular 在国内很火吗？显然不够火，现在国内还有相当多的前端开发者分不清 angular.js 和 Angular，喜欢拿着 angular.js 的缺点批判 Angular 一番
但是国内看起来不火的技术就是过时的吗？
显然不是
如果把时间推回 2016 年 9月，在这个时候诞生了一款前端框架，它有着以下众多特性：
以上任何一条，在 2020 年有框架支持其中任意一条应该都会引起不小的热度和讨论，但是以上的这些，2016 年的 Angular 就已经支持了
Angular 在 2016 年就已经支持的几个技术方向，在 4 年后的今天看起来都是超前的
脚手架 + 自动升级 + 零配置
大概两年前 Angular CLI 还是被各种社区诟病的对象，CLI 太重，不灵活，等等等等。
到 2019 年的时候各个框架也有了自己的 CLI，看来大家虽然嘴上不承认，用起来还是真香的。无论是只要运行一次可以将所有的 Angular 环境升级至最新，并且会自动修正掉所有的不兼容代码的 ng udpate，还是默认零配置并且隔绝了底层 webpack 升级，让用户从webpack config 中直接解放出来（当然用户还可以通过自定义 builders 获得 webpack 的自定义能力）的 angular.json，不管你是否承认，Angular CLI 仍然是目前所有框架中最强大的脚手架。
三方组件初始化
打包与部署
Schematics
Schematics 支持的本质上就是一种 low code platform，由于 Angular 的 Template 本身就代表着 View 层，或者可以当做 config 文件，Angular 做这种低代码生成工具格外得心应手。
在 Angular 生态下直接直接通过 ng generate 命令就可以随意的搭建出来整个项目，也是所有的组件库基本都支持。
Angular 官方提供了一整套 Schemantic 系列 low code 的搭建文档，企业可以很容易根据自己的业务需要，自定义各种企业 Layout 和 Component 的快速生成器，快速提升企业开发效率。
RxJS
Angular 从第一个版本开始就是based on RxJS，无论是 HttpClient 还是对 View 的操作，如果你愿意可以随意用 RxJS 的 operator 发挥他们的最大作用。最近还有 RxJS 社区的 Michael 搞出来了 rx-angular， 让 Angular 直接可以充当 RxJS 的 View 层使用，配合刚发布的 RxJS 7.0 beta 的调试工具，也会让数据的中间过程更加透明。
TypeScript
再提一句 Typescript，记得前几年 Angular 刚开始用 TypeScript 的时候还有人说前端不要学后端那套，到今年的时候有人居然会觉得 Angular 只是 TypeScript 的用户，TypeScript 的普及没有 Angular 的功劳。
即使不说后续 Angular 团队贡献的代码，只提 TypeScript 是 AtScript 和 TypeScript 合并的产物，Angular 团队怎么也能算 TypeScript 的半个亲爹，没想到不到几年的时间在知乎就已经被人喷成过时技术的代表了。
此外，脱离第三方包谈 TypeScript 支持完全是空中楼阁，Angular 是目前所有前端框架中，唯一所有的三方库 100% 支持 Typescript 的 ，不知道大家有没有被各种有问题的 d.ts 误导过，这件事情在 Angular 社区中是根本不可能发生的。
Ivy Compiler
Ivy 其实从好几年之前就开始立项了，核心思想是通过 Compiler 静态编译减少实际运行时的代码量，之所以做了这么久是因为 Ivy 要保证与之前 Angular 版本的所有兼容情况，相当于在给一辆高速公路上运行的车辆换Engine。
其实所有的 Compiler + Template 的框架想要发挥最大优势基本这是必经路线。Minko 在 Ivy 正式发布之后发布了这样一条 twitter，如果你感兴趣这部分的话，可以直接在 Angular 9.0 之后的项目中运行 npx ngc，结果一定会让你对整个 Angular 项目组的技术实力刮目相看。
如果你认为 Svelte 的技术方向够 fancy，就没有任何理由去贬损 Angular，要不然就是真正的大型双标现场。
当然，先进不一定代表 100% 的会火，每一种框架都有自己的取舍，不同的场景的使用者、不同的背景的程序员对于 Angular 可能有完全不一样的感受。
我认为 Angular 在国内不够"火"的原因有以下几点：
发布时间
Angular 的 发布时间（2016年9月）是 晚于 Vue（2014年2月）两年 和 React（2013年3月） 三年半的，所有的第三方生态的建立都需要时间。
另外晚于 React 和 Vue 发布，实际上大量的国内前端开发者在那个时刻已经更换到 React 或者 Vue，Angular 能够带来的工程化收益又不足以让很多开发者更换框架（现在让很多 Angular 用户切换到 React 自然也是不愿意的，同样的原因）。如果把 Angular 作为一款在售产品的话，这个产品的发布时间显然有待考量。
早期 Bundle Size 问题
Angular 早期市场定位把所有关心 bundle size 的用户都排除在外了，Angular 4.0 之前 bundle size 轻松超过 1MB，对于很多移动端开发是不可接受的。
虽然这个问题在 Angular 最近几个版本中已经得到了彻底解决（目前 Hello World 包含所有必须套件的情况下 gzip 后的尺寸在 30KB 以内，与 vue 或者 react 增加必须套件 gzip 之后体积没有区别），但是仍然给很多早期用户留下了 Angular 应用打包太大的印象。
用户定位与限制
如果你只需要一款简单的应用，而不是直接要做一款大型应用，Angular 应该 100% 会给你一种 over design 的假象。甚至官方文档也是直接默认把用户当做要开发大型项目来对待，直接从 Router 开始教学（唯一一个这么做的前端框架），应该让很多入门者当场弃坑。
Angular 直接用户定位一直在大中型项目上，规范一直是 Angular 团队最看重的东西，Angular 从各种行为模式上限制了开发者的自由度，很多操作不是不能做，而是 Angular 从最佳实践上限制了你的花式写法，官网文档压根不给用户提供超出最佳实践范围的写法指南（比如runtime compile template），直接从源头避免了 100 个开发者的 101 种开发姿势，这很容易给很多人一种 Angular 官网大而不全的错觉。说直白一些就是“这也不准做，那也不准做”，这真的太容易被很多热爱自由的前端开发者的攻击了，是典型的吃力不讨好的操作。
而实际上前端框架的 用户/开发团队 选型转换无非有两种情况，一种是从 大型项目-》小型项目，有些 用户/开发团队 感受到了一个框架企业级的好处，然后在小型的项目中也会采用。而另一种是从 小型项目 -》大型项目，用户/团队 在小型项目中熟悉了某种框架的使用，然后在大型项目中采用。
在后一种路径下，用户和部分团队可以通过自己的努力开发出来能满足大型项目的三方库，虽然大部分不会像 Angular 官方提供的这样稳定，但是从另外一个维度也必定激活了大量社区开发者与团队的热情与KPI（非贬义），变得很火。
不搞新概念
Angular 整个开发团队都有服务端的背景，从起名到营销上都比其他框架差了不是一点半点。举个栗子，Angular 底层的所谓 DirtyCheck 与所谓的 Virtual DOM 相比，从原理上无论如何 DirtyCheck 是要更快的（当然这是在牺牲了灵活性的基础上），但是估计大家听到 DirtyCheck 第一反应就是 angular.js 那套（根本不是一回事）。
今年大火的微前端的概念，95% 微前端要解决的问题，在 Angular 体系内都可以通过 module + DI + submodule 解决，我们两年前在业务中解决这些问题的时候，完全没有意识到整套 Angular 提供好的解决方案，事实上就是微前端。
最近社区搞出来的那套可以全 Reactive Programing 的方案，直接起名叫 ngrx/components，营销效果 0 分。这几年整个 Angular 团队在营销上最好的表现，应该就是给新的 Compiler + Render 起了个新名字。其余的 Dependency Injection，装饰器等等 100% 会劝退很多追求 fancy 的前端开发工程师。
开发者与公司背景
从公司背景来说，我们维护 Angular 开源库已经有超过 3 年的时间，根据我们的用户统计，大量的 toB 的企业使用 Angular 并且有内部组件库的，但是这些传统 toB 企业受限于各种原因，又不会开源内部的组件库（非贬义）。甚至有大量的国内企业使用了 ng-zorro-antd 但是由于 toB 企业内部审批的原因不能对外公布，这可以解释为什么你在国内很少看到国内 Angular 开发者发声的原因。
从开发者背景来说，大量的 Angular 开发者与 Angular 官方都有着相同的服务端背景，如果你关注过 Github 的 trends 就能理解服务端项目的人有多么不善于创造“火”的概念。
官方职责与三方库边界
Angular 官方负责维护了大量的官方库，并且保障了每次升级的兼容性（Angular 甚至保障了很多非 Angular 官方开发包的兼容性）。
范围广泛的官方职责对于需要长期维护的前端项目自然是好事情，但是这也必定社区的第三方库看起来不那么“火“，比如 router ，在 Angular 提供了官方 router 的前提下，社区的 router 很难再有独立发展并且火爆的可能性，说白了就是官方的职责太广，反而减少了社区的表面繁荣的现象。
按照 KANO 模型， Angular 有些功能对于企业开发者来说都是 Basic Needs，然而对于期盼自由度的开发者却很容易成为 Reverse Quality。甚至很多对 Angular 工具库的不满也会直接影响被指向 Angular 本身。
react-router 不兼容升级的时候不会有人怪罪 react，但是 @angular/router 如果不兼容升级（是一个假设），一定在社区会被拉去祭天。同样的，Angular CLI 即使提供了 webpack 的自定义方式，也总会有人指责 Angular CLI 没有一键满足他们的需求，虽然 Angular 一样可以手写 webpack config 编译，即使回退到最原始的情况下也没有比其他框架更差。
官方的职责范围一旦覆盖了太多领域，就很难让所有用户满意，甚至会让很多用户产生敌意。这也可以用来解释为什么同样使用 Angular，不同用户的感受会差别很多。
总体而言
如果你在前端框架上追求的更多是：升级稳定、标准统一、长期维护成本低、协作方便，不需要频繁重构，Angular 的使用感受应该还是相当不错的，这也是为什么目前大量企业用户会选择 Angular 的原因。
反过来，如果你追求的是绝对的自由，那你使用 Angular 的时候感受到的一定会是各种限制。
不过 Angular 在 Ivy 项目开启的时候就已经开始为追求自由/小型应用的程序员提供更多的支持，比如First-Class LazyLoad Component，renderComponent 这些新的 API 也会让 Angular 在小型化应用上更加得心应手，甚至可以直接 renderComponent from Scratch。
这些都是不同框架职责范围的取舍而已，希望这篇文章能给大家框架选型带来更多思路。