I will use the term hard programmers here to describe people with background in server-side development and compiled languages like C++ and Java, who have never been involved in real web development. I first stumbled across this term when I was reading the book ppk on JavaScript.

Being surrounded by hard programmers myself, I found that describing all the specifics, processes and tendencies of web development to them is a challenging task. There are fundamental differences how traditional and web applications work. If you do not believe me, look at two questions that looks akward for web professionals, but are commonly asked by hard programmers:

• When will HTML5 be ready?
• Is it possible to use HTML5 and CSS3 when the browsers do not support it?

There are many variants of these questions, but basically, all of them regard the lack of features in browsers, something that web professionals know how to overcome. Hard programmers, however, do not face such a problem in other environments, where something either is working and can be used, or is not working and cannot be used at all.

So here are several points you should mention in front of hard programmers to explain how the Web works:

HTML5 and CSS3 are modular - each module has a separate life

What modular means in this case is that there are separate specifications for the different features and each of them is in different state (draft, recommendation, etc). Same goes for the implementations. While one feature may be very popular in mass media and thus implemented well even in early draft (2D Transformation being a good example), other may lack support in any browser today.

Having in mind the big competition between the browser vendors, waiting for all the specifications to become recommendations is not possible. Moreover, no one knows what "all the specifications" means. A new draft, for example, may be released tomorrow. This is an ongoing process. New features are continuously proposed. Not believing again? Look at css4 selectors, Fullscreen API, or the proposition about simplifying element creation.

This environment differs from Java SE, for example. When JDK 7 is released, you have all the features ready to be used. No partial implementations, no hacks to triggers a feature, no vendor prefixes.

Web apps do not need to behave the same in each platform

If this or this are not enough for you, here are some additional arguments in a form of examples:

• The Google Docs application has an offline mode. Does it work in old browsers? No. Does Google care? No. The core functionality - to work online with documents, is always there. The offline mode is an enhancement for users that use modern browsers.
• Twitter home page uses many CSS3 effects (shadows, rounded corners, opacity). Do these effects work in old browsers? No. Does Twitter care? No. The core functionality - to identify the brand and to log-in/register is always there. CSS3 is only an enhancement for users that use modern browsers.

Building applications with basic technologies while enhancing with features for advanced browsers is a tendency in web development which will never vanish. Hard programmers get to this paradigm very slow because there is no analogy with traditional application development, where everything should work the same in each platform.

Paul Boag has made a great document on how to explain the need of progressive enhancement to our clients. This might very well work for hard programmers too.

JavaScript is dynamic - it can implement features that lack support

An example that I really like because it shows the conceptional differences between JavaScript and other languages hard programmers are used to, is the following: in Java, you cannot use generics if you want to compile in Java 4. And you cannot define it. In JavaScript, you can implement generics in a browser that do not support it and still use it.

For a real example, localStorage can be implemented on top of other storage mechanisms that is available in the browser (IE userData, Flash Shared Object, Cookies...). And you will still use the localStorage API as if it is available in the browser.

For a concrete application, see diagram.ly, which relies on SVG, but also works in IE7.

HTML and CSS are not programming languages, but it helps to treat them as if they are

Although hard programmers are aware of the best practices to write source code, my observations on their markup and front-end code are discouraging. They copy-paste a lot of HTML, CSS and JavaScript handlers written directly in the markup and they don't have any clue that this code should also be organized or that some principles should be followed.

If you are a web professional who has to work with hard programmers, explain to them that HTML and CSS are also source code and make them think about these technologies as programming languages. That may help to trigger some sense to follow best practices.

Final Note

I recently helped my colleague Plamen Todorov to create this excellent presentation about why should we care about html5, css3 and JavaScript. Since Plamen is more concentrated on JavaScript, there are less arguments and links for html5 and css3, but still it's a very strong research regarding the latest tendencies.

In May 2010, the (now former) Google employee Brad Neuberg gave an amazing presentation about the new and emerging technologies in web development. The name of the topic is HTML5 and the Future of the Web, but don't let this title fool you - it's not dedicated only to HTML5 but also to CSS3, SVG and the new JavaScript APIs. According to Brad:

HTML5 = Next Generation Features for Modern Web Development

Fortunately, a high quality video is uploaded on youtube. Although May 2010 is now way behind us, this video is still a brilliant overview of what's going on today. Before seeing it, I didn't believed that someone can explain all this stuff in less than an hour, but Brad proved me wrong. And he did it with style.

Here are the topics mentioned in the video and the quotes that impressed me the most:

• New JavaScript selectors - it's a sort of what jQuery gives you. You can put an arbitrary CSS selector;
• Web Storage - It's really easy to be used, and it just persists;
• Web SQL Database - When simple key-value pair isn't enough, another part of HTML5 is a real SQL database;
• Application Cache API;
• Geolocation;
• Web Workers - they are not threads, but they kind of act like them;
• Drag And Drop;
• New Semantic Tags - the nice thing is that it keeps your mark-up more semantic, it helps search engines [...] and you're also making your page more maintainable;
• New link relations;
• Microdata - it's not trying to be artificial intelligence mark-up language, and it's learning from a lot of the lessons from the last 15 years. Right now Google will actually see some Microdata mark-ups for events, reviews, in order to get better search results;
• ARIA attributes - one problem with jQuery UI, Dojo UI, is that screen readers can't work with them. ARIA is a way to add a little more of extra information, so screen readers know that a jQuery UI component that is a tree... is a tree;
• New form field types - we don't have to do this with JavaScript. So a lot of HTML5 is, again... get things out of the JavaScript that don't really belong there, get them back in the browser;
• Audio and Video - this is really in the browser, so we can add CSS reflection (and other stuff);
• Canvas;
• SVG - HTML5 says you can now drop these tags into the normal html;
• Selectors - CSS gives you more of them (selectors) based on what people have asked for;
• Fonts - it's actually from CSS 2.1 but it's finally ariving after 15 years;
• Text wrapping - you have no idea how much pain people have gone trough, having to use server-side solution to achieve this;
• Columns - something that used to be a pain in the but to do; you don't have to be a wizzard to do things that everyone needs to do;
• Text stroke;
• Opacity - this used to require custom made images;
• HSL - the reason that matters is humans don't think of colors in terms how rgb asked you to think of colors;
• Rounded corners - it's amazing how common things used to be so hard;
• Gradients - with great power comes great responsibility;
• Text shadows;
• Background sizing and multiple backgrounds - again, you don't have to spend many hours in front of Photoshop;
• Transition and Transforms - these can replace a lot of JavaScript.

In general, two phrases by Brad Neuberg are also worth mentioning:

It's great time to be a web developer

and

The next five years will be very exciting

The slides can be found on slides.html5rocks.com. It seems that they update the information from time to time with things that are missed, or had not existed, during the talk, which is a great way to keep yourself informed about what's going on in the constantly changing world of HTML5, CSS3 and JavaScript. Some of the new topics are IndexedDB, Web Sockets, Desktop Drag-In (File API), Desktop Drag-Out, FileSystem APIs, Device Orientation, Speech Input, Markup for applications, Form field types on mobile, Border image, Flexible Box Model, Custom data-* attributes, Element.classList, History API.

Enjoy the video.

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.