HTML5 has certainly been making the rounds in the news lately. With Apple’s on-going PR campaign against Adobe’s Flash technology, comes mounting misconceptions about what exactly HTML5 is, what it can do, and what it means for end-users.

I hope to clarify several of the most glaring misconceptions over the next few posts. Today I’d like to focus on the most publicized and misunderstood issue of HTML5 video.

HTML5 is not a complete standard

Before we even get into video itself, it is worth noting that for all the publicity HTML5 is getting as the next big thing, it isn’t even final. W3C, the standards body responsible for HTML5, still classifies the HTML5 spec as a “Working Draft” as of this writing.

This means that none of the features are final and are still subject to change. While many browser makers are being pro-active in adding support for the proposed HTML5 features, there is inconsistency in implementation between browsers and level of support.

In other words – HTML5 is not supported in its entirety by any browser currently available.

Why HTML5 video?

One of the biggest areas of growth for Flash has been in delivering video. Flash was probably never best suited to the task, but due to the market penetration the plug-in had across the Internet, it evolved into the defacto standard for delivering web video.

HTML5 seeks to alleviate the web’s reliance on a single plug-in for video by bringing native video support to the browser negating the need for a plug-in. There are many high-profile live implementations of HTML5 video on the web today that target modern browsers and Apple’s mobile devices like YouTube, Vimeo, Time Magazine, NPR, and others.

However, while Apple is aggressively pushing HTML5 video for their iOS devices and modern browsers as an open alternative to Flash, what isn’t open is the video codec Apple has chosen for their implementation.

What is a codec, and why does it matter?

A codec is a method of taking raw audio and video and compressing them into a single file for distribution, and subsequently decompressing the file for playback. Raw video is extremely large, and so codecs serve to produce the best possible size to quality ratio. For web video specifically, this is extremely important.

Several notable browser and smartphone makers like Apple, Google, and Microsoft are currently (or intend to in Microsoft’s case) supporting the popular H.264 codec for HTML5 video. However several other bodies oppose this seemingly ad-hoc choice due to the fact that the H.264 codec is not open source and requires licensing. Organizations like Mozilla and Opera have posed the argument that an open video implementation without an open codec is two steps forward, but one step back.

However, the counter-argument in favour of H.264 generally revolves around the notion that H.264 is already widely adopted, has excellent performance, quality and compression, the licensing terms are clear, and all patent claims against the codec are accounted for. Contrasted to some of the open source alternatives proposed like Theora, it isn’t clear whether or not they may infringe on existing patents, which makes them somewhat risky to use. In addition, both Microsoft and Apple are members of the licensing organization for the codec, which may also explain their preference.

To muddy the waters further, a new video codec called VP8 has recently been acquired by Google and has been released as open-source. Mozilla, Opera, Adobe, and Google, are all pushing for this codec to be considered for HTML5 video via the WebM Project.

So what? Does an open codec matter?

There are valid opinions on either side of this debate. It is logical to want to see an open source codec used in conjunction with an open standard like HTML5. Otherwise every piece of software that plays or authors video intended for the web will need to pay licensing fees for use of the codec. Others consider this a fair price to pay for access to a mature, robust codec with high-quality compression.

Personally, I don’t feel comfortable handing control of such an important piece of the Internet to a private organization. Much like the arguments levied against Adobe’s proprietary Flash technology, trading video locked into Adobe’s Flash is in a way much the same as video locked into MPEG-LA’s codec. Alternatively, browser makers could simply license and build the Flash plug-in into their browsers and achieve the same effect.

If we’re going to go through the effort of converting the Internet away from proprietary video formats, we might as well go all the way.

HTML5 video is not a catch-all solution

While the prospect of an open video format is extremely enticing, there are several cases where it will probably never be used. A prime example is the distribution of broadcast television and film. Currently networks stream their content online and support it with advertisements. Since this video is locked away in a plug-in like Flash or Silverlight, the viewers of these streams are unable to download and re-distribute the content.

