Delivering Quality

Developing applications for the web has changed significantly over the last 5 years. Since 2005 the term AJAX has been coined, Ruby on Rails is now an open source web application framework, jQuery was created and has subsequently revolutionized JavaScript development, and now HTML5 is the top buzzword of the day. I believe the next 5 years will hold just as many improvements for web developers.

I foresee a new framework will be created to make developing fully interactive AJAX applications as easy as it is to write current MVC applications. Current frameworks like Ruby on Rails and Symfony provide everything you need to develop a modern application without having to build plumbing infrastructure; however, they do not provide nice components for interactive applications. In addition to a robust server core, this new framework will have a client side JavaScript component that simplifies the process of building interactive web 2.0 applications. Some critical components would be:

• Form Validation. Libraries do exist to validate forms in JavaScript, but they don’t integrate with the server side form validation. In this new framework you won’t have to write form validation code twice.
• Paginated Lists. Almost all web applications have at least one page where data needs to be searched and listed with pagination. We need to have this same functionality in JavaScript to skip a full page reload and provide local caching of the results.
• Animation Library. While script.aculo.us and jQuery have made simple animations and visual effects much easier to do, I believe we can go even farther. Web applications also need to gain that fluidity and soft animations that desktop applications such as Exposé have had for a couple of years.

I also see huge resources being directed towards mobile development because ALL current generation smart phones are built for an incredible web browsing experience. As home users have switched from desktop computers to laptop computers in the last few years, people will slowly start switching to hand-held devices for their primary communication and Internet needs. Most likely this will have one primary effect: web frameworks will have a mobile optimized version of the site done automatically. Little to none developer intervention will be required as only resolution, text sizes, and layouts will be modified for the mobile version.

Lastly I see tools and libraries around 2D and 3D drawing elements. Most likely these libraries would be rendering to a Canvas or a WebGL element but something better could be created. Both of these are young standards right now that show a lot of promise on delivering the ability to draw pixels directly in a native HTML web page. While they will be used first in simple computer games, I am very interested to see what libraries are created to facilitate these elements being used appropriately inside next generation web applications.

What do you think the next 5 years will bring?

As you’ve probably heard, both YouTube and Vimeo have released beta support to their massively popular websites to play videos using the HTML5 video tag instead of Flash. While I am glad the video sites are finally switching to the native HTML video tag, I am perplexed why they have gone with the non-free option.

Firefox, Safari, Google Chrome, and soon Opera all support the HTML5 video tag with the ability to play Ogg Theora encoded videos (except Safari). On the other hand, H.264 is only supported by Google Chrome and Safari. Both of these formats do the same thing, they specify a compression standard that allows for efficient playback at relatively small file sizes. There are a number of technical differences, but generally, they preform relatively the same. The big difference between the two is that Ogg Theora is royalty free and available for anybody to use, while H.264 is encumbered by patents held by the MPEG LA association. This same organization will charge anybody who uses it a hefty royalty fee starting in 2011.

If you have a personal blog and want to put a video on your website using H.264 this means you need to have to hire a lawyer to create a deal with the MPEG LA to allow you to use their codec. This will either cost you a lot of money, or they will not allow you to do it. They do have the right to simply deny you if they don’t feel like it.

However, if you use the open Ogg Theora format, you are free to simply upload the video to your website to start using it, the same as uploading an image. Ogg Theora is not covered by any patents and is royalty free.

I don’t understand why both YouTube and Vimeo are both going the non-free route. Is it simply because they have the money to pay MPEG LA? Whatever the case, endorsing H.264 encoded videos as the format for video on the web is an option for large companies with money to pay, but it’s completely the wrong choice for blog writers and any small or medium sized organization.

Does anybody want a google wave invite? Leave a comment and the first people to respond will get one.

If you’re interested in programming graphics on the web I recommend subscribing to Planet WebGL; it has a lot of great tutorials and instructional material for learning how to program graphics in a web environment.

WebGL is technically a JavaScript binding to OpenGL ES 2.0. If you already know OpenGL ES and JavaScript, you should be able to pick it up pretty quickly. If you know JavaScript but not OpenGL and are in a web development career, I encourage you to look into WebGL because it could be one key component of interactive web applications in the future.

A fairly common website optimization that a lot of web 2.0 dot com companies are doing is to remove the leading www from the domain name. Removing the legacy www leaves you with a domain like http://delicious.com. Ok so delicious has a modern domain name but should you switch also?

Reasons for non-WWW

First, the domain name is more concise, easier to remember and just looks better. One caveat: you will need to setup a 301 redirect for requests with the three w’s to go to the non www version (see below).

Hold on, is it that simple?

No, it’s not, there are some disadvantages to having a domain name without a leading www.

Cookies are stored in a web browser at a set domain name. If you are not using the www, the cookie is saved to root: example.com. This can be quite a large disadvantage because the cookie is then passed along for every single request that browser makes for any subdomain on example.com. Even if you setup an alternate server just for serving images (images.example.com), your users browser will sent the cookie to that domain while fetching images. Sure its not a lot, but it does add up and removes some flexibility from your setup.

Another area it impacts is a site specific search in google. Doing a google search like the following: managing complexity site:markdeepwell.com, will not only search your main example.com website, but also all its sub-domains.

Reasons for WWW

Just about every person on the planet can recognize a domain name if it starts with www.something. Yes the www is redundant and not needed anymore, but it is a bit more user friendly.

If your site has multiple sub-domains, then I’d definitely recommend you go with a www domain to keep them all separate. Large websites benefit more from having the leading www; alternatively, if you have an extremely simple website like upcomingholiday.com it would do no harm to remove the www.

If you have a domain that’s been around for a few years it is possible to switch from one to the other, as long as you setup 301 redirects for SEO purposes, or else your rankings will plummet.

No matter what, make sure you have a 301 redirect setup so that users only see one version of your site instead of two. Be consistent by picking one and sticking with it.

Here are some common htaccess rules for redirecting requests to the proper domain name.

Redirect www to non-www:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Redirect non-www to www:

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule (.*) http://www.%{HTTP_HOST}/$1 [R=301,L]