I was asked this past week what my thoughts were on Angular 2. I wrote early on about my impressions of Angular 2 when it was barely done enough to review. But now that I’ve been working with it for a while and know a bit more, what I want to discuss is more along the line of what it means to the average developer and, more importantly, organizations that are planning to use it.

Options

While like Angular 1, Angular 2 provides us with most of what we need to build an application. Angular 2 also provides us, out of the box, with very Angular 1 ish ways of putting together an application, complete with modules. What Angular 2 provides that isn’t quite so obvious going into your development is options.

In angular 1, we had options at the GUI level. And while this is still true for Angular 2, this is not the only place where you will see options.

In general, you can split your options into, 1) do you want to do things the Angular 1 way, or 2) would you like to use an approach that looks more like React.JS? No place is this more obvious than with how you deal with forms. You can create forms with a declarative syntax, like you’ve done with Angular 1, using Template Syntax. But, in my opinion, a much better way to create forms is with a more reactive approach using the FormControls and FormGroups classes. If all you are doing is just displaying data, you’ll probably find that using the template syntax is all you need. But once you start working with complex forms that accepts data input and implements validation, you’ll probably want to move toward a more reactive approach. The added benefit is that more of you code will be testable.

The next option you are going to have is figuring out how to move data around your system. Most of the literature is going to suggest you use a data flow that looks a lot like what you were doing in Angular 1. But there is nothing stopping you from using Flux, Redux, or even RxJS instead. And here again, my recommendation would be that you learn these because I think you’ll find that your system will end up being much easier to reason about than the old MVVM stuff you may be used to.

Lazy Loading

There are several places where we had to make choices in Angular 2 where the feature has been built into the framework. One of these places is lazy loading. Why load all of your JavaScript up front? Load what you need when you need it. Angular 2 makes this easy with Lazy Loading and the choice between using WebPack (the default) or System.JS.

I’ll warn you though, as of this writing, Lazy Loading only really works when using System.JS unless you want to spend a lot of time tweaking your webpack config file.

Angular 2 CLI

Command Line Interfaces seem to be the cool new kid on the block. You aren’t a real framework unless you have one. While the Angular CLI is not quite baked yet, I can see how this is going to make writing Angular 2 apps much easier. There are a lot of moving parts involved in getting even the most basic of applications up and running. The Angular CLI makes starting your first application REALLY easy. It even hides all of the WebPack internals while allowing you to add your own config file if you need to. Once they have the routing bit re-implemented, it should make using Lazy Loading with WebPack much easier.

The other thing using the CLI will do for you is that you will automatically start following the coding standards that the Angular team have developed.

Angular 2 Components

Right now, there aren’t a lot of options available for Angular 2 for custom components. While Kendo UI has been the defacto standard for Angular components in the past, Telerik is in the middle of rewriting Kendo UI for Angular 2 (and React.JS). I haven’t seen any movement in the Angular UI camp to support Angular 2. Angular 2 Material has a few components that seem ready, but they are all relatively simple. The only vendors that seems to have a complete Angular 2 package is Wijmo and Prime Faces. I haven’t tried them and I’m not endorsing them. I’m just reporting what I’ve found. There are a few standalone components here and there, but if you are looking for a set of components you can just use from one source, I’m afraid you’ll have to wait. This isn’t necessarily a bad thing. It gives you time to properly learn Angular 2.

But what about the Angular 1 to Angular 2 bridge? In my mind this is way more trouble than it is worth. We’ve waited two years for Angular 2, I think we can wait just a bit longer for a set of components that we can use with it.

What Angular 2 Means for You

The main difference between Angular 1 and Angular 2 is that just about any Script Kiddie could pick up Angular 1 and get something done. Angular 1 was developed during a period of JavaScript history when JavaScript had not quite reach the level of “serious programming language.” But now, JavaScript has not just reached that level, but several very serious frameworks have been developed.

What I notice as I review the JavaScript landscape is that we’ve moved from just getting stuff done with little to no planning, to treating JavaScript as a first class programming language that requires, and even demands that we adhere to a set of programming best practices that we would use for any other language. These include things like naming conventions and design patterns. For you to write code well in this new universe, you will need to understand what these design patterns are, why they exist and how to implement them well. If you continue on your merry script kiddie way, you will soon find yourself out of work.

Further, if you think you know Angular 2 just because you know Angular 1, or you think Angular 2 will be easy to pick up because you know Angular 1, you are in for a very big surprise. Many of the concepts are the same. But since Angular 2 has so many options, you should learn the options well so that you can make an educated decision about which option to use.

What Angular 2 Means for Organizations

Similarly, if you are an organization that is planning to move to Angular 2, don’t expect your programmers to just pick up and move to Angular 2 overnight. Give them time to learn it. My recommendation is that you make learning it part of their job while they continue to use Angular 1 for the product you are trying to complete. We all have time pressure, so you need to factor learning into the schedule.

But Angular 2 may also mean you need to find additional programmers who already have the skills and can transfer the knowledge to your team.

