Website and UI

Are Single Page Applications (SPAs) for everybody and everything?

Take a look at these two statements. Which is true?

  • “To say that SPA development is the future is an extreme understatement.”
  • “SPAs are how some of the best applications on the Web offer fluid UX and responsiveness, while minimizing payloads and round-trips to the server.”

The interesting thing is, both of these are from the same article (March 2014 MSDN Magazine). I think the second statement is demonstrably true – but the first statement is an exaggeration. Over time Single Page Applications (SPAs) will become ONE way of writing applications – maybe even the default way – but far from the only way. And it’s safe to say that the way we write SPAs now will change dramatically over the next five years. Let me explain why.

Migrations are usually gradual

If you’re starting from scratch, a SPA is a great way to go. However, the typical migration I see in the enterprise isn’t all at once, but more of a shallow-end-of-the-pool kind of adoption that allows teams to grow into client-side development:

  • An existing Webforms app starts to use some Javascript/jQuery functionality.
  • Over time, this becomes more complex and more jQuery plugins start appearing, where jQuery/JS usage starts significantly changing the page structure
  • Pieces or the entire application starts migrating to the MVC framework for communicating with the server and presenting views
  • The app starts becoming a mini-SPA. Most pieces are still served up using views/controllers, but some critical pathways are served up client-side with asynchronous data requests. This is done one baby step at a time, and most of the application remains straight up MVC/webforms.
  • Migration to full SPA. There’s a login and a forgot password request page, but all other client interactions are handled within a SPA framework.

Why is this?

SPAs aren’t a silver bullet for your development woes

Too often we don’t take into account the maturity or size of a development team in making architecture recommendations. For example, a while ago I was involved in a development effort where the team looked at SPAs/WebAPI and abandoned it as “too expensive”, in favor of a prototype approach with ASP.NET webforms. Seeing as how we had a very crude SDLC and a nonexistent peer/code review and release management strategy, I had to agree with this decision. Maturity wise, the team wasn’t where we could have leveraged the best aspects of MVVM and AngularJS – we just didn’t have the pieces in place without a team commitment to testing, reuse and code quality. It’s pointless to make the leap to client-side development without taking care of the essentials first.

No one is arguing here that client-side JS frontend doesn’t offer a potentially fantastic Ux experience and more maintainable/testable code in the long run. The downside is a very sharp learning curve, sometimes spotty documentation, and a plethora of rapidly changing JS libraries to choose from. If the dev team has only MVC/webform experience, you’ll need to invest in specific training and experience, and the tooling for JS libraries is not nearly as good as what you can get with webforms/MVC. It’s well worth it – if you are able to accept those costs and commit to the longer ramp-up that implies.

Not all applications will fit the SPA model

I don’t feel that all applications need or should be SPAs. If you’re writing an app that will have most of the heavy lifting done server-side with a sprinkling of jQuery/JS, going to a MV* framework could be overkill. If the app design calls for a lot of data manipulation and presentation happening browser-side – for example an app that could download all the scripts, styles and markup a client could need in one payload and then perform additional behavior in the background – well, that’s a SPA. In that case a JS MV* framework will pay off.

What’s the future?

As we’ve grown from classic icky ASP => ASP.NET webforms => MVC => SPAs with MVVM, each time we’re refining our approaches and the challenges have made us better programmers. So, this is a sea change – thinking in terms of a rich UI and the user experience. Even for internal apps – users now have an elevated set of expectations from Ux-forward apps they use on their tablets and smart-phones. We have to embrace this change, with both arms. It’s no longer about Java vs C#/.NET, Eclipse vs Visual Studio. JS and the client experience will hold sway. I’m thinking in the next few years we’ll see MSFT really fill in the gaps when it comes to JS development tooling – we already are with the 4.5 release

I remember when XML came out, and then MVC – there was a kind of sharp “everything we have must be converted to this now” reaction, followed by a reset where it became a new tool in our library. I think SPAs will follow the same path, where they’ll be used sometimes, where appropriate – where Ux is king, where the dev team can handle it, and where everything can be done client-side.

Maybe you agree with this – maybe you don’t. And as I continue exploring AngularJS and other frameworks maybe I’ll change my mind and talk about how foolish I was in my prophecies. More importantly, maybe the market will disagree – and agree more with the author at the start of this writeup about SPAs being the future, the be-all, the everything. In that case, maybe 80-90% of the code we’ll be writing in six years will be JS – and some new way-cool JS library, the great-great-grandkid of AngularJS, will rule supreme. But for now, I’m going to advocate with my clients a really careful look at what the SPA frameworks they’re looking at can deliver – and whether the benefits of that client-side emphasis outweighs the disadvantages of a rapidly-morphing paradigm.


 Resource Links:




MVC best practices – quick thought

