Here are my thoughts on Angular and how I think it is compared to its peers (such as Ember, Vue.js, and React).
TypeScript Support (/Requirement?)
I think that one of the biggest things that separates Angular from other web development libraries is its TypeScript support. I'm a fan of TypeScript; it's a programming language that introduces static type checking to JavaScript.
As far as I know, Ember.js doesn't officially support TypeScript. React and Vue support TypeScript, but their documentation for it is somewhat sparse.
But Angular went all-out on their TypeScript support. All examples throughout the official site use TypeScript, and its API documentation has plentiful information about typing. When coding Angular apps using TypeScript, I rarely struggle with finding the right types to use.
But Angular's depth of support for TypeScript has come at an apparent price - I cannot find much information on Angular's official site about how to actually use Angular with JavaScript. I think that there used to be a page on the Angular site for using Angular with JavaScript, but I can no longer find it.
In my opinion, learning Angular requires having to know or learn TypeScript. Otherwise, you're learning Angular by writing code that has little in common with code examples.
Learning Curve
When I started learning Angular, I struggled. I picked-up TypeScript at the same time as I did Angular, so I had to learn both technologies at the same time.
Once I got past the "hello world" phase, I found out that I had a third thing to learn RxJS. Some things in Angular, most notably its HTTP Client, are built using RxJS, so becoming well-versed in RxJS is essential for fluent Angular application development.
It took me a while to understand Angular, TypeScript, and RxJS. But once I did, the act of making Angular applications felt natural. Angular suggests using an application structure (app/component/view/CSS) that is pleasant to work with and excels at separating concerns into manageable pieces. Angular's boilerplate is terse but is easily understood and serves an obvious purpose. And I don't spend a lot of my time looking up what to do, which allows me to focus on actually building applications. I still struggle a bit with RxJS, but I find it pleasant to work with in the context of an Angular app.
Ember.js (pre-2.0) was similarly tough for me to learn, but I never reached the point where developing applications Ember.js was easy for me. Its more "magical" aspects made it rather difficult for me to fully comprehend what my code was actually doing.
Compared to Angular and Ember.js, I had a much easier time learning React. But React is "just" a view library. Angular has more built into it, including dependency injection, URL routing, the aforementioned HTTP client, and extensive tooling.
Tooling
The largest tool in Angular's toolbox is Angular CLI. It's the recommended and best way to develop Angular applications. It handles quite a bit: application scaffolding, dev server instantiation, unit testing, and production builds.
But on one of my applications, I ran into issues with Angular CLI. I'll admit - I ran into an uncommon problem. I was working on a white-label site that's designed to work from any subdirectory, and I couldn't get Angular CLI to build correctly for the site. As it turns out, you don't have to use Angular CLI for your Angular applications. The official site used to have extensive notes about using both webpack (used by Angular CLI) and Rollup. It's mostly gone now, but it was present while I was working on the application, and I successfully built the app using both Rollup and webpack (which I migrated to because of issues with Rollup).
Angular's support for alternative build systems is there, but it's hidden away a bit.
Conclusion
When I build applications for myself, I tend to favor using multiple, small libraries over one large library. I preferred Sinatra over Ruby on Rails, Flask over Django, MVVM Light (and my own KSMVVM.WPF) over larger MVVM libraries for WPF, and React over the original AngularJS.
But I also like modern Angular - it seems every bit as purpose-built as the smaller libraries that I tend to prefer. And even though the documentation is very spotty when it comes to going "off-road", I can appreciate how it does its best to guide developers into a specific way of implementing applications by making decisions for you. Using Angular to its fullest requires using a specific language (TypeScript), a specific way of structuring applications (app/component/view/css), and a specific build system (Angular CLI/webpack). By making these decisions for developers, I feel that Angular is a great fit for larger web-based applications.
No comments:
Post a Comment