This past week I got into a small discussion about the importance of loosely coupled code.  Specifically, I was looking at event handler code that did nothing more than change the size of another element on the screen.  But the event handler code was in the controller which in the particular implementation we are using was the event handler portion of our Model in a MVVM architecture.  The question becomes does this code belong in the view, or does it belong in the controller? The question of where code belongs leads eventually to arguments for loosely coupled code.  If I put code in my controller that is manipulating the view, then I either need to mock out my view in order to test my controller or I have to have an instance of my view available to test my controller.  Having coded enough systems to know that both of those choices are problematic, I opt for placing the view specific code in the view.  Another place where you might place this code would be in a View Specific event handler class.  But that would only be for the purposes of clean separation.  Something we might consider doing if the View were plain HTML.  But in our particular case, the view is generated from code, so placing the handlers in that same code seems to be the most appropriate location for it.

But all of this leads to a larger question.  Why should your code be loosely coupled at all?

Read More

There have been a number of things that have occurred over the last week that have prompted this particular post.  And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry.  PLEASE don’t take this personally.

Some of those reasons will show up in this article.  But the question we need to examine today is why is it so hard to write bug free code.  And I’m not even talking about perfection.  Why is it that we miss the simple stuff?  The stuff that once it is found, we think, “how could we have missed that?!”.  I’m perfectly aware that all code has bugs some just haven’t been found yet.  I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.

Read More

Have you ever noticed how, when QA reports a “defect” developers tend to bristle?  I first noticed this in myself a few years ago.  Now that I’m functioning as a Scrum coach, I’m noticing it in others.

Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial?  I think so.

I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.

But first, why does this problem exist in the first place?

Read More

We’ve all been there.  Either at the micro level or at the macro level.  Business wants to know, “How much is this going to cost me?”  And as software developers, we all know the answer is, “more than you were expecting.”  We also know that whatever number we give will probably be wrong for a number of reasons.  Chief among them is that no one really knows what they want until they see it.

And yet, there has to be some way of providing business what they need and still allowing for unknowns.

So what follows are a few tips on estimating that help you estimate software projects like a pro.

Read More

Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software.  What works.  What doesn’t.  What mistakes I see people make.

There has also been a move to avoid estimates entirely.  The argument goes something along the lines of, “we know the least about a project at the beginning of the project, so we can’t really give an accurate estimate.”  Which is mostly true.  And yet, there are people who need to know “how much is this going to cost?”  What do we do for them?  How do we balance the two realities? And then all of this lead me to think of all the ways we sabotage our estimates, or our estimates are sabotaged for us.

You might think that estimating projects only applies to project managers.  But the truth is, most places I have worked rely on programmers to give them estimates, and frankly, most of us screw this up.

Read More

I’ve written about using Selenium to test web applications before.  But all of those articles have assumed you are using C#.  I’ve realized that Selenium has multiple language bindings which allow me to use any language I want but C# just seemed easier at the time.  But, now I’m in an environment that doesn’t use .NET at all.  They use Java.  I know Java, but I choose not to use it and instead my focus at this shop is all JavaScript.  Which means, if I want to write Selenium tests to verify my work, I need to write my tests in JavaScript.  But Using JavaScript to Drive Selenium is, in my opinion what everyone should be doing.  At least everyone who is writing most of their web application using client side code.

Read More

We’ll get to Reasons Projects Succeed soon, but I need to do some setup work first.

I’ve been thinking about starting an Open Source project for a while.  The only issue was; I didn’t have an idea for a project that didn’t already exist.  Now I do.  So, I’ve begun the process.

The issue with starting a project like this is that I would much rather just start coding.  In fact, I would much rather not even make this Open Source.  But making it Open Source has forced me to face project management issues head on.

I’ve been listening to enough podcast recently to know that putting something up on GitHub isn’t going to make a project Open Source any more than it will make it successful.  Therefor, I’ve decided to start the project as though it had a team of people already working on it.  It is a team of one for now.  But, one thing I’ve learned in life is that having the structure in place to handle a larger team now will not just benefit me in the future, but it will actually help my small little team of me today.

I’ve started looking at other successful Open Source projects to see what they are doing and to determine what components of what they are doing I want to include in my project.  As I’ve gone through this exercise, the thought occurred to me, “If the organizations I’ve worked for implemented half of what these projects implement, the projects would have been run so much more efficiently and the projects that were in trouble may have avoided the trouble.”

Read More

I was just getting started writing an article about using Node/JavaScript to drive my Selenium tests and as I was writing the “Prerequisite” section, I realized I have never written the basics about how to get setup with Node or even why you would want to.

As popular as Node is, I am still finding that many of the people I work with have no idea what it is or if they do, they only have a partial idea and can’t see how it would apply to the work they do on a daily basis.

So, let’s start with the fundamentals.

Read More

The MVVM design pattern has been around for quite a while now.  It has a lot of strengths when done correctly.

But, I believe the time has come to recognize that MVVM has a lot of shortcomings that point to its demise.  Since I primarily develop web applications, I will keep this discussion centered on the use of MVVM in web applications.  The use of MVVM for desktop may or may not have these same issues.

