AngularJS: The De Facto Standard for SPA Development?

One year ago, I started a large Single Page Application (SPA) project. I spent a few weeks Googling and biting my nails, trying to choose between the various options for SPA development. I considered four leading players:

  1. Knockout with Durandal
  2. Ember
  3. Backbone with Marionette
  4. AngularJS

A year ago this felt like anyone’s race. I ended up selecting Knockout with Durandal for the project since the combination offered clear support for older versions of IE. I currently develop apps for automotive dealerships and they’re notoriously slow to upgrade browsers. I enjoyed the development process with Durandal and Knockout and don’t regret my decision. There’s certainly no way I could’ve pulled off such a rich, interactive UI with solely jQuery.

Yet in the last year I’ve watched the tide shift heavily toward AngularJS.

AngularJS, KnockoutJS, Ember, Backbone

Angular’s momentum has become clear at various conferences across the country. Perhaps the most obvious recent example was at FluentConf in San Francisco:

That’s a pretty striking contrast. Now given, one could argue high conference session counts are merely a sign that Angular is a lot more complicated! But there’s no denying Angular has massive momentum. Enough to settle into a long-term #1 spot on Pluralsight’s top 100 courses. Angular even recently spawned it’s own its own conference: ng-conf.

Today marked another huge landmark for the Angular project: Rob Eisenberg, Durandal’s creator and director, announced that Durandal is being merged with Angular. He quietly joined the Angular team a few months ago. And, going forward, there will be only maintenance releases for Durandal 2. So, Durandal’s upcoming convergence with Angular makes this basically a three horse race.

Only a few years ago JavaScript developers abandoned MooTools, Prototype, and various other frameworks to declare jQuery the de facto standard. And today, Angular has such a clear lead in inertia that I’m comfortable with this declaration:

Angular has become the de facto standard for SPA development.

Why Has Angular Become so Popular?

I see three simple reasons:

1. Google Support – Sure, Google has a long history of killing promising projects. Remember Wave and Reader? But they’re a corporate powerhouse which lends a great deal of credibility to the project. Tell your boss you want to use a free framework from Google. That’s an easy sell.

2. Integrated and Opinionated – I enjoy working with Durandal, but ultimately you must rely upon multiple technologies to create a complex SPA using Durandal including Knockout for binding, RequireJS for dependency management, and a promise library (I went with Q.js). Backbone takes a similar approach – it’s not very opinionated so developers are free to make many architectural decisions on their own or to pull in libraries like Marionnette.

In contrast, Angular is highly opinionated and offers a single integrated solution. It’s analogous to the Unix and Windows model. In Unix you perform complex tasks by piping commands. The composition of many small targeted applications provides great power and flexibility. But the masses gravitate toward opinionated and integrated solutions like Windows. Why? A simple psychological principal called the tyranny of choice. In short, abundant choice often leads to misery. It’s easier to accept a few things you dislike in Angular than to be overwhelmed with decisions in other less opinionated libraries and frameworks.

3. Testability Baked-in – The Angular team has gone to great lengths to assure that Angular apps are testable out of the box. Testing JavaScript is notoriously painful given its lack of native dependency management options and the constant temptation to interact directly with the DOM. Angular’s focus on dependency injection and testability is refreshing. It creates a “pit of success” for developers.

The Future is Evergreen

I still have concerns about Angular. One must ask why Google is making this play at all. I believe it’s the same reason they built Chrome: Angular is Google’s new lever to push the web forward. That said, I worry that Google will push too aggressively on browser standards, thereby making the framework a non-starter for unlucky developers who must support older browsers. It’s clear Google prefers to err on the side of forcing the web forward. I admire this mission, but hate to see the developers supporting legacy browsers left with few viable alternatives.

Framework developers are starting to embrace a new ideal: Soon only Evergreen browsers will be supported by modern frameworks like Angular. This term, coined by Paul Irish has a simple premise: Evergreen browsers auto update. Most of today’s current browsers are Evergreen including Chrome, Firefox, Safari, and IE10+. This trend is great news for web developers who will soon be able to enjoy the power of ECMAScript 6 and the shadow DOM with Web Components. But it means customers should be warned now. Select an auto-updating browser ASAP – The web is surging ahead and Google will use AngularJS to lead the charge.

