What Happened at Throne of JS
By Eric FerraiuoloJuly 30th, 2012
A couple of weekends ago I packed up my laptop and my horns and headed over the border to lovely Toronto to play Devil’s Advocate at the Throne of JS conference. This conference was different in that it focused solely on JavaScript MVC (or MV* if you will) libraries/frameworks and using them to build rich, dynamic web apps. I know what you’re thinking, seems like a perfect venue to promote YUI and specifically the App Framework components, right? While I could have done that, I decided to instead discuss the main premise of the entire conference:
“It’s no longer good enough to build web apps around full page loads then progressively enhance them to behave more dynamically. Building apps which are fast, responsive and modern require you to completely rethink your approach.” [emphesis added] – Throne of JS
We all want fast, responsive and modern web apps, but to build them, do we really have to give up progressive enhancement and completely rethink our approach to web development? I think that utilizing both the client and server in a coordinated way is a modern approach—by leveraging JavaScript in the browser to provide the responsiveness and the server to provide the fastest initial rendering of your app. Having this balance, instead of doing everything on the server or everything on the client, means work can be done in the most optimal place and hopefully provide a better experience for the user. Here are my slides from my talk which go into more detail:
Also, all the sessions were recorded, so you can watch and listen to my talk!
Being able to spend a whole weekend geeking out about JavaScript MVC with application developers and library/framework authors lead to many invaluable conversations. Oh, and that everyone wants data-binding, and it’s extremely difficult to implement correctly :).
I had a great time at the conference and visiting Toronto (which seems to be massively expanding!). I want to thank all the attendees and the other speakers for making the conference so great, and special thanks goes out to Meghann Millard, Justin Giancola, and the Unspace crew for organizing the whole thing.
July 31, 2012 at 5:18 am
IMHO progressive enhancement is a complete misuderstanding. JavaScript is part of the webstack, the only reason progressive enhancement still lives, is the search engines inability to index sites that render with javascript.
So much potential has been lost due to that, let’s move on and ditch progressive enhancement.
July 31, 2012 at 6:00 am
Allan,
Whether you subscribe to a progressive enhancement strategy (and how far you go with it) should be evaluated on a case-by-case basis. When the data for your application is inherently public and if you live in the world we’re in today, you’ll want to have server side rendering support, otherwise your business could suffer. The amount of extra computation work search engines would have to do to execute JavaScript would be huge. I’m doubtful that they can justify the cost for current gain.
If you’re building an app which has inherently private data and users must sign in, then I feel that you have more affordances for doing everything on the client. But, if you’re looking to have the best user experience (over everything else, including time to developer time), your app will be faster if you use the server perform the initial rendering. This way users can start seeing and consuming data while the JavaScript in the browser is still booting up. Think about how much nicer Gmail would feel if you could start reading your email right away, instead of staring at the blue loading bar.