From today's post to Baldur Bjarnason's blog:

We might have a project that has a limited budget and resources but also a user-base that isn’t demanding the Single-Page-App ‘experience’. In which case, the logical approach is to make a multi-page web service instead of a Single Page App. It’ll cost less both in the short term and the long term. And you’re much more likely to be able to deliver it on time.

But you almost never get to do that these days because only a Single-Page-App is a ‘proper’ website. An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence. I must be arguing against an Single-Page-App because I don’t know how to make one.

Framework authors... frequently make this situation worse. ... They argue that a ‘properly’ made Single-Page-App won’t have the accessibility and correctness bugs that frequently plague many of the Single-Page-Apps you see in the wild.

The problem is that doing a Single-Page-App ‘properly’ is even more expensive than doing a mediocre Single-Page-App, which in turn is considerably more expensive than an old-style multi-page web service. If a lack of resources is the limiting factor for the project, any suggestion that involves more work or more resources makes the problem worse.

What we end up with is an industry plagued with cost and time overruns. ... Because everybody wants to do ‘proper’ web development and nobody wants to adjust their expectations of what can be accomplished with their resources to something more realistic.

Long quote, sorry. 100% accurate.

I keep wondering why teams can't hit the old, Classic ASP scheduling rule of thumb we had back in the 20th century: One dev, one data entry page (with QA & dbms access!), two days.

Today, with the groups I've worked with on SPAs, we're nowhere close.

Part of it is quality of developers -- it's the Michael Jordan syndrome. While a GM, Jordan seemed to think players would unlock as much of their potential as he did his, so that's the way he drafted or traded, for potential. Didn't work out that well. 

Too many architects and technical decision makers think, "I can understand it," or "The internet suggests a dev should be able to do this." Both are followed by, "If you can't, it's your problem. We need better devs." Better devs would be great! Of course, the cost, even the simple feasibility, of finding, recruiting, hiring, training, and retaining those devs gets ignored. Worse, a stack that fits their devs better than a SPA never enters their minds. Or, when you suggest it, you get the same response Baldur describes.

And that's the contributor to slow development: We're using the wrong tools for our current devs.

If you've got all championship coders (which, I should add, are usually much different folks than championship NBA players, but there is some overlap -- well paid, trusted), make a great SPA.

If you've got bog standard devs from outside the Valley, it might be time to do something simpler as long as your use case says you can.

Labels: development, spa