We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[zh]
丑话说在前头,如果有错误,欢迎斧正,不要玻璃心。
说实话虽然在灵雀云用 Angular 做着企业级的应用,但我个人是很不认可它大而全的哲学的,虽然我也在 Angular 相关专栏发过几篇水文,但是习惯了 React 和 Vue 『纯粹』框架的哲学后依旧很不喜欢(不喜勿喷),但我很感谢 Angular 带我入了 rxjs 的坑,仅此而已。
Angular
React
Vue
rxjs
Angular 的模块系统和 bundler 都是自己搞得一套标准『黑盒』,也就是说没办法在各个框架直接平滑地切换,比如 http 请求库,其他框架都可以随便选,一般比较通用的是 axios,还有 axios-observable 支持 Observable API,但 Angular 为了更好地支持自己的 DI 又搞了一个 @angular/common/http ,其实大可以把 DI 部分抽成一个库嘛(以前是单独抽了一个 DI 包的,后面又被合到 core 里了),这样所有框架都能使用你这个 DI 系统,岂不美哉?ts 打包非要整出一个 ngfactory 的概念,连基本的库打包都要有个专门的 ng-packagr,真心受不了,学会 rollup/webpack 已经很不容易了,换个前端框架还要学这个???还有各种 NgModule 的报错信息实在不忍直视,用了 @angular/router 后它还直接给我退出到上一个无报错的页面了,也就是调试的时候我还得再点一次保存页面的入口,如果还有错,还得继续来?!
bundler
axios
axios-observable
Observable
@angular/common/http
DI
core
ts
ngfactory
ng-packagr
rollup
webpack
NgModule
@angular/router
说到这里实在不得不再吐槽 Angular 对 hmr(hot module reload) 的支持简直弱爆了,甚至可以说是『垃圾』,(我的个人体验来说 Vue 的 hmr 支持是最好的),开发个新功能页面不停地 reload, reload, reload... 我已经放弃挣扎了。
hmr(hot module reload)
hmr
有人会说这些 @angular/cli 都帮你解决了啊,这还是刚刚『黑盒』的问题,这也是我自己写项目都是不用什么所谓的 cli 的,而 @angular/cli 里我只用会用两个命令:ng serve 和 ng build,而且是在用 @alauda/custom-webpack 的前提下,因为:我压根儿不需要默认的那套打包配置,对我们的生产力反而是阻碍。为什么 Angular 不能往和其他框架一样纯框架的方向走呢?那些什么 ng lint/test 之类的命令真是醉了,这不是脱裤子放屁吗?自己加个 lint/test 脚本的事儿我为什么要去单独学啊?非得在 angular.json 里配置?说到 angular.json 就更可笑了,连 js 格式都不支持?每个公司不同项目都要 copy/paste 吗?这也是为什么我在灵雀云搞了 @alauda/custom-webpack 的原因,因为自定义 webpack 配置在公司内部项目里也是通用的啊。
@angular/cli
cli
ng serve
ng build
ng lint/test
lint/test
angular.json
我们再来看一个 css 打包的问题,Angular 的方案是把 css 文件内容处理完转化成字符串,然后运行时由 @angular/core 进行插入,这有什么问题?问题大了,比如 A/B 组件都在 styleUrls 里引用了 common.css 那么最终它会把 common inline 到 A 和 B 上,也就是 css 内容是重复的,什么 vue-style-loader 它不香吗?明明是 bundler 该做的事情为什么要跑到框架层去做???
css
@angular/core
A
B
styleUrls
common.css
common
vue-style-loader
还有之前吹 JIT 到 AOT 优化的事儿,你看 vue 吹过吗?vue/vue-loader 一直都是原生支持所谓的『AOT』的,到了 Angular 这儿就变成了大优化了,而且所有相关库和 App 都要做一些必要的修改才能支持 AOT,而且这个 AOT 呢还有各种乱七八糟的限制,一不小心就是 build error 说什么哪里哪里不支持箭头函数、哪里哪里得把变量导出去,可这些 JIT 的时候明明都是好好的。对了,JIT 和 AOT 的变更检测次数还是策略好像还不太一样,上次 ngChina 的时候有嘉宾演示了一下,这真不是劝退吗?
JIT
AOT
vue
vue-loader
App
build error
ngChina
再来,Angular 的维护者们似乎都喜欢自己玩儿自己的,连 i18n 方案它都帮你内置了,当然我肯定是不用的,因为和其他框架的使用方式差异太大,实在诡异。我们之前是用的 @ngrx/translste ,今年我『二进宫』回来就把这部分精简重写了,只保留并定制我们自己需要的东西。也就是说官方内置的方案它不一定是最好的或者说是对所有人都适用的。
i18n
@ngrx/translste
最后呢,再说说几个框架对 SSR 的支持,Vue 是有官方指导的,React 提供了基础能力,但是具体怎么玩儿全凭社区,Angular我感觉是对这一块儿不上心的,好像到现在都只有 express 相关的指导,不过毕竟目标是『企业级应用』嘛,基本是不需要考虑 SEO 问题。那既然 Angular 是更面向企业级应用的,那么个人应用就没必要选它了嘛。那既然我个人应用都没有用过 Angular 我怎么敢在公司项目里去用呢?(此处手动狗头)
SSR
express
所以像 React 和 Vue 这种的轻量级框架才会更流行,因为它们才代表了自由,而我和很多人一样不喜欢被束缚,更何况只是一个前端框架,所以我的个人项目是绝不会考虑用 Angular 的。而公司的项目,当初选择 Angular 的大哥已经后悔并离职去写 React 了,而现在的我们这些接盘侠还将继续使用,毕竟历史包袱尾大不掉。但我仍然要感谢 Angular 带我走入 Observable 的世界,正如 @徐飞 所说,我相信 React/Vue 社区经过 hooks 的洗礼也可能会拥抱天然组合的 Observable。
hooks
写着写着好像变成了抨击 Angular 的文章,但其实不是,萝卜青菜各有所爱,有人喜欢框架的约束,让不太会写代码的人也能写出不那么差的代码,而我个人喜欢自由的代码,这样才能显示出我的架构能力不是?(继续狗头)
本文首发于 知乎专栏 - 1stG 全栈之路
The text was updated successfully, but these errors were encountered:
No branches or pull requests
[zh]
丑话说在前头,如果有错误,欢迎斧正,不要玻璃心。
说实话虽然在灵雀云用
Angular
做着企业级的应用,但我个人是很不认可它大而全的哲学的,虽然我也在Angular
相关专栏发过几篇水文,但是习惯了React
和Vue
『纯粹』框架的哲学后依旧很不喜欢(不喜勿喷),但我很感谢Angular
带我入了rxjs
的坑,仅此而已。Angular
的模块系统和bundler
都是自己搞得一套标准『黑盒』,也就是说没办法在各个框架直接平滑地切换,比如 http 请求库,其他框架都可以随便选,一般比较通用的是axios
,还有axios-observable
支持Observable
API,但Angular
为了更好地支持自己的 DI 又搞了一个@angular/common/http
,其实大可以把DI
部分抽成一个库嘛(以前是单独抽了一个DI
包的,后面又被合到core
里了),这样所有框架都能使用你这个DI
系统,岂不美哉?ts
打包非要整出一个ngfactory
的概念,连基本的库打包都要有个专门的ng-packagr
,真心受不了,学会rollup
/webpack
已经很不容易了,换个前端框架还要学这个???还有各种NgModule
的报错信息实在不忍直视,用了@angular/router
后它还直接给我退出到上一个无报错的页面了,也就是调试的时候我还得再点一次保存页面的入口,如果还有错,还得继续来?!说到这里实在不得不再吐槽
Angular
对hmr(hot module reload)
的支持简直弱爆了,甚至可以说是『垃圾』,(我的个人体验来说Vue
的hmr
支持是最好的),开发个新功能页面不停地 reload, reload, reload... 我已经放弃挣扎了。有人会说这些
@angular/cli
都帮你解决了啊,这还是刚刚『黑盒』的问题,这也是我自己写项目都是不用什么所谓的cli
的,而@angular/cli
里我只用会用两个命令:ng serve
和ng build
,而且是在用 @alauda/custom-webpack 的前提下,因为:我压根儿不需要默认的那套打包配置,对我们的生产力反而是阻碍。为什么Angular
不能往和其他框架一样纯框架的方向走呢?那些什么ng lint/test
之类的命令真是醉了,这不是脱裤子放屁吗?自己加个lint/test
脚本的事儿我为什么要去单独学啊?非得在angular.json
里配置?说到angular.json
就更可笑了,连 js 格式都不支持?每个公司不同项目都要 copy/paste 吗?这也是为什么我在灵雀云搞了 @alauda/custom-webpack 的原因,因为自定义webpack
配置在公司内部项目里也是通用的啊。我们再来看一个
css
打包的问题,Angular
的方案是把css
文件内容处理完转化成字符串,然后运行时由@angular/core
进行插入,这有什么问题?问题大了,比如A
/B
组件都在styleUrls
里引用了common.css
那么最终它会把common
inline 到A
和B
上,也就是css
内容是重复的,什么vue-style-loader
它不香吗?明明是bundler
该做的事情为什么要跑到框架层去做???还有之前吹
JIT
到AOT
优化的事儿,你看vue
吹过吗?vue
/vue-loader
一直都是原生支持所谓的『AOT
』的,到了Angular
这儿就变成了大优化了,而且所有相关库和App
都要做一些必要的修改才能支持AOT
,而且这个AOT
呢还有各种乱七八糟的限制,一不小心就是build error
说什么哪里哪里不支持箭头函数、哪里哪里得把变量导出去,可这些JIT
的时候明明都是好好的。对了,JIT
和AOT
的变更检测次数还是策略好像还不太一样,上次ngChina
的时候有嘉宾演示了一下,这真不是劝退吗?再来,
Angular
的维护者们似乎都喜欢自己玩儿自己的,连i18n
方案它都帮你内置了,当然我肯定是不用的,因为和其他框架的使用方式差异太大,实在诡异。我们之前是用的@ngrx/translste
,今年我『二进宫』回来就把这部分精简重写了,只保留并定制我们自己需要的东西。也就是说官方内置的方案它不一定是最好的或者说是对所有人都适用的。最后呢,再说说几个框架对
SSR
的支持,Vue
是有官方指导的,React
提供了基础能力,但是具体怎么玩儿全凭社区,Angular
我感觉是对这一块儿不上心的,好像到现在都只有express
相关的指导,不过毕竟目标是『企业级应用』嘛,基本是不需要考虑 SEO 问题。那既然Angular
是更面向企业级应用的,那么个人应用就没必要选它了嘛。那既然我个人应用都没有用过Angular
我怎么敢在公司项目里去用呢?(此处手动狗头)所以像
React
和Vue
这种的轻量级框架才会更流行,因为它们才代表了自由,而我和很多人一样不喜欢被束缚,更何况只是一个前端框架,所以我的个人项目是绝不会考虑用Angular
的。而公司的项目,当初选择Angular
的大哥已经后悔并离职去写React
了,而现在的我们这些接盘侠还将继续使用,毕竟历史包袱尾大不掉。但我仍然要感谢Angular
带我走入Observable
的世界,正如 @徐飞 所说,我相信React
/Vue
社区经过hooks
的洗礼也可能会拥抱天然组合的Observable
。写着写着好像变成了抨击
Angular
的文章,但其实不是,萝卜青菜各有所爱,有人喜欢框架的约束,让不太会写代码的人也能写出不那么差的代码,而我个人喜欢自由的代码,这样才能显示出我的架构能力不是?(继续狗头)本文首发于 知乎专栏 - 1stG 全栈之路
The text was updated successfully, but these errors were encountered: