I’ve been studying topics related to social science recently and one item that keeps popping up in various places is the idea of luck. It turns out that lucky people aren’t really all that lucky. There life has been arranged either by them directly or indirectly by their environment so they end up having more chances of good things happening to them.
How can we apply this to programming? How can you be a lucky programmer? 
Photo Gaertringen via Visual Hunt
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?
Over the last several months, I’ve seen a lot of whining, complaining a fear regarding Angular 2 in particular and the JavaScript platform in general.
Terms like “JavaScript fatigue” are indicative of the attitude.
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? Or the general attitude that particular (modern) design decisions that have been made in some of the more recent frameworks that have been released are bad for JavaScript.
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:
In the new world of Angular 2, and even in the world of Angular.js, you might feel like the concept of a module is the most difficult to wrap your head around.
This is especially if you’ve only ever written client side JavaScript code. Once you’ve learned why you need a module, the temptation is to use one module for all your code. I am guilty of doing that myself when I first started. But, many times using one module for your entire application is the wrong thing to do because it reduces the ability to reuse your code in other modules. Once you understand why modules exist, you’ll begin to reason about how to use modules appropriately.
If you’ve started looking at Angular 2, one of the things that you’ll notice is that RxJS has gotten a bit of a toe hold in the framework. This becomes apparent the first time you try to access data. Gone is the $http service that returns a promise. Instead, we now have a service that returns an Observable. Now, writing the code to access the server is arguably easy to learn. But, as you travel down the rabbit hole that is Angular 2, you realize that RxJS shows up in places as disperse as NgRX/Store, handling events, and as we’ve already mentioned, AJAX calls.
Because it shows up in so many places, this new API is set to be the next thing we will need to learn to be effective JavaScript programmers. But, should we?
Last week when we took a look at Client side Routing, I mentioned that one of the reasons you’d want to implement a component in its own module is so that we could lazy load the component and its dependencies
This week, we want to dig into how to implement lazy loading in your Angular 2 application
Over the last several Angular 2 posts, we’ve been building up our application bit by bit and examining the various features of Angular 2 along the way using the Angular CLI where that makes sense and modifying it along the way. So far, routing is an area that the Angular CLI does not yet support and so, when you want to use routing in your Angular 2 application, you’ll need to wire most of it in by hand. Now, the routing engine has changed several times during the development of Angular 2. And I know you’re wondering which version of the router this article is going to be talking about. So, to be clear, this article was written using the Angular CLI version 1.0.0-beta.21 and Router version 3.2.1.
This week we want to continue our series about Angular 2 by looking at the Unit Testing capabilities that Angular 2 provides for us. What we want to cover today is:
This article was written using Angular CLI version 1.0.0-beta.20-4 (Tip, if you are upgrading on windows, rm –rf node_modules dist temp just means to delete the three directories. You can do that part manually, or install bash for Windows and run the command in bash.)