From my colleagues, both front-end developers and full-stack developers, I've heard nothing but criticism of Angular >2.0.0. I would like to hear the other side. If you use fresh Angular, why?
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.
Not really. Testing components is still really a pain: there's lots of boilerplate and the tests are extremely slow. In a medium-size project, they're far too slow to treat as unit tests: I break out all the TestBed stuff into a separate karma integration test config.
Angular is in desperate need of something like Enzyme.
Well if you use the Angular CLI it will generate the boilerplate test code for you, I don’t find them slow to run personally (my dev machine is pretty well specced though)
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.
To be fair the situation has changed drastically over the past 12 months.
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.
I hate CLIs that do too much. Just give me a sane starter generator and I`ll take it from there. And please don`t hide webpack from me like angular cli does.
And this part "generating new components/services/etc. easy" I always find strange. Creating a component or whatever takes like 1-2 shortcuts in a normal IDE. And you can also use templates to expand various reusable/common parts. 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.
Heavy CLI tools just add another layer of unnecessary complexity to the project. Why don't just learn webpack which you can use on any project, and you will have much more power at your fingertips.
When I used Angular 1, the two way binding was a breathe of fresh air. It was akin to when jQuery first hit the scene and you all of a sudden had selectors. There was a learning curve regarding the "Angular way" (think: $scope, controller, directive), but altogether I was happy with the result and the ideology.
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.
> When I used Angular 1, the two way binding was a breath of fresh air.
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.
Two-way binding is amazing for smaller sites, but it becomes a nightmare for an enterprise-level app. Digests, and having to wait for the next event cycle is an incredible headache, especially when you have to write tests and modify values outside of angular control.
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.
Interesting considering Angular 3 was never in existence, they switched to Semver specifically avoiding vs 3 because of the move to an rxjs based router.
Angular 2+ is much better than 1 - it fixes pretty much all of the warts with 1. On the flip side, there are some tradeoffs, some that is not quite Angular’s fault, although they’re tradeoffs chosen by the Angular team in designing the framework.
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.
My gripe with testing in React has a lot to do with testing in JS in general - it avoids the elephant in the room of how to mock dependencies (whether it be functions, classes, etc.), and control various scenarios so you appropriately unit test business logic. One can impose a solution by convention with React, whether it be creating/using a DI mechanism, creating functions that one can pass in dependencies to that returns the desired function, or other numerous ways. Or one can choose to avoid creating a solution and decide not to directly test those scenarios, but then that just leads to more expensive, fragile, and complicated scenarios where one loses the advantage of the fast & tight feedback cycle a unit test gives you.
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.
Enzyme and Jest (for React) are pretty awesome. I haven't seen UI testing that good elsewhere...not to mention Storybooks which are great for documentation and manual review. Snapshots, auto mocking, etc...you can't beat React's tooling.
I came from React. Angular is a much more complex and strict tool, but with that comes more power (build-in functionality): It's a framework not just a view layer. So it takes more time to learn, but with React you need to first choose, then learn Router, http, ... as well.
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.
Typescript. When working in a shop with a large contingent of .NET developers, having a language that somewhat resembles what they are used to is a great asset.
I found especially that working with a project that requires a lot of extra bits to be installed (like the react ecosystem) makes working with JavaScript libraries from typescript especially painful, since you need to get typescript definitions for all of them, and they may not always mesh well together.
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).
In recent Typescript it defaults not found modules to type `any` and only complains if `--noImplicitAny` is used.
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:
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 use angular 4.x for two and a half reasons in a small shop (e.g., just me, making internal web apps for my org)
(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.
All that said, I was working on 1.x code for quite some time, and only started playing with angular 2+ after 4.0.0 had been released. If I had started a new project during the transition, I probably would have ended up using react. Mostly timing is all.
They are probably just angry at themselves for jumping into React too early. Good I had wits not to do it. Angular is simply awesome, especially with CLI. I am doing a big project and I never touched nasty webpack files. All that I wanted additionally was available via npm install. Typescript is awesome. Tons of frameworks, PrimeNG being the greatest .