HTML5 provides no method of content or copy protection, which means it will probably never be used to distribute this sort of content.

What this means for end-users is the continued use of closed, proprietary technology – whether it be plug-ins like Flash or Silverlight, or platforms like iOS applications.

So while HTML5 video will clearly be a great step forward for web video, it will not fully replace Flash – at least not in this iteration. Therefore while Apple has valid reasons for not supporting Flash on iOS (namely Flash’s notoriously poor performance), it cannot be denied that Flash video will remain a significant source of copyrighted video content on the web until a better solution emerges.

When people think of open source, the things that immediately come to mind are products and tools that many consider to be polar opposites of Microsoft offerings.

Firefox vs Internet Explorer
Linux vs Windows
Apache vs IIS
PHP vs ASP.NET
MySQL vs MS SQL
Open Office vs Microsoft Office

If you run an organization that heavily relies on Microsoft technologies like Windows Server and Microsoft SQL, you may immediately assume this means you’re out of luck unless you’re willing to invest in open source web infrastructure – the most popular of which is known as the “LAMP” (Linux, Apache, MySQL, PHP) stack.

Luckily this is no longer true. Microsoft has made a concerted effort to support PHP on Windows Server and Internet Information Services (IIS). While PHP has always been able to run on IIS, the performance and stability was widely considered to be poor and as such, Windows was generally avoided as a viable server environment for PHP applications.

However, as of last year, Microsoft has begun official support for PHP on the Windows Server platform and is publishing official PHP extensions to natively support Microsoft SQL as well. This support has made the Windows Server environment a viable platform for popular open source CMS tools like Drupal, Joomla and WordPress.

In fact, if you visit the PHP microsite on http://iis.net, you’ll find easy install tools to get PHP running on IIS along with bundles of popular open source projects.

Support doesn’t end there – Microsoft is also addressing scaling and compatibility concerns by publishing a URL rewriter which is compatible with Apache’s popular mod_rewrite and a caching engine.

This move of support from Microsoft is a powerful indicator of how strong and successful the open source movement has been across the web. Microsoft could no longer afford to ignore the prevalence of PHP and rising popularity of open source tools in the enterprise space.

Many open-source advocates may dismiss this support as a “if you can’t beat ‘em, join ‘em” move on Microsoft’s part, and I think that’s sadly missing the point. Regardless of Microsoft’s intentions in throwing support behind PHP and popular open-source web applications, the key point to take away from this is that Microsoft has dropped several barriers companies have faced in the past when looking to leverage these technologies.

I don’t really blame people, though. Drupal probably isn’t for them, and drupal.org and most Drupal advocates are doing a terrible job of setting expectations. So much so that I feel this trend of pushing Drupal onto everyone for everything is hurting Drupal’s reputation and perception.

Drupal is NOT in any way, shape or form a turnkey solution. You cannot download and install the package from drupal.org and get anything resembling a functional, maintainable website. Drupal is NOT a content management system, it’s a content management platform.

To most people that distinction is meaningless and does not adjust expectations. All one has to do is count how many times a day people ask on Twitter whether they should choose “WordPress, Joomla or Drupal” to recognize where people’s expectations are when talking about Drupal.

When first installing Drupal 6.x, most people quickly realize:

• It has no WYSIWYG
• It does not generate search engine friendly URLs
• It has no media management
• Does not produce image galleries or embed video
• Has a confusing, cryptic admin interface that doesn’t distinguish itself from the user-facing site

To a user expecting something like WordPress, Drupal looks like complete and utter garbage, and they’re quick to express this point of view on blogs, twitter, message boards, Facebook, LinkedIn and in comments on posts like this.

Drupal is designed this way intentionally (as counter-intuitive as this may seem). No two websites are the same, and so Drupal tries to make as few assumptions about what kind of site you’re trying to make as possible. Upon installing Drupal, the expectation is that the user then proceeds to head over to http://drupal.org/project/Modules, browse the buffet of functionality and proceed to “build your own content management system”… but no one tells the user that.

