The gulf between web site and web app has never been so severed. At one end, there’s a stateless informative web page, at the other, a fully fledged, rich, interactive and stateful application. They both can benefit from the same magic ingredients of HTML, CSS and JavaScript, but depending on your (user) needs, you can adjust the potency to suit.

The right flavour?
For an event that’s grown over the past three years (dubbed “… one of the globe’s foremost conferences for web designers and developers”), I’m a little disappointed at the overall lack of useful technical information for developers. It needed more chili, more hot-stuff. Yes, there is a conflict of interest between designers and developers; perhaps this is something to consider when organising such an event. I attended Future of Web Apps earlier this year, which in comparison contained more cowbell than I saw at my @media debut. Personally, @media lacked inspiration and insight for me as a developer. A little bland.
Tasty – JavaScript with Yahoo!
I’m definitely a JavaScript nut. Yahoo’s openness about OO JavaScript and best practices have influenced the way I develop my JavaScript; understating both its limitless potential and inherent pitfalls. Nate Koechley is one of the Yahoo champions and I was happy to hear him speak at the conference. Nate gave us 12 rules on how to increase site performance (based on testing carried out at Yahoo), which will be discussed in detail back @ the office.
Bones to pick – web applications built on JavaScript?
Jeremy Keith made his point that JavaScript/CSS isn’t the right technology for building a web application, in comparison to something like Flash or Apollo. Google Maps/Mail/Calendar/Docs & Spreadsheets, YAHOO Pipes, Flickr (organiser) and myself totally disagree. The support for JavaScript is ever increasing, browsers are improving and the forementioned web applications have reached mainstream proportions. There’s no denying they’re doing something right – all with technologies natively supported by the browsers.
Aftertaste – unit testing JavaScript?
Dan Webb raised some questionable points about testing JavaScript. He recommended Selenium, an end-to-end testing tool for automating browser testing. He said “… Selenium can be used for testing your JavaScript…”, where really it’s for testing your UI workflow that might not rely on JavaScript (e.g. form completion and tab order). Also, he stated there is no need for unit testing JavaScript (i.e. with JsUnit) – if you felt the need to do this then your code is doing too much.
First point, APIs such as the YUI library are cases for unit testing, along with useful formatting/utility methods you create for your project (e.g. you might have a wrapper DOM method that can be tested standalone). Secondly, if your JavaScript is so simple that it doesn’t require unit testing, then Selenium would also be overkill for testing. Selenium is a powerful tool, but setting up regression scripts consumes time upfront and for maintenance. JSUnit is a fantastic port of Java’s JUnit; if you write good modular code then you can definitely unit test it. When your JavaScript code is UI workflow specific, then Selenium is the way to go (providing resource allows it).
@hh…
So, a few things to think about after the conference. The mushroom curry (day two) was spot on, along with the berry dessert.