> 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.
This a thousand times. I read the article and thought it a little weak on perspective. I've used Mustache+Backbone+Require.js stack like the one you're alluding to and it worked quite well together.
> 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.