The "Development Drawbacks" of JavaScript Web Applications

August 08, 2013
web apps

With the advent of client-side application frameworks like Ember, Angular, and Backbone, there is a growing split in the web development community. A number of developers have dug in their heels against moving substantial application logic into JavaScript, and would prefer that servers continue to render as much HTML as possible. In the release notes for Rails 4, David Heinemeier Hansson declared that "a big focus has been on making it dead simple to build modern web applications that are screaming fast without needing to go the client-side JS/JSON server route". He went on to describe one of the new features, Turbolinks, as able to "essentially turn your app into a single-page javascript application in terms of speed, but with none of the developmental drawbacks".

I'd like to take a look at some of these perceived drawbacks and offer some counterpoints.

Language preference

Language Preference

Of course, we've only got one realistic language choice in the browser: JavaScript. If you prefer Ruby (or Python or Java or C#) over JavaScript, you may favor keeping as much of your application on the server as possible based on "developer happiness".

I agree that's an important metric, but let's face it: JavaScript simply can't be avoided when writing modern web applications. Instead of sprinkling jQuery snippets throughout your application in an effort to make it more "dynamic", you'll be much better off if you fully understand and embrace the JavaScript language.

Thanks to the efforts of TC39, JavaScript is actively being improved. You may be pleasantly surprised by some of the features coming in ES6, the next version of JavaScript. If you really can't stomach curly braces, give CoffeeScript a try. I should add that, in my consulting experience, I've noticed a trend towards front or back end specialization, especially on larger teams. If you strongly favor one or the other, you may not need to "wear all the hats" on a project.



It's often argued that writing a client-side application paired with a backend API is substantially more complex than an equivalent server-rendered application. While that may be true in launching a minimum viable product, any time-to-launch advantages will probably dissipate as your service matures. In his criticism of client-side MVC, Thomas Fuchs claims that "what you end up with is building a layer cake that doesn’t add any value and slows down development."

I've found the opposite to be true: a strongly dilineated architecture benefits applications in the short and long run. By developing your front and back ends simultaneously, you can virtually guarantee that your service will have a useful and robust API, even at v1. And with an API as a firewall between front and back end code you'll gain discipline that will clarify architectural decisions and leave you with very little duplication of functionality across your stack.

Time to Load

Time to Load

An oft-cited problem with client-side applications is the time to download and initialize on page load. The total size of many JavaScript applications, including framework code, is typically the size of one or two JPEGs, and often is less than the total JavaScript downloaded on traditional web pages once all the miscellaneous plugins are added up. That's not to say that this is a non-issue: client-side applications typically don't display anything to users until they've been fully downloaded and initialized.

What's the answer? Start by delivering your assets as quickly as possible with a CDN. Consider splitting up larger applications into modules that can be progressively loaded as needed. This is possible in Ember, for instance, now that the router supports asynchronous loading of routes.



Although search crawlers don't yet automatically process JavaScript web applications, it's actually not that difficult to ensure that your public facing content will be searchable. Google provides a spec for making dynamically created content visible to crawlers, which Alex MacCaw discusses in his post SEO in JS Web Apps. Also check out SeoJs, which relies on PhantomJS to crawl your dynamic site and provide static indexable content to search spiders.

Primitive Browser Compability

Primitive browser

This criticism is obvious: if you want your site to work without JavaScript, you'll need to create a version that is not entirely dependent upon JavaScript. The only way to make this happen is with redundant development of a simplified static site.

Of course, a large majority of server-rendered sites are also heavily dependent on JavaScript and face similar challenges to work with scriptless browsers. But then again, it's become so rare and undesirable to disable JavaScript that the option has been obfuscated in the upcoming v23 of Firefox.



While some screen readers don't work with JavaScript generated content, Apple's VoiceOver does a pretty decent job regardless of where the markup was created. You can try it out in OS X simply by pressing ⌘ + F5 in your browser.

Going further, the W3C's WAI-ARIA spec aims to make dynamic content more accessible to people with disabilities. By adding custom role and aria-* attributes to elements, combined with semantic structure, you can provide guidance to improve how content is presented by VoiceOver and other sophisticated screen readers.

Similar Appearance

Similar appearance

Another charge that Thomas Fuchs levels is that "if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same (many people choose using Twitter’s Bootstrap library, for example)".

I'm not sure where this originated, but it is not unlike claiming that all Rails applications look the same. As a frequent user of and contributor to Ember, I can assure Thomas (and everyone else) that Ember applications are in no way tied to a particular style or user experience. Peruse popular Ember apps like Discourse, Yapp, Zendesk, and Square to see for yourself.

I realize that this post may seem a bit defensive, but I think it's important to not let claims go unchecked. I've personally been working with Ember.js for the past 20 months and couldn't be happier with my choice for the applications I've been developing. While some aspects of development have been more challenging, I think the pros far outweigh the cons for many types of applications.

Stay tuned for a post that can help clarify this decision for your application...