Chime in on Hacker News, Reddit or in the comments below.

User Interface Framework Showdown: Bootstrap, Foundation, KendoUI, and jQueryUI

Standards might not be exciting, but man, they’re important. Without them everyone does their own thing, reinvents the wheel, and unnecessarily injects new frameworks into the system. Lately the importance of standards has become painfully obvious. In my current role, our app has been around since the days of ASP.NET 1.0, so it’s over a decade old in various spots. In that time it’s picked up over a half dozen data access frameworks! And the story with the user interface frameworks is even more fragmented:

Wow. And this list doesn’t even include the dozens of jQuery plugins that have been pulled in over the last few years like Fancybox, tablesorter, toastr, etc. So the question is, how do you pick one framework? And wait, is that even a practical goal these days? To do so, you obviously have to understand what each offers so you’re clear what you’re giving up.

Since our application is behind a login and requires a lot of rich interactions, we’re moving toward primarily client-side rendering via Knockout with Durandal. So to simplify this list, one important decision involves selecting a client-side UI framework. I pitted four leading client-side UI frameworks against one another for consideration: jQueryUI, KendoUI, Bootstrap 3, and Foundation 5. And yes, Foundation isn’t in the list above but is worth a look. Perhaps it checks all the boxes and can become the one new standard?

XKCD - https://xkcd.com/927/

Okay, fat chance. These all slice the market a little differently. You likely find it odd that I’m pitting jQueryUI and KendoUI against responsive CSS frameworks, but the fact is, as you can see below these four cover a lot of similar ground. I summarized their features in a table I compiled below. Unique attributes are highlighted in yellow.

  jQueryUI KendoUI Bootstrap Foundation
  1.10.4 2013.4.1324 3.1.1 5
Accordian / Panelbar x x x x
Autocomplete x x    
Alerts   x x x
Badges     x  
Breadcrumbs     x x
Button x x x x
ButtonDropdown     x x
Calendar   x    
Color Animation x      
Colorpicker   x    
ComboBox   x    
DatePicker x x    
DateTimePicker   x    
Draggable x x    
DropDownList   x    
Editor   x    
Grid (paginated table)   x    
Icons x x x  
Joyride (guided tour)       x
Labels     x  
Lightbox       x
ListView   x    
Menu x x x x
MultiSelect   x    
NumericTextbox x x    
Pagination   x x x
Pills     x  
Position x      
ProgressBar x x x x
Scheduler   x    
Slider x x    
Splitter   x    
Rotator       x
Resizable x      
Selectable x      
Sortable x x    
Tabs x x x x
TimePicker   x    
Tooltip x x x x
TreeView   x    
Upload   x    
Validation   x   x
Window x x x x
       
 
  jQueryUI KendoUI Bootstrap Foundation
Other Features        
Themeable x x x  
Templatable x x
Knockout Compatable KO/jqueryUI KO-Kendo KO-bootstrap  
HTML Input styling   x x x
Grid System     x x
JS Size (minified) 223 276 28 75
CSS Size (in K) 31 81 97 106
Total size (in K) 254 357 125 181
Browser support IE7+ IE7+ IE8+ IE9+
Sass integration     x x
Support   Telerik   Zurb
Visual Studio Default     x  
Requires jQuery x x    
Fluid grid resizing       x
Dev team 8 core Telerik Open. 500+ Zurb. 15

Summary

Each framework has it’s merits. jQueryUI is easy to use and well documented, though it’s progress lately has been slower than the others. Bootstrap is lightweight and very popular. It has a rich plugin ecosystem that fills in many features that aren’t listed above. Kendo offers many powerful and unique features with a high level of polish. And it certainly should since it’s not free! Foundation is the only option with a fluid resizing grid, and it arguably offers the most compelling mobile first story. Which would you pick if you could only choose one? How does your team avoid ending up with a laundry list of UI frameworks?