I realize that for some of you, the very suggestion of dropping MVVM will invoke a negative emotional response.  Some very smart people have quit their job at the suggestion that MVVM and its close cousin two-way data-binding, be abandoned in favor of another way.  But just for a few minutes, I would like for you to stop treating programming as a religion and consider the possibility that there may be a better way.

History of MVVM

MVVM was originally created by John Gossman to support the XAML syntax used to create Windows™ desktop applications and Silver Light applications.  Its main advantage has always been that it provides an easy way to decouple the View code from any business logic that might need to run.  Because of this decoupling, our applications become much easier to unit test.

The next major implementation of MVVM that I can remember is Knockout.  It is the knockout framework that introduced me to MVVM and I have to say it is also the only one I feel like actually got it right.  By that I mean that it actually did what it was advertised to do.  Maybe that’s because of all the implementations I’ve used, Knockout is the only one that ONLY implemented MVVM rather than making it part of a larger framework.

Definition of MVVM

I’ve written about MVVM before where I’ve explained more completely what MVVM is.  But just so we have a working definition of what I mean when I talk about MVVM, let’s define it this way.

MVVM is a design pattern that uses two-way data-binding to get data in and out of the presentation layer, referred to as the View, without the programmer needing to do any more than specifying that this should happen in the view.  MVVM is also able to have data elements and functions in the “ViewModel” track changes so that anything that is dependent on other data is automatically recalculated without the programmer having to write a lot of code to make this happen.  This creates a model that is able to respond to events in the view, but is primarily data centric rather than event centric has we have often reasoned about our applications in the past.

It sounds great.  And when it works it is.  But that’s the main problem, it hardly ever works well.

MVVM Done Right is Slow

If you’ve had any experience or paid any attention to the implementation of MVVM using JavaScript, you will realize that the number one problem with MVVM is that it is a memory hog and performs poorly for all but the most trivial of applications.  In fact, for all of the popularity of Angular JS, the biggest complaint has been around the implementation of the data-binding.  In a large application, you might need to loop through the data multiple times to make sure it has all recalculated correctly.  If you just use the framework and let the framework deal with your sloppy code, this can make the system incredibly slow.  If you actually pay attention to what you are doing, it takes longer to implement than if you had chosen some other design pattern.

But doing that means we have not moved on to…

MVVM is Hard to Implement

Recognizing that looping through the data until it stabilizes may not be a good idea, the framework designers have developed rules such as, “We’ll only run the digest cycle once.”  and “We’ll only run it when some user interaction has occurred.”  Well, OK.  That sounds good.  At least now it will be obvious that I have a problem.  But this is where the trouble begins.  If I can’t rely on my data, and ultimately my view, responding to changes in my data correctly, I am left with having to only partially implementing MVVM so that I can work around these limitations and using other means to make sure my view is updated correctly.

This is to say nothing of many frameworks just not working as you would expect them to.

MVVM is Hard to Reason About

Again, in all but the most trivial of applications, and because of the optimizations that various frameworks have tried to implement, MVVM becomes difficult to implement.  As I’ve tried to explain MVVM to others and even as I’ve tried to implement it myself, I’ve found that the simple act of keeping the view stuff in the view layer and the data stuff in the data layer and making sure it all updates appropriately has me, at times tearing my hair out.  Many times this is caused by incomplete implementations.  But if being hard to implement means it is hard to reason about, maybe we shouldn’t be using it to begin with.

MVVM is Overkill

But it does work sometimes.  In really simple CRUD applications, it works great.  None of the problems I’ve mentioned.  And this is the great seduction of MVVM.  You try it on some small application and you get excited.  Like a gateway drug, it lures you in.  And when you finally go to implement it on some larger application, you find out that it really doesn’t scale all that well.  And on that small app you tried it on, couldn’t you have done that just as easily using another design pattern?

Where to Go from Here

As I was reviewing these arguments with a co-worker this week, he asked, “Are you saying we shouldn’t be using MVVM?”  And my answer might surprise you.

I said, “Given the two models we have to work within the framework we are currently using, MVVM is the best choice.” However, what we might want to consider is moving to another framework that provides a better design pattern.  There are several “One-way” design patterns that intrigue me.  The first is the basic Flux pattern that React tends to use.  Done correctly, this uses events to achieve the decoupling we all should be striving for.  At its core, it is basic MVC.

The second one, which is very flux like, is RxJS.  I’m still wrapping my head around how I to use it in an application and honestly don’t know enough about it at this point to say any more than that it looks interesting.

And even if we decided to move away from MVVM, I think using two way data-binding between the view and the ViewModel is good.  I just think the ViewModel shouldn’t try to re-compute the values as part of what it does.

Leave that to the developer to control.  The problem is, trying to get existing systems that implement two-way data-binding to only work at that level would not work correctly.  

Other places talking about MVVM

• The Advantages and Disadvantages of MVVM (by John Gossman himself!)