@media 2008: From Scaffolding Or From Scratch?
I was possibly a little brighter eyed than many attendees this morning as I had missed the @media party in order to take my daughter to see the musical Wicked (which was very good incidentally), so arrived at the venue in good time to get front row seats for Nate Koechley‘s keynote, “Professional Front-End Engineering”. In the last couple of years I feel that we have seen a rise of the front-end developer as a specialist in their own right, and Nate discussed some of the ways in which people with this job function could improve their skills to become, “tireless trendsetters of quality”. Nate also talked about working at Yahoo! and some of the things they had discovered there, such as the fact that using @import for CSS creates a performance hit as the imported stylesheet is loaded last of all and the page isn’t loaded until it is. The effect being the same as if you had a linked stylesheet just before the closing body tag.
In the final session before lunch I moved over to the alternative track in order to hear Marc Pacheco talk about the redesign of The Guardian newspaper website and Matt Biddulph on Dopplr. Marc explained how The Guardian has over 500K of CSS, which is difficult to maintain. This is a subject I have talked about before at @media on a Panel two years ago and is a problem that isn’t solved yet. A complex site with a lot of CSS quickly becomes very difficult to maintain. One thing The Guardian do is to have lots of separate files during development time – splitting out colors, grids and so on, these files are then combined back into one large file as part of the build and deployment process. This means that they have the convenience of separate files for development but don’t take a performance hit because of them once live. He also mentioned another problem that we have encountered, which is that merging files with Subversion doesn’t work well for CSS, and you can easily find rules merged together that should not be with surprising results.
Matt’s talk about Dopplr, a social network for frequent travelers, highlighted some of the interesting ways in which they are using other APIs to add to the data that they already hold. Dopplr didn’t try to replicate functionality that people already have with other social networks and so have functionality such as the ability for travelers to link their Flickr photostream with their trip information, as opposed to building their own photo gallery application. This approach is really helpful for anyone planning to build a new web application – decide what it is that you do and concentrate on that, then use the APIs from other applications to enable people to link together their various profiles and data. This really followed on from some of the things that Jonathan Snook had discussed earlier in the day.
After lunch was my own panel, the other panelists hoped I would give us a glowing review – or perhaps that I should review the audience at this point. Our topic was, “Communicating Best Practices” and the panel was chaired by Paul Boag with backing vocalists being Murray Rowan, Patrick H. Lauke and myself. Between us we have experience ranging from large corporates, in-house development in an academic environment and small business, so I hope that we managed to give a reasonable overview of the ways in which we can communicate and use best practices in the different ways we work. I think we were all quite well behaved as were the audience – those I could see through the lights anyway!
After my panel I could at last relax and enjoy the rest of the day. We were followed in the alternative track by James Adam and Simon Willison, who were talking about Ruby on Rails and Django respectively in a session named, “Exploring the Server Side”. James took us through a quick example of Rails – doing a live coding demonstration using scaffolding, and then Simon showed us the ease with which Django could be used to replicate the @media 2008 website. While James’ live coding was certainly brave (I can barely speak in front of an audience without having to code as well) I felt that people became side-tracked by the obviously crufty mark-up generated by scaffolding. At a conference where web standards and unobtrusive scripting techniques are high on the agenda it might have been better to avoid using the scaffolding approach, as impressive as it may be in terms of the speed it can be used to generate pages. Creating pages quickly is all well and good, but if those pages aren’t production ready – is it actually helpful? That is a topic for a different blog post entirely however! I’m not a Django user or a Python coder but I enjoyed Simon’s demonstration and it left me feeling that I’d like to have a play with Django and see how easy it is to get a site up and running with it. One question raised at the end was how easy it was to get hosting for Rails or Django, hosting is one reason that my company has stayed with PHP – we like to be able to give people applications that will be really easy to host and move if there is a problem with a host, however it sounds as if in the last year or so there have been more options available for hosting Rails and Django. Certainly both have excellent communities so there should be help out there if you are looking for hosting.
Once again the day was rounded off with a Hot Topics Panel, focussing on development. The panelists being Steve Faulkner, Simon Willison, Jonathan Snook, Nate Koechley with Matt Biddulph as chair. There was again a rousing defense of the front-end developer as a serious engineer from Simon Willison, and a little titbit mentioned by Nate was that IE6 has now been overtaken by IE7 in the Yahoo! logs.