My Problem With Javascript-only Apps

I love Javascript. I code almost exclusively using Javascript. My startup’s entire stack is Javascript (MongoDB + Node + jQuery + Hand-rolled front-end libs).

But I hate apps that require Javascript to load content. I’m looking at you Backbone.js/AngularJS/Ember.js.

I understand that the increasing speeds of SpiderMonkey and V8 (and even Chakra) have turned the web into a place where you can build client-side web apps with much richer functionality. And I understand why that has led us to more and more “single-page” apps that load additional data and render it using on-page templates.

What I don’t understand is a reliance on Javascript to load content. Not rich functionality, not drag-n-drop WYSIWYG editing, not even AJAX-y autocompletions, but plain old content. And not just as the primary choice to provide snappy responses once the page has been loaded once, but the only way to load content.

Earlier today, I was checking out the popular article on Hacker News about Ember.js’s Quick Start shortcomings. It was a forum post on the new Discourse platform from the Stack Exchange folks, which was itself built on Ember.js.

Here’s what I saw:


A blank page.

I checked the errors, and it looks like something failed to load.

When I checked the source, I see that Discourse has some nice backwards-compatibility for people that don’t have Javascript enabled – they include the entire rendered HTML page in the <noscript> tags. But for those of us that have javascript enabled, but for whatever reason it doesn’t load properly? No forum for you.

The irony to me, is when looking at Discourse’s about page:

The state of forums has been unchanged for so long that forums are considered unworkable and undesirable; few sites want forums any more because the software is so poor.

In my book, those old forums worked, as ugly as they were, and working and ugly is better than pretty and not working. All your fancy live-updates, inline editing, etc, simply don’t matter when the content doesn’t load. As has been said a million times before, Content Is King.

I don’t mean to pick on Discourse here. They built what is I’m sure a great product, which is itself built on a great framework by very smart people.

The problem is in the assumption that rich functionality and traditional HTML rendering have to be divorced. That if we want all the fancy rich-client stuff, we can't deliver rendered content to the client, we must render content client-side.

I don’t think that’s true. I think you can build apps that deliver rendered HTML content to the browser, and add rich functionality on top of that, hopefully with appropriate fallbacks for the most important actions.

Doing so provides a number of benefits:

  • Faster startup time - “Time to first tweet” is Twitter’s benchmark, and the best way to ace such a benchmark is by delivering rendered HTML to the browser on first page load
  • Graceful failure - No blank screens like that I one I got today at
  • Search engine friendliness - The big crawlers are supposedly going to get better at rendering Javascript to index pages, but why would you make it harder to index your site?
  • Smaller payloads - With Discourse’s noscript tags, they are delivering both the data and the templates to the user’s browser twice

When building a true app, one in which the functionality instead of the content is most important, the exclusive reliance on client-side Javascript makes sense. But any web app for which content plays an important role, loading that content with Javascript is the wrong choice.