Who Dictates Software Quality: Client or Coder?

A friend of mine brought up a common struggle for many software developers, particularly independent consultants:

How do you influence your clients to demand their apps have effective unit and integration test coverage? Quality is a tough sell because the customer doesn’t directly see it.

This struggle between quality and expediency is a common thread throughout any developer’s career. It’s a big reason why I was so excited to publish Architecting Applications for the Real World on Pluralsight. Once we learn best practices, it’s natural to have a desire to apply them everywhere. Yet once pressure is applied, developers tend to revert to the mode that they feel allows them to move fastest. And this commonly means temporarily ignoring clean coding practices and reducing or altogether eliminating efforts in automated testing. Yes, many feel TDD helps them move faster in the long run, yet a recent study by Microsoft found TDD added around 15-35% to the initial development timeline. Thus, like many architectural best practices, TDD is an investment up front for potential payoff later (in both improved design and enhanced agility down the road).

So how do we assure that there’s adequate time to build sufficient quality into the application? I see two approaches to consider:

  1. Developer dictates quality. Code at a level of quality that makes you feel comfortable, fulfilled, and professional. Don’t even broach the subject with the client. There’s no requirement that we expose decisions on such technical details to the customer, right?
  2. Customer dictates quality. Engage the customer in conversations about the current constraints and their impact on code quality. Attempt to sell them on the need for these best practices, the impacts of technical debt, and the cost/benefit ratio. Be flexible and ultimately let the customer make the call on the level of quality they desire.

While neither approach is universally applicable, I tend to choose #1. Why? They’re paying us to be professionals. And as professionals, we should analyze their situation and flex the quality of the implementation based on an assessment of their current and future needs. If I feel that means their timeline is unrealistic, then I discuss the need to flex the feature set or the timeline. I only hack something in to hit the date when I think that option is truly recommended for the client in their current situation.

Waitresses from Alice TV Series on Wikipedia

A Human Service Layer

Think about your job as a service layer. Yes, they’re all the rage these days because they provide a coarse grained, friendly, and reusable API. As developers, we provide a human service layer to our clients. Yes, we’re aware of the fine grained API and plethora of options that we’re working with behind the scenes. But that doesn’t mean we should expose all these choices to the client. They’d likely be both overwhelmed and annoyed. They’re paying us for our judgment.

If you consider other fields, there’s indeed a precedent for hiding information from clients. An architect won’t mention all the potential materials that could be utilized for a structure. She’ll consider the situation and recommend a short list that makes the most sense in that context. A doctor won’t enumerate every potential drug or surgical option to a patient. He’ll instead recommend a specific course of action based on his expertise. We know this to be true because patients often seek second opinions when they don’t like what they’re hearing from the doctor. We assume the doctor is hiding some options he feels aren’t advisable.

We are software professionals, so we know that quality is not an all or nothing decision. We should consider the client’s needs and select an approach that balances quality and expedience. And yes, this means the answer likely won’t be 100% or 0% test coverage. But make your decision based on context, and if the timeline doesn’t afford you the time to deliver at the quality you believe is merited for this project, then it’s not suddenly time to start silently reducing quality to hit a deadline. Instead, it’s time to talk about flexing features and deadlines. Reducing quality below your professional recommendation in order to hit a deadline is malpractice. An architect won’t risk public safety, the company’s future, or her reputation for the sake of a deadline. Neither should we.

How do you balance quality, cost, and timelines? Do you discuss options for quality such as automated testing with your clients? Chime in via the comments below or on Hacker News or Reddit.

Where Should an Architect Begin?

Imagine you’re dropped in a new position with no one there to help provide a smooth knowledge transition. It’s like being dropped right out of the sky. That’s exactly how a new software architect felt who reached out to me with this question:

You are brought on board as a software architect in a company with products in a totally foreign business domain (to you). You are told you are responsible for working with product lines X, Y, Z. Btw, here is the code base (TFS url). Kthxbai.

Ouch. That’s an intimidating place to start. Time to figure out how to eat the elephant a bite at a time.

