Relevant questions

If there is a mistake, welcome to correct it, not glass heart.

To be honest, I personally don’t approve of the big and comprehensive philosophy of The App. Although I have posted a few Angular columns on hydrology, I still don’t like the philosophy of the “pure” framework of React and Vue. But I’m grateful to Angular for taking me into RXJS, that’s all.

Angular’s module system and Bundler have their own set of standard “black boxes,” meaning there is no way to switch smoothly between frameworks like HTTP request libraries. You can choose from any other framework, axios being the most common. Axios-observable supports the Observable API, but Angular uses @angular/common/ HTTP to better support its DI. You can use DI as a library, so that all frameworks can use your DI system. Ts packaging has to be a whole ngFactory concept, even the basic library packaging has to have a special ng-packagr, I can’t stand it, learn rollup/webpack is very difficult, change the front-end framework to learn this? I can’t even look at the NgModule error messages. After using @angular/router, it sends me back to the previous error-free page, which means I have to click the save page again during debugging. !

Angular’s support for hot Module Reload (HMR) is so weak that it’s “garbage.” (IN my experience, Vue’s HMR support is the best.) Reload, reload, reload… I’ve given up fighting.

@angular/ CLI will help you solve the black box problem. I don’t use cli to write my own projects. In @angular/ CLI, I only use two commands: Ng serve and NG build, using @alauda/custom-webpack, because I don’t need the default package configuration at all, which is a drag on productivity. Why can’t Angular go in the same direction as other frameworks? Those ng Lint /test commands are really drunk, aren’t they farting with their pants down? Why would I need to learn lint/test script alone? Must it be configured in angular.json? Angular. json is even more ridiculous. It doesn’t even support JS? Does every company copy/paste different projects? That’s why I created @alauda/ custom-Webpack at Linchman, because custom WebPack configurations are also common in company projects.

Let’s look at CSS packaging. Angular’s solution is to process the CSS file content into a string that is then inserted at runtime by @angular/core. What’s wrong with that? If A/B component references common.css in styleUrls, it will eventually inline common to A and B. CSS content is repeated. Why did Bundler go to the framework when it was the right thing to do?

There is also the matter of blowing JIT to AOT optimization before, have you seen vue blowing? Vue/VUe-loader has always supported so-called “AOT” nately. This is a major optimization for Angular, and all libraries and apps have to make the necessary changes to support AOT, and the AOT has all sorts of restrictions. A build error says that arrow functions are not supported and variables should be exported when JIT is performed. By the way, JIT and AOT change detection times or strategies seem not quite the same, last time ngChina when a guest demonstrated, this is really not to discourage?

Also, Angular maintainers seem to like to do their own thing. Even the I18n solution is built in, which I’m sure I don’t use because it’s so different from other frameworks. We used to use @ngrx/ Translste, but this year WHEN I came back from my second year in the palace, I simplified and rewrote this part, only keeping and customising what we need. That is to say, the official built-in solution is not necessarily the best solution or the one that works for everyone.

React provides the basic capabilities, but it’s up to the community to play with it. Angular I don’t really care about it. It’s like I’ve only had express guidance so far, but after all, the goal is to be an “enterprise application.” Basically, you don’t need to think about SEO. Since Angular is more enterprise oriented, there is no need for personal applications. How can I use Angular for a company project if I haven’t used it for my own application? (Manual dog head here)

That’s why lightweight frameworks like React and Vue are popular because they represent freedom, and I, like many people, don’t like being tied down, let alone a front-end framework, so I would never consider Angular for a personal project. As for the company’s project, the original brother who chose Angular has regretted and left to write React, and we who are now successors will continue to use it, after all, the historical burden will not be removed. But I still want to thank Angular for bringing me into the world of Observables. As @Xu fei said, I believe the React/Vue community will embrace natural observables too, thanks to hooks.

Some people like the constraints of frameworks that allow people who aren’t very good at writing code to write less bad code, while I personally like the freedom of code to show my architectural skills. (Continue with the dog head)

This article was first published in Zhihu column – 1stG full stack road