With the right amount of patience, research and experience, Drupal has the capability to produce massive, complex, highly customized site management tools for any size organization. This is the main reason many web shops are shifting their business toward providing professional Drupal services. In a nutshell, it lets developers build very customized sites for clients quickly and at lower costs.

There is much debate happening within the Drupal community about whether or not the current approach of shipping the core product with as little as possible is the correct one or not. Some feel shipping with a WYSIWYG and a more concrete set of metaphors is necessary for Drupal’s wide adoption while others feel this takes away from Drupal’s core strengths.

Whichever side of the fence you currently sit on, I think we can all agree that the current state of the messaging to new users sets errant expectations and new users may look upon the tool more favourably if they come into it with the expectation that upon installing Drupal, their job is only starting.

Acquia, Drupal founder Dries Buytaert‘s commercial venture, is betting on their Drupal 7 based hosted service,Drupal Gardens, to start changing perceptions by demonstrating what a “productised” implementation of Drupal can do. Whether Gardens will help or hurt the cause remains to be seen as the product is in invite-only beta as of this writing, and Drupal 7 itself has not reached a stable release yet.

Even still, Drupal isn’t for everyone or every site, and that’s OK – I’m a big believer in selecting the right tool for the job. If you’ve found yourself in a position where you’re unsure about whether or not your organization is suited to jumping on the Drupal bandwagon, check out our literature on open source software, and/or give us a shout.

As anyone who has developed a Drupal site with devel module‘s query logging on can tell you, a Drupal implementation can quickly get out of control when it comes to hammering the database. Personally, I’ve seen Drupal run well over 300 queries to render a single page. In a hosting setup where the bottlenecks exist at the memory usage and MySQL levels (which refers to nearly all non-dedicated hosting packages), this can quickly become a problem.

I’ve summarized a series of simple setup and configuration tips behind the jump that can help any site running Drupal 6.x improve performance and the subsequent user experience as a result.

1 – Disable Re-Building of Theme Registry

When a Drupal implementation is under development, themers and/or developers will often enable an option that forces Drupal to rebuild the theme registry on every page load. This registry tells Drupal what template files and overrides exist in the theme’s directory. This is a very costly operation and would cause noticeable slow down on any production website. It is important to disable this option upon going live. Under Administer > Appearance choose the Configure option for your theme and scroll to the bottom of the page. Make sure the option named “Rebuild theme registry on every page.” is disabled.

2 – Enable Page and Block Cache

Another simple option to enable is Drupal’s caching engine (Administer > Configuration > Performance). When enabled, Drupal will render the page and associated blocks once, and then save that result in the database. This can drastically reduce the number of database calls run on a page since the results are pre-rendered.

A point to consider about caching is that the more interactive the site is, the less effective the cache may be. Especially if complex permissions are at play, Drupal won’t be able to effectively cache since most of the page content may change depending on the permissions of the currently logged in user.

Drupal’s caching engine is most effective for anonymous visitors – if your site is mostly “read only” and doesn’t have visitors logging in, caching can make a dramatic improvement in site load speed.

3 – Increase Cache Lifetime

An option for some sites may be to increase the cache lifetime. This determines how long Drupal will hold onto a cached result before it will re-generate the page. If you have frequently changing content, you may want to set the cache lifetime to only 5 minutes, but if your content doesn’t change often, an acceptable value may be several hours.

On high-traffic sites, the less often Drupal has to re-generate pages, the better.

4 – Optimize JavaScript and CSS Files

Also in the Performance settings is an option to optimize both JavaScript and CSS files. When enabled, Drupal will consolidate all CSS and JS files included on each page into a single file, and compress the code by removing whitespace. This will reduce the overall file size and improve page load speeds.

5 – Disable Un-used Modules

Due to the staggering array of available contrib modules listed on Drupal.org, it’s common to download and install dozens of modules to test out and see if they meet your site’s needs. In the process of doing this, it’s easy to forget to uninstall the modules you don’t end up using. Additionally, the default install of Drupal comes with a minimum number of modules pre-enabled. Again, if your site isn’t using it, there’s no reason to keep it enabled.