One obvious starting point is documentation. Well, assuming the existing documentation that isn’t horribly out of date. But properly updated documentation is rarely the case. Much like out of date comments, stale documentation can tell dangerous lies and lead you in the wrong direction altogether. So avoid spending time reviewing any documentation alone. Having others there to vet existing documentation as you review it kills two birds with one stone. If it’s accurate, it shouldn’t take long to confirm. And if it’s a dusty mess, now’s the time to have the conversations necessary to get the house in order.

By Andrew Dupont at http://www.flickr.com/photos/savetheclocktower/172724622/

I would move on by reviewing the codebase at a high level. Where is it stored? What technologies are utilized? What skeletons are in the closet that are immediately obvious? But don’t spend too much time exploring on your own just yet. There’s a more profitable and enjoyable option: buy chicken wings and beer. Get your fellow geeks and business folk out of the office and start picking their brains in a casual atmosphere. Bring some paper so you can sketch down notes as you strive to understand and document the system.

To help drive your initial goals, consider the areas of the application that you seek to manage and improve as an architect:

  1. Security
  2. Reuse
  3. Duplication
  4. Separation of concerns
  5. Code quality
  6. Test coverage
  7. Build process
  8. Consistency
  9. Performance and scalability
  10. What do people love? Hate?

Prioritizing these areas will focus your conversations, questions, and any documentation you decide to generate. Sure, the problem is feeling like the domain you need to learn is too big. Having a standardized list of questions to ask helps drive discovery. However, consider exactly what actions you plan to take based on the answers. This will cut the fat on your list of questions and maximize the signal to noise ratio in conversations. Having a finite set of areas you seek to improve initially will focus conversations and lessen the pain of your initial learning curve.

There’s no easy answers when you’re trying to bootstrap in a situation like this. But organization and clear short-term goals combined with out of the office time to help gain the necessary candor can help make the transition process more profitable and enjoyable for all.

Lean Software Architecture: Focus On the Pain – Part 3 of 3

In previous parts of this series, we outlined a simple two step process for being a lean software architect:

  1. Build the simplest thing that could possibly work
  2. Focus on the pain

In part one of this series, we outlined some specific examples of complexities that today’s software architects may consider. And in part two of this series we defined some ground rules that help you determine if you’re building the simplest thing that could possibly work. In this final part, let’s discuss how to focus on the pain to determine when adding additional complexity to the system is justified.

Once you’ve selected the simplest thing that could possibly work, it’s time to start looking around for pain points. Perhaps you’re seeing redundant queries as the application grows or struggling with unit testing business logic due to tightly coupled data access. This is where abstracting data access into a separate layer can add value.

Hammering Thumb

Perhaps your presentation layer is getting bloated with excessive amounts of logic to handle the interactions among your business logic classes. At this point creating a service layer and migrating such code to this new layer can simplify your controllers. Waiting until this point avoids creating a service layer that may not be necessary or worthwhile.

Maybe your data access story has grown more complex, involving multiple databases and third party services that persist data. Abstracting data access to sit behind the repository pattern can hide this complexity behind a clean simple interface the application can leverage.

Real Craftsmen Consider the Options

Adding complexity is much like adding options on a car. There’s no best practice for selecting options. Automatic transmissions, sunroofs, and heated seats are useful to some and a total waste of money for others. They’re all useful in a certain context and their value thus lies in the eyes of the beholder. In both cars and software, the more options you check, the more money you have wrapped up. So be wary of a blind devotion to perceived “best practices” – it can lead to building more application than you need. Speculative architecture is risky for the same reason speculating in stocks is risky: The investment may sink or swim.

This discussion just scratches the surface of architectural considerations. To learn more about thinking pragmatically about software architecture, check out “Architecting Applications for the Real World in .NET” on Pluralsight.

Architecting Applications for the Real World in .NET

Lean Software Architecture: Build The Simplest Thing – Part 2 of 3

In part one of this series, we outlined some specific examples of complexities that today’s software architects may consider. And we considered how each potential complexity must be justified because each “best practice” has a corresponding context. Finally, we outlined a simple two step process for lean software architecture:

  1. Build the simplest thing that could possibly work
  2. Focus on the pain

