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.

Read More

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:

1. Handling Forms
2. Page State Management
3. Component State Management
4. Data Flow
5. Client Side Data

Read More

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.

Read More

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?

Read More

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

Read More

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.

Read More

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:

• Tweaking Karma to avoid using the Browser Window
• Code Coverage
• Tips to testing components

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.)

Read More

When Node.JS started getting popular, one of the major benefits people were proclaiming about it is that the web servers running under Node.JS were all processing the request asynchronously. This is how a single threaded environment was able to handle a significant load without falling over. Cool! So, you might wonder how does ASP.NET process request? It processes code synchronously. So, one might assume that if there were a way of running code asynchronously, we might be able to improve the performance of our applications. But can we? And if we can, is it worth it?

Read More

Angular 2 is finally released. But the biggest problem with learning Angular 2 is that it is a “Choose your own adventure” kind of framework. And while React has a similar problem, I think Angular has out done them. This means that you can learn bits and pieces of Angular 2, but it will be a while before you get a cohesive understanding of what choices you need to make, which choices are the right choices, and why all of this matters.

And all of this is even more difficult if you are a relatively new programmer. I’m talking those of you who have less than 5 years of experience and even some of you who have less than 10 years of experience.

So, what I thought I’d do to address this very real problem is to assemble a very opinionated Angular 2 tutorial. Over the next several weeks I plan to show you how to create a simple CRUD application using Angular 2 in a way that will scale up to larger projects. While I may mention some of the other options along the way, what you’ll end up with is the “right way.” OK. To be fair, most of what I consider “right” is opinion. Some very smart people disagree with me. But, some other very smart people agree with me too.

Read More

• Tightly coupled code runs faster.
• Tightly coupled code is easier to write.
• Test Driven Development increases development time.
• Test Driven Development negatively impacts code design.
• Knowing the names of design patterns isn’t important as long as you can use them.
• All my customer cares about is how soon they can have the product, not how clean the code is.

All of these statements, and others like them, are excuses for not writing code correctly. And you know what an excuse is, right?

The skin of a reason stuffed with a lie.

Read More