JS Interjection

Attending the JS Summit a couple of weeks ago here in San Francisco was a blast! I met many very smart people and came back to the Engine Yard headquarters later that day with a bag full of new ideas and interesting findings from the JavaScript universe. And as a good open-source sport it would be a shame to keep them all to myself. Therefore here it is, my very random list of JS tidbits. At the pace the JS community is currently moving forward better savor them while they’re fresh!

AngularJS - A MVC/MVVM Framework to look at

The space of JS MVC/MVVM frameworks is quite cluttered and to stay up-to-date is a tough task. So in the case you’ve not taken a look at AngularJS yet, head over there now. Similar to Knockout or SproutCore, it uses data-binding to keep models and views in sync and therefore means less things for you to care about! It also appears to be a very robust framework, approaching version 1.0 soon and already being used for several internal projects at no other than your beloved friend Google.

We at Engine Yard definitively put down Angular on the list of things we have on our radar for any future projects.

Oh and of course AngularJS is also featured in the fabulous todomvc project. If you want to see how it compares to all the other MVC/MVVM frameworks out there, or just want to get a general overview of your choices, make sure to check that out.


WebComponents are not a brand new idea but are still in an early draft phase at W3C. They actually consist of two different W3C RFCs: The Shadow DOM and HTML Templates. When you combine those two dudes, the result is simply amazing: Imagine being able to write your own HTML elements or widgets, package everything what is needed for them (HTML, CSS and even event handling JavaScript) together and be able to distribute those elements or widgets without having to even think about any side effects on the pages using them. Example? Sure: What about a calendar widget that you can just use on your page? So instead of having to toss in the right HTML markup, some CSS files and of course the JavaScript to make all the magic happen, you can just load the widget with a simple:

<link rel="components" href="http://example.com/calendar.html">

and then use it like this:

<select is="calendar" name="departure_date" .../>

This all and even more can be done with WebComponents!

Webkit pushed out support for the draft Shadow DOM API last June and I’m sure that as soon as the HTML Template part follows, we will see a lot of movement around WebComponents and a bunch of frameworks out there will make use of this leap in web technology.

You can find a detailed and well written rundown of everything they are here. It’s the damn future, don’t miss it!


Do you know what is going wrong on your site? Oh you say you’re collecting all the exceptions? You even have a nice solution for searching your logs when shit goes wrong? Not bad. But what about JavaScript? Do you get notified whenever something goes wrong on the client-side of your page? No? There is no reason not to anymore!

It is funny that big chunks of the Front-end Guy’s time at any start-up seem to be used up by including metrics and funnel and whatnot analytics scripts on the page to measure even the tiniest bit of available information and make sure no potential customers will be left behind. But when it comes to errors we do not measure, we do not track, we do not send them down a funnel; we are simply not aware that they even have happened as long as we or our QA folks don’t see them. And just to make this clear: the odds are not bad that a single error in some script renders your whole page useless.

If you have gotten a bit nervous by now, don’t worry. There are ways to cope with that and some of them are not even very hard.

First you can register a page-wide error handler by just using window.onerror which is supported by all major modern browsers (a complete list of supported browsers and more useful information can be found at the Opera dev pages). If the lacking support in some ancient browsers scares you there is another solution but you might want to think twice about using it: You can find it in GMail where the Google developers have replaced all of JavaScripts methods with versions that support error logging. A tedious quest, no doubt. But it works. No matter how you solve that problem, detecting errors early will make your application a happier and better place for your customers to be.

That’s it

I hope you liked this peak into the future of client side JavaScript as much as I did enjoy the JS Summit. Thanks again to O’Reilly for putting this event together and stay tuned for more JS hotness as soon as it is served.