I didn't believe I would've ever said that, but on March I attended the Microsoft Days 2012 here in Sofia. Read my thoughts on the lectures, but bare in mind that they are strongly affected by my web personality.

There are fundamental differences of how traditional and web applications work. I found that describing all the specifics, processes and tendencies of web development to hard programmers can be a challenging task.

In May 2010, the (now former) Google employee Brad Neuberg gave an amazing presentation about the new and emerging technologies in web development. Invest these 50 minutes and watch the video if you still feel that HTML5 and CSS3 are only buzzwords and do not yet know what has already come in the field of web development. This article contains the video, a short list of the features Brad has mentioned in it and the most memorable conclusions.

There are two ways to look at the Object-oriented programming when it comes to JavaScript. The first one is to think in terms of classes and instances (the classical OOP), and the second one - only in terms of objects (the prototypal OOP).

In this article I've made an attempt to explain the classical OOP paradigm using a lot of examples (the most of them influenced by the Pro JavaScript Design Patterns book). How can you make a class, public and private members, static and instance methods, and how can you emulate inheritance?

One of the best places I've ever seen to learn advanced JavaScript is on ejohn.org. There are several reasons for it, but what I want to mention here is the first slide (after the summary). Our goal! Determining a goal for your audience is the best way to draw attention to the end of any presentation. In this case the effect is even bigger because the audience will have found out till the end of the introduction whether the information is relevant to them, thus whether they are interested to listen / read.

I am amazed how many lecturers failed to do that simple trick and therefore lose connection with the audience.

Let me first make this clear: each time you fix something for a certain browser, you are not applying progressive enhancement. Progressive enhancement is all about building for the less capable first and enhance the experience for those using the latest modern browsers. So, any type of fixes are useless. If you use fixes, you might be applying graceful degradation or, more likely, you may just be hacking around in order to workaround the differences across the browsers and to make everything look and feel the same.

One of the great features of html5 is the new semantic tags. Like section, article, aside, footer, etc. Let's see how we can build a new layout using them. First of all, we have to make them block-level elements with css since they will behave as inline in each browser that do not understand them. So we fix the fact that these browsers do not support html5 semantic tags. Oops, I used the word fix, that's an indication we're not applying progressive enhancement. Ok, that's a tiny little fix so we can ignore it. Now, another obstacle is that Internet Explorer cannot apply a style to elements it doesn't know. So we're using the html5 shiv to create the elements in the DOM Tree and to fix this bug in IE. Oops, another fix. I'm not going to continue, I believe you get my point.

Ok, but what about the degradation of our future highly semantic markup? When you apply these fixes, another issue to worry about is what happens on browsers that do not support css. All these block-level elements becomes inline and the page looks messy (remember the idea of the CSS Naked Day?) The same way as if you use only spans to build the layout. Or what happens to IE with JavaScript turned off. It still cannot see the styles related to the new elements. So, our degradation is obviously not graceful, it is, to be honest, painful to watch.

The fact is, html, no matter which version, is not related to the user experience in any way on a given web page. It describes the data on the web, it marks it up. That's it. No visualization, no behavior. So, how can we build html5 layouts using progressive enhancement? Which is the basic technology we can use before it to assure wide support? Yup, there isn't any. Of course, we can build our layouts in the old way, but then we are not really using html5, only these features that work across the different browsers, like the short doctype, short charset, etc. That's a kind of compromise, it's neither progressive enhancement nor graceful degradation.

A great example of html5 and graceful degradation is Video for Everybody! on camendesign.com. It uses html5 video features, then it fails to QuickTime if your browser is not aware of html5, then it fails to flash, then it fails to image. But can't we reverse the process? Can't we build for the one that is unable to see video by any mean and then add flash, QuickTime and in the end - html5? I think it cannot be done right now, but it's still a not explored field. I might be wrong...

Go to http://www.youtube.com/html5, click on Join the HTML5 Beta link and search for a video. You have to use a web browser that supports the html5 video tag and the youtube video format, which pretty much limits you to Safari 4 or Chrome 4 by the time this article is published (Update: Firefox 4 is now on the list).

Eric Meyer demonstrates an interesting flexibility when html5 is used instead of flash.