Drupal will fire callbacks for all enabled modules which may come with their own database queries. Be sure to take the time to clean out your enabled modules list before going live with a site.

6 – Configure Cron to Run

One thing that’s easy to overlook is setting up Drupal’s cron tasks to run. Most web hosts provide a way to configure “scheduled tasks” or “cron jobs” in the hosting panel. Drupal’s cron.php fires updates for RSS aggregators, launches the search indexer, and any tasks defined in installed modules. In addition, it will perform some basic maintenance tasks like deleting temporary files and clearing logs.

The Drupal installation guide covers cron in detail with several methods for configuring it.

7 – Disable CCK Content Permissions

While this tip technically falls under tip 5, I figure it’s important enough to be explicitly outlined. The CCK module comes with several sub-modules. One of which is “Content Permissions”. This enables site administrators to set permissions on a per-field basis. Unless your site absolutely needs per-field permissions, this is a no-brainer to disable.

The less permission checks your site has to run the better!

8 – Disable Database Logging

Again, another one that technically falls under tip 5, but I feel is especially important is disabling the database logging module. This module will log a wide variety of actions performed on the site to the database. If you’re the only administrator, this module’s usefulness is greatly reduced and should be turned off. Alternatively, you can enable the syslog module which ships with core instead. This will write the more technical log entries to the server’s standard log on the file system and save the database queries.

9 – Use a Third Party Comment System

This one isn’t necessarily Drupal specific, but an easy way to off-load quite a bit of processing on a popular site. Since Drupal’s caching system is far more effective when only serving to anonymous users, if the only reason you have user registration enabled is to allow them to write comments, you may consider off-loading that task to a free third party service like Intense Debate or Disqus. A small clip of javascript is all you need to include into your template (or include it via a block), to embed a robust comment system into your site. Also, if your visitors read other sites that use Intense Debate or Disqus and already have an account (or use OpenID), they’ll already have an account to comment on your site.

As of this writing, there is a published module to add Disqus support as well.

As any software developer will tell you, there’s a limit to the number of times you can hack on a codebase before it’s no longer sustainable. When a piece of software, protocol, or standard of some kind is conceived, it is done with assumptions in mind. These assumptions ultimately lead to limitations, and those limitations ultimately necessitate the need to come up with clever workarounds or, in the worst case scenario – hacks.

This leads me to a thought I had while trying to get the office Internet connection to work (read: configuring the network to use OpenDNS because our ISP’s DNS servers woefully unreliable) when a realization hit me. The Internet, as a whole, from the basic protocols driving the data through the tubes, all the way to the scripting languages rendering a good chunk of what you’re seeing on this page right now, is one giant, heavily error prone, endlessly band-aided hack.

Hindsight is 20/20

When the original group of folks sat down and came up with the idea of HTML and a browser, they could have never imagined something like, say, Google Wave one day running in that browser. However, here we are today, playing with a beta version which represents over two years of work by some of Google’s most brilliant engineers… and it barely works.

Yes, I did notice the clearly displayed beta tag in the corner, and I’m sure eventually Google will apply enough duct tape and chewing gum under the hood to give Google Wave the illusion of stability (Gmail and Google Maps both run great today), but the fact of the matter is that the brilliant, advanced technology powering most of the Internet’s slickest, most cutting edge applications just isn’t all that brilliant or advanced… and it’s starting to show in a big way.

The March of Progress is More of a Crawl

Web standards move at a glacial pace, but that’s only half the equation. The other half are the browsers that move even slower. The folks that govern web standards could release a radically up to date set of standards that have applications in mind, but that doesn’t mean developers would ever be able to actually use those standards as they are limited by the lowest common denominator of support  in the browser market.

In a world where a decade old browser (that had poor standards compliance when it launched) still commands a considerable market share, where does that leave the future of web applications? Even if we could wipe Internet Explorer 6 off the face of the earth tomorrow, today’s most bleeding edge standards are still simply additional hacks tacked onto an already rusty frame.