In this post we’ll consider step one in more detail.

It’s easy to get in a rut as an architect. One can find a few favorite technologies and patterns that seem to do the trick and start using them religiously. To avoid this tendency, I propose starting with the simplest thing that could possibly work. This angle minimizes commitment to an application that may not pan out in the first place.

Though projects fail for a variety of reasons, common mistakes include building the wrong thing or building the right thing too late. Software is merely a representation of the world around us, and that world is always changing. So getting the application out the door as soon as possible helps minimize the risk of investing excessive time and money on building something no one wants anymore. Building the simplest thing adds value by thinking more like a business person and less like a religious geek.

Reel Mower by Michael Newman at http://www.flickr.com/photos/mzn37/4001914227/

So what is the simplest thing? Well, that will of course vary depending on your needs. If you code in a test-driven manner, then you’ll need to introduce more initial complexity such as consistently coding dependencies to an interface and using dependency injection in order to support this activity up front. That said, in the real world many teams either lack skills in TDD or choose not to write automated tests for sufficiently simplistic applications. For such teams the simplest thing may involve a more monolithic application that mixes business logic and data access concerns together in the interest of speed and architectural simplicity.

Many variables determine the level of complexity that is justified for a given app including team seniority, timelines, application lifespan, security concerns, and the potential for reuse. Even development speed considerations have merit here – more senior teams may perform best with a logically layered application while more junior teams may find the complexity of a more enterprise level architecture confounding and thus an impediment.

Here’s a quick gut check question to gauge if you’re thinking lean enough: Imagine you’re paying other developers to write code and it’s your company – would you require everything you’re prescribing for this particular situation?

In the third and final part of this series (publishes 1/23), we’ll discuss how to determine when it’s time to introduce additional complexity into the architecture by focusing on the pain.

This discussion just scratches the surface of architectural considerations. To learn more about thinking pragmatically about software architecture, check out my new course “Architecting Applications for the Real World in .NET” on PluralsightArchitecting Applications for the Real World in .NET

David & Goliath: Haswell Ultrabook vs Desktop Replacement Laptop

Okay, so it was only a few months ago I was rambling on about how I am quite happy with my four year old desktop replacement style Dell laptop. It’s been completely reliable, runs cool, has a roomy keyboard, and a native dual monitor dock. I didn’t have much to complain about at the time. In my eyes, laptop technology just hadn’t advanced sufficiently to warrant an upgrade so I decided to keep soldiering on with the beast.

But I’ve begun traveling regularly to speak at development conferences, and the downsides of having a large, heavy, power hungry laptop are becoming increasingly obvious. The never-ending hunt for plugins combined with a power supply roughly the size and weight of a literal brick have convinced me I’m using the wrong tool for a mobile lifestyle. So I decided to take the plunge and see how life feels with nearly the exact opposite: A Haswell Ultrabook. Seeing the two side-by-side is a striking study in contrast.

Yoga 2 Pro and M6400

Decision Made: Lenovo Yoga 2 Pro

My hunt took me through a variety of options that I outlined in my 13″ Haswell Ultrabook Showdown. I ultimately decided the Yoga 2 Pro was a no-brainer to at least try. It’s significantly cheaper than similarly configured alternatives at only $1199 and so far the Yoga has been nothing short of impressive. The contrast with my existing machine is pretty hilarious:

  Dell Precision M6400 Lenovo Yoga 2 Pro
Weight 8.5 3.1
Battery Life 1.5 hrs 6 hrs
Screen Size 17″ 13″
Screen Resolution 1920×1200 3200×1800

Yoga 2 Pro on M6400

