It is small if I want to, but it has lots of features if I need them.
I don't have to worry about 3rd party libraries, because the official router, forms modules, http client, material components, flex layout etc. are all high-quality.
The CLI not only helps with new projects, but also makes testing, linting, building, serving, generating new components/services/etc. easy.
Implementing lazy loading with the router was easy, so that only the modules that I need for a certain route get loaded and my home site isn't 500kb+ for no good reason.
It has a predictable release schedule.
Did they finally fix it to be actually possible to make it small? I remember them quoting some ridiculous number, and none of my colleagues, nor I, could get it below a megabyte using the suggested methods, nor below a few hundred k for a hello world.
After 2.0, AOT got enabled by default, drastically reducing size, then 4.0 drastically reduced size, then the build-optimizer (default with 5.0) drastically reduced size.
Angular is in desperate need of something like Enzyme.
ng new my-project
> And please don`t hide webpack from me like angular cli does
ng eject; that gives you the webpack config and basically disables the CLI
> Why would I ever want to learn some cli command that would create ordinary file for me which I can create as usual with the tool I already use.
You don't have to use it, it's optional
I tried Angular 2 and it was a mess. It feels as though the ideology is fighting you every step of the way, but with no foreseeable benefit beyond the benefits of Angular 1. Angular 1 had some issues of course (mostly with scope) but it gave us a way of working around them (via, $rootScope, etc), but Angular 2 seems to have taken away (again, think $rootScope).
Around the time Ancular 3 came out (yes, a renaming of Angular 2), I moved over to vuejs and haven't looked back yet.
Yeah, to be honest, if you aren't suffering performance issues as a result of it, Angular 1 is very productive. Problems present themselves in applications with large views, or using esoteric low-performing features. Angular >2 should never have been called Angular. Even if they call it "Angular" instead of "AngularJS", everyone called AngularJS Angular to begin with. It's so utterly different that it doesn't even fit in the same places.
Add to that the frequent execution and performance issues with watches and we deeply regret having to deal with it now.
Add to that having to learn the painful guts around digest-related executions. Watches fire on init so you have to ignore those first calls. Tests are nasty because timeouts have to be flushed manually, and $q promises won't resolve until you call $apply, etc. It quickly became "WTF is going wrong internally".
Angular 2 is a lot better, but at this stage I think so many former AngularJS/v1 developers went the react/vue route and don't see any reason to return.
Angular doubles down on the component-based model it tried to emphasize in Angular 1. It also is very performant. The main router is much better than Angular 1’s.
I haven’t used Angular in the past 5-6 months though - in my current role, we decided on React, and have been satisfied with it for the most part, although some things have been more painful than if we were to use Angular (testing being the big one), but also some things are simpler too. There’s tradeoffs with whatever library one goes with, but as a whole, Angular is still a very strong choice IMO.
EDIT: whoops, mistyped. We don't use karma anymore in our React testing stack. It's mocha now.
Hah, looking now, I realize I mistyped. We use mocha, not karma. Was conflating things
Angular’s solution of a robust DI mechanism is a little on the heavy side, and the test execution perf is worse than Angular 1’s in general, but it is almost certainly the most powerful test helper situation available for testing frontend JS chrrently.
Note that testing serverside JS doesn’t suffer as much, since there are libraries for making use of the require cache for mocking such as testdouble.
Now, it all depends what you prefer / what's good for you. For me it was a huge productivity boost to switch to Angular because they just tell me how to do things. I don't spend much time on thinking how to architecture or about which library to choose (e.g. MobX vs. Redux), I just do it. With WebStorm it's two clicks to get a component / service / etc. scaffolded. That is pretty much the fasted it can get. Once you know Angular, you can develop really fast despite it's complexity.
But that's really a personal choice. If you need structure and tend to get lost in decision making, give Angular a try.
For the same reasons I'd choose for larger teams.
It’s really helped reduce some of that 3rd party lib / buildchain JS fatigue for me.
Even with `--noImplicitAny`, it's gotten pretty easy. Leave a scratch .d.ts file somewhere in your project and when you install a new library you can start with:
declare module 'libraryname'
declare module 'libraryname/**/*'
That gives you an explicit `any` for those libraries. Then you can go back and add types later.The number of npm packages with types directly included is growing at an impressive rate (even Facebook often bundles them for React libraries), so there's not even the need to seek out types in so many cases these days.
I believe the latest version of Visual Studio Code can automatically install the type dependencies from the IDE (e.g. a quick fix if the type definitions are missing).
(1) Ionic makes it relatively easy to bundle angular apps into hybrid-native packaging. I personally know it's not much different from users pinning an app to a start screen (other than the offline functionality you get in iOS, since iOS doesn't support service workers yet), but my users like apps for whatever reason. Of course, Ionic is moving away from angular-only, so this won't be a constraint in the future.
(1a) I have worked with react-native and nativescript as well, and can say that it's way easier to build cross-platform stuff with Ionic. If you're building bog-standard businessish CRUD apps, Ionic is super-straightforward. If you're doing cutting edge interfaces and games, well, that's not what this is for.
(2) I honestly prefer Ionic's parameter-binding syntax to mixed JSX syntax. I've written enough JSP, PHP, handlebars and other mixed-template languages, tyvm. I like having a template with data-bound properties and a controller in its own file.
(2.5) Another preference: while I like unidirectional data flow and have written my own rxjs-based middleware for fetching data out of a local cache and from and API (and sending data back), I'm not a fan of how redux and redux-like architectures work. Giant switch blocks feel like they're just re-inventing object method dispatch from another angle.
At the end of the day, the performance differential is negligible (I probably write faster code in angular, because I'm more conversant with it). I get more frustrated with Ionic than Angular most days (I am also looking forward to a future version where using Ionic doesn't tie you into a specific locked version of angular, typescript, and build tooling that's hard to modify).
Sure, there's weaknesses, but from my perspective, people like to yell about angular because they made so many breaking changes with the v2 transition - it's basically just a different framework from the same people now. But the latest stuff is fast and has great AOT package size reduction. If you just come to it as a "well, maybe I'll use angular for this new project" perspective instead of "dang, I don't want to port my 1.x stuff over", you're fine.
And I think Angular is winning anyway by a large margin: https://trends.google.com/trends/explore?date=all&q=Angular%...