Developing Google Wave’s interface as a desktop application would be a trivial task relative to the amount of effort it’s taken so far just to get Google Wave to run within bare reason in a browser window. Why?

Browsers Are Terrible Application Platforms

1 – HTML, CSS and Javascript are tools designed for displaying and manipulating flat content, not tools for building interfaces and applications.

Wikipedia is the closest realization of what the Internet and the associated standards as a whole were designed to do – deliver content in a readable format on screen.

2 – Browsers are designed as content renderers, not application platforms.

It’s the browser’s job to take that content delivered from a web server, read and understand the markup, and display that content on screen as the author intended it to look. It wasn’t meant to manage multiple document interfaces, generate non-standard UI elements (tabs, grids, taskbars, modal windows, etc), or maintain persistent, open connections to servers.

3 – Browsers are the number one attack vector for malware

…and for good reason. Being able to deliver executable code right onto a user’s machine opens near endless avenues for attack. That said, the browser locking web applications out of all system functions like local file storage also severely limit what an application can accomplish.

Gentlemen, Start your Hacking!

Which leads us full circle – what is it about Google Wave that so perfectly highlights everything wrong with today’s web applications?

In a word: Javascript.

Just about everything done in web applications is accomplished through the horrific abuse of Javascript. You may have noticed a lot of talk in the browser world about who has the “fastest Javascript engine” and this is why.

Every single element in the Google Wave interface is generated dynamically by Javascript which is read and executed – line by line – by the browser. As you might imagine, this is slow. Since Google’s applications so heavily rely on Javascript, they went as far as to release their own browser with a dramatically faster Javascript engine in order to kick off a Javascript performance war in the browser world.

Furthermore, to ring in the launch of Google Wave, Google has gone as far as to offer a “plug-in” for Internet Explorer that basically just shoves Google’s browser into the Internet Explorer interface. This is exactly how desperate Google is to force bleeding-edge standards into the wild.

The second major limitation Google Wave is trying to address is how to bring real-time communication into the browser. The way this is accomplished today is through the use of making Javascript continuously poll a server to ask if there’s anything new since the last time it asked. As you might imagine, this is also slow and error prone. Alternate techniques have been addressed to get around this limitation where a server is configured to allow an abnormally long request to linger (essentially endlessly left “loading”). This allows Javascript to ask a server if there’s anything new, and instead of a simple yes or no, it pretends it’s answering the request very, very slowly.

This is better, but still not perfect and is hard on web servers which are tailored for delivering yes or no answers to requests and quickly moving onto the next, and not practical to implement in the vast majority of server configurations.

The Solution

After a rant like that, I’m sure you’re expecting a brilliant, well thought out plan to fix all our woes. Unfortunately, I don’t have one. Today’s Internet has grown so organically and has responded in new, interesting and clever ways that it’s almost impossible to judge where it’ll turn next. Any new standards that are concocted will eventually become insufficient for the unexpected developments the Internet will churn out.

Google Wave is ahead of it’s time, but there’s nothing wrong with that. As a web developer, I’m pleased and excited to see a high-profile application like Google Wave pushing the bleeding edge of what’s possible in the browser.

Just like the original computer programmers who toiled endlessly, manually writing processor instructions and directing bytes of memory, our new generation of web developers toil with inconsistent standards, rudimentary tools and a decade old browser that won’t die.

Things will get better as long as we have companies like Google willing to invest millions into making the browser a better and more viable application platform.

Things will get better as long as we have groups of developers in open-source communities improving frameworks that make us forget we’re writing massive applications with interpretted, fragile, inline script.

Things will get better as end users demand faster, more advanced applications through their browsers.

These are exciting times. Unlike those who drafted the original HTML spec, we can imagine what tomorrow’s Internet will be like. It is this imagination that will continue to fuel innovative hacks and keep our beloved Internet hobbling along.

We tip our hat to the community at large and, on occasion, contribute some Drupal goodies ourselves!