| This is perplexing to me. > 1. Bad search ranking and Twitter/Facebook previews This problem is patently obvious to the most cursory examination of single-page applications. If SEO is important, and you want to do an SPA, then you must be willing to bear the cost of addressing HTML requests. For my startup, I wanted to keep things DRY, which lead me early on to the Nustache engine for ASP.NET, allowing me to use the same Mustache templates on server and client. This doesn't have anything like the complexity described in the article. > 2. Flaky stats and monitoring Simply not true. Using Google Analytics and Backbone, you simply listen to the Backbone.history:route event and fire off a pageview using the Google Analytics API. > 3. Slow, complex build tools Complex, yes. Slow? Using r.js, no slower than a typical static language build. > 4. Slow, flaky tests Slow, yes, but no more so than desktop app test automation. I've found PhantomJS with QUnit (unit-testing), and CasperJS for integration testing to be quite reliable. It took a few days to get everything connected (scripting IIS Express to start and end in the background being the trickiest bit), but that was it. > 5. Slowness is swept under the rug, not addressed This is a UX challenge that is known and obvious up-front. Failing to address it is a design problem, not a technological one. Overall, this seems the result of the ineptitude prevalent in inexperienced, "move fast, break things" teams. Rather than owning up to moving too fast and foregoing due analysis/research, they blame technology. Or, the article is a marketing ploy. |