A great article from the redoubtable Dino Esposito on best practices for MVC apps. Shockingly, he advocates weighing the pros and cons of Bootstrap before adopting it. His points are logical – you’re not writing pure HTML, any more than writing jQuery and calling it “javascript” – but I’m not sure if there’s as big of a downside as he thinks. Maybe for a more mobile-targeted display the content sizes would be an issue.

IE incompatibility notes

Quick post for the day. We had an issue where the site was rendering great in IE and Chrome locally, but when we promoted it out – kablooey! How to fix?

Checking the client browser mode (and using IE’s dev tools) showed that our default browser mode settings were to IE7. (Not sure why this was, but it’s part of our awesome standard config evidently). Edge setting (or the most recent, a la Chrome) would be more correct. So, in the header, try this tag:

<meta http-equiv=”X-UA-Compatible” content=”IE=edge”>

Explorations with Azure – knocking out a pilot website in about two hours.

So recently I was asked to put together a pilot website for a friend who’s not super tech-savvy. His business may or may not ever get off the ground; like most of us he’s wanting to float something out there and see if it goes somewhere. An internet storefront seemed like a great place to start.

OK, so after the requisite weeks of haggling over the name, I scaffolded out a site and posted it on Azure. I’m happy to announce that the site is awesome, very responsive – and best of all, free. It’s a VERY good use case for what Azure does very well – quick ramp-up sites that may or may not see full-size production traffic.

My first step was to create a Visual Studio Online project. This was simple – see below:

Following this I opened up the project in Visual Studio 2013. I had to map the workspace and pull down the code – in this case it was empty – before we could see our old friend Source Control Explorer.

Now, to work. I clicked, File, New Project, and selected ASP.NET Web Application. I selected Application Insights and synched it up with my new account.


I used the MVC option as my main option – but also added WebForms and WebAPI in case I want to tack them on in the future. Now, I’ve got a set of code available – that I can see is ready to be checked in. Right mouse click that baby and check in the code!


Back to your Azure account. Click on New Web Site and select the Custom Create option. I entered in my desired URL and a bare-bones SQL option – and, this is important, selected the Publish From Source Control option.

Selecting that option took me to the authorize connection screen in Azure, where I synched up my sourcecode with the new Azure website that was being spun up. Select the Authorize Now option here.

Once I did this, it took me back to Visual Studio 2013 – where a publish profile was ready to go for me. I skipped through the now-familiar Profile -> Connection -> Settings -> Preview steps – they were all set up nicely by the Azure publish profile – and clicked Publish.


… and, my site was published – lickity split. I could view it on stonefly. I also get all that cool less-is-more Azure dashboarding, showing requests/response time:

Best of all, I now have my site up and my code available in a repository that I can access anywhere. Feel free to check it out. No need to walk around with thumbdrives anymore. And, there’s something about building out a demo site quick and cheaply like this that appeals to me. Add to it that my TFSOnline account was free – yes, free (if MSFT ever changes that I could move over to GitHub) – and the case for handling this in Azure versus going all-out and spinning it up on or the like becomes pretty compelling. This is enough for my friend to evaluate and decide on next steps. Sprinkle in some HTML and CSS, and suddenly we’ve got ourselves a going concern:

Now, I could buy a DNS address (like, I don’t know, stoneflysoftware.azu or the like) and register it with Azure. But I probably won’t. As you can see from this site, it ain’t cheap – we’re talking $56/month for basic, which is a great deal if you have 6 or more sites you’d like to host, or you need true geodistributed 99.9% HA coverage on your site. Scott Hanselman has a whole series of articles on pennypinching with Azure that I’d recommend, including this nifty video on using Azure as a CDN.



Theming It Up! I love you Bootstrap, never leave me alone again…


So, here’s my “second version” of my site. Using plain vanilla Bootstrap. Barf, urf, yuck.

How do I kinda beef this up look-wise without spending half a lifetime in CSS-land?

Well, I tried using some of the free Metro themes. And, it looked… better but still really plain.


So, cough up $10 or so and get a professional’s assistance. I went through probably about 20 designs and ended up setting – for the bargain-basement price of $8 – on the Atropos theme. (It just looked a little more professional than the 2nd place winner, Flanzo – if I wanted something a little more forward-looking I would have gone with Clean or – something I really like in terms of look – Smart.

Anyway I just took the embedded HTML assets – which are actually nicely organized – and dropped them into my root folder and built it. Stripped out some pieces piece by piece and – looky here!


I’m not a UX expert – that’s a legitimate and very-little understood specialty – and I don’t like pretending to be one. Paying an expert a few bucks to pop together a great looking site, where I can drop in some simple HTML – and have it work on any device, FAST, is a great plus.

Still looking for UX ideas? A friend put together a GREAT looking site – again using Bootstrap – here: – feel free to give that a look. That’s a clean user interface, and it looks GREAT on a mobile device.


Themes I looked through