I’ve been working with Angular2 now since RC0 and I’ve learned quite a few things about Angular2 DOM tips, tricks, and warnings that you’ll want to pay attention to as you get started.
The first time a programmer who was trained in the classical procedural/object oriented history is confronted with the concept of making everything immutable, the first question that comes to mind is, “won’t that make my application slow?” This is because of how most programmers have been trained. Making everything immutable generally means that we must copy a lot of memory from one place to another. Moving memory around is generally considered slow. And so, most programmers dismiss the whole idea as crazy talk. But is it really all that crazy?
Another place I see this is with the recent announcement from the Angular team stating there will be another major point release every six months. Like this is a bad thing?
And I look at that and honestly wonder why these people are programming in the first place. If change bothers you, you are really in the wrong industry.
On the subject of Angular2 Architecture, the perception is that Angular 2 is a highly-opinionated architecture. But even though there is a style guide for Angular 2, there are a lot of decisions that still need to be made when working on any but the most trivial of applications. And even then, since most applications take on a life of their own, one could make the case that you need to make these decisions for any application you are building regardless of the initial size. Applications grow up. But, that’s another blog post.
I’ve identified, and have formed opinions about 5 areas that Angular 2 leaves open for decisions. Areas that if you don’t spend time considering the choices and making decisions could cost you in the future.
The five areas I’ve identified are:
- Handling Forms
- Page State Management
- Component State Management
- Data Flow
- Client Side Data