The Yoga is the only high DPI 13″ Ultrabook that converts painlessly into a tablet. This initially struck me as a gimmick, but on a screen with such a high DPI, reading is a joy and quickly flipping between creation and consumption modes is a breeze. And converting the machine into a tablet creates a large, but not overly heavy tablet experience. The convertible options create some unique work options that didn’t occur to me until after purchase. For comfort, I really enjoy using a full ergonomic keyboard and mouse when away from my desk. Folding the Yoga’s screen back into “stand mode” offers a very comfortable high DPI work experience. Traditional laptops would require sliding the screen further away from you to allow room for the built in keyboard so the unique convertible format really shines here.

Mobile Ergonomic Workstation

DSC_6114

For a full on “OSHA compliant” level ergonomic setup I simply set a box or luggage under the Yoga to raise the screen to seated eye height. Voila! A complete ergonomic setup while on the go!

And since the screen flips 180 degrees, laying it flat makes it easy to work with while at a standing desk. Yes, I could hook up my larger external monitors, but text looks so much better on the Yoga’s high DPI screen I’m happy choosing quality over quantity when writing or surfing the web.

Standing desk setup

After a few weeks with a high DPI screen, I can’t wait for affordable 60hz 4K screens at desktop sizes.

IE11 Sidebar

As a bit of a sidenote, IE11 has become my new browser for consumption based activities on the Yoga for three simple reasons:

  1. Fast as Chrome
  2. Crisp text on high DPI screens.
  3. Rich touch support

I still prefer Chrome for development tasks due to its rich development tooling, but on these new high DPI touch machines, it’s no contest: IE11 rules. The touch interactivity is buttery smooth, text looks gorgeous, and interactions feel every bit as snappy as Chrome. In fact, IE11 is quite competitive in recent benchmarks. Well done IE team! As someone who does a lot of web development, I couldn’t be more excited to see continued competition in the browser space.

Machines that run this long (around 6 hours) really change how you work. I find I’m more likely to setup shop on the couch since I don’t have to grab a power supply. And when I run to the coffee house to work for the afternoon the only thing I grab is the machine. By the way, the difference in size of the power supplies is pretty hilarious. It’s nearly the difference between a deck of cards and a brick.

Power Supply Comparison

M6400 vs Yoga Pro 2 Power Supply

Now the world isn’t all rosy on the new Yoga. Windows 8.1 does an admirable job scaling to a whopping 200% to support such a high resolution screen, but it’s clear many apps still need to be updated to support scaling. Until they do, expect apps like Photoshop, browser plugins like Lastpass, and various install windows to ignore your scaling settings and thus render ultra-tiny text and icons. It’s occasional and not a deal breaker for me since I can still read these items (admittedly, with some squinting).

I expect the issue to be resolved soon – as more high DPI screens are shipped app developers will have little choice to remain competitive. The same issues occurred for awhile after Apple began shipping Retina displays, so this is a short-term nuisance that will certainly be solved for most popular apps in due time. That said, if you use one of said apps I’d suggest going with a lower resolution screen so you can avoid the need to scale altogether. Or you can just lower the resolution, though that’s a hassle and reduces the razor sharp clarity of the display.

I’ve also found the keyboard to be smaller than ideal, requiring more twisting in my wrists than I prefer. This makes prolonged typing on this keyboard notably less comfortable than my 17″ Dell. It’s a fact of life – smaller screens require narrower keyboards. Excluding the dedicated number pad section, my Dell’s keyboard is 11.25″ wide. The Yoga’s is a full inch tighter at only 10.25″ wide.

Yoga 2 Pro and M6400

So if you have a larger frame or bigger hands, be sure to try out typing in person on whichever laptop you choose. For reference, my favorite keyboard, the Microsoft Sculpt Ergonomic Keyboard is a downright spacious 13″ wide (measured from far left key edge to the enter key).

I’m still toying with docking options. I had hoped to utilize a USB dock like the Pluggable UD-3900, but I found a variety of quirks with using a USB style dock. This is where my Dell excels – the native dock just plain works and runs my dual 1920×1200 24″ Dell Ultrasharp displays effortlessly. Thus, the Ultrabook doesn’t currently serve as my only machine since I strongly prefer coding on large dual screen monitors with a proper ergonomic keyboard. But when traveling and working mobile, it’s an excellent, lightweight compromise that I’m thoroughly enjoying.