Keith Cirkel

What to expect from a world without IE6.

Sun, 11 Apr 2010 12:22:16 +0100

It’s no secret that developers across the globe resent Internet Explorer. It’s disregard for standards are a burden, often requiring a parallel development effort just to cater for its inadequacies. Newer versions aren’t much better, and in some cases exacerbate the problem. This year saw Internet Explorer 6 drop below 10%, and Google has dropped support for it; and (perhaps most importantly) the upcoming release of Internet Explorer 9, what can we expect to see changing?

The fall of Internet Explorer 6

Without a doubt Internet Explorer 6, a browser nearly as old as this millennia, is wrought with the most problems — as to be expected. With Internet Explorer 6 out of the picture we can finally start to use some of the great technologies CSS2 has brought us:

CSS Event Selector Support (well, just :hover) - IE6, unfortunately, has spotty support for even the most basic selectors. :hover and :active only work on anchor tags, :focus support is non existent, alongside :before and :after. Unfortunately Internet Explorer 7 doesn’t really improve much on this, except for with :hover. But :hover is still a huge improvement, so worthy of going on this list.
CSS HTML Selector Support - HTML Selector support gives support traversal and attribute rules, such as * (which IE6 does support), + (select the adjacent element, for example li.first + li{} or > (select only the direct children, for example ul > li{}). Add on to this the :first-child selector, and you can drop a lot of your HTML class names (think ul:first-child as opposed to li.first). Also included in this list is the [attr=] rules, which version 7 has full support for. This means no more classing your inputs, you can just add a rule such as input[name=”submit”]{margin:10px}, and it’ll work across the range of browsers. Beautiful.
CSS3 Selectors - As crazy as this might sound, IE7 actually supports some CSS3 selectors, so dropping IE6 will give you the ability to use advanced CSS3 selectors, such as ~ (which is like +, but + only selects the next sibling (so a limit of 1), where as ~ selects any following siblings). CSS3 also brought support for advanced [attr=] selectors, so you can use semi-regex pattern matching such CSS as a[href^=”http://”].
Max-Width, Max-Height CSS Rules - I think these are self explanatory, but IE6 is missing support for all but a tiny fraction of these rules, while IE7+ and the rest of the world support them perfectly. Dropping IE6 means you can finally flex your max-* muscle, which means more intuitive scalable web pages.
PNG support - Ok, IE6 does support PNGs: badly - it messes up with the palettes in PNG8 files, and worse so, does not support Alpha transparency in PNG-24 files. If you’re developing for the web, you likely know just how useful Alpha Transparent images are, but here is a concise summary. Now, you can hack PNG support into IE6, using Javascript and Microsofts own CSS filter rules, but you’re just adding cruft and maintenance issues which can become a headache. Dropping IE6 from your vocabulary will mean you can finally stop using GIFs and switch for PNG8 and PNG24, and live a happy existence.
ABBR Tag - Ok, not a big one, but still useful: IE7 recognised the abbreviation tag, improving on IE6’s support of - well, ignoring it.
Support for fixed backgrounds - Another small bug significant improvement, is IE7’s support for background-position: fixed. Allowing the background to stay fixed on the screen while the user scrolls.
Less use of hacks - It almost goes without saying, but the improvements made in Internet Explorer 7 have allowed developers to use less “hacks” to support later versions of IE: no more frustrating box-model bug, decent CSS selector support, PNG support! So when IE6 finally dissapears, you can expect less <!if ie[lt]7—> comments, and less CSS/Javascript hacks. This all amounts to less code, meaning less maintenance, meaning you get to spend more time doing the cool stuff than figuring out how to get IE6 working with your new site.

Can you drop Internet Explorer 6 support though?

In my mind, yes! There is very little reason to continue supporting IE6, Google haven’t since March. Windows XP users can upgrade to IE7. Microsoft has issued automatic updates for IE7 to Home and Corporate users, and even removed the WGA requirement from IE7, so even pirated versions of Windows XP can get Internet Explorer 7. IE6 has seen a fairly steady decline in userbase (around 1% per month) which means by December 2010 IE6 could match the userbase of browsers such as Opera 9, and IE5 - perhaps it will see an even faster decline after the release of Internet Explorer 9. By then, IE6 usage could well be lower than Firefox 2.*, Mozilla 1.*, Seamonkey 1.*, Safari 3.* and Opera 9.*. How many of those browsers do you support now? If you don’t want to take into account the usage statistics, how about age? IE6 was released in 2001. Mozilla Firefox 1.0 was released in 2004, Netscape 7 in 2002, Netscape Navigator 4.8: 2002, Opera 6.0: 2002, Safari 1.0: 2003. How many of these do you support? I think the answer is clear.

Leaving Internet Explorer 7 behind

It is a bold suggestion right now to ditch Internet Explorer 7. IE7 was released in 2006: a 4 year old browser, aeons in computer years. But what would dropping IE7 even give you? What does IE8 have to offer?

Full CSS Event Selector Support - As opposed to lackadaisical approach with event selectors, IE8 gives it the college try. :hover and :active are supported for all elements, not just anchor tags. :focus is fully supported. No more Javascript hacks for you!
Full CSS HTML Selector Support - Selector support becomes more inline with other browers, including adding the :before and :after tags. These tags let you add an image, or text before or after an element. Adding to this, it supports the content: declaration married to this selector.
Counter declaration support - This is a cool but seldom used declaration among the CSS2 ranks. Counter lets you assign list-style-type elements to any HTML element. This is actually more useful than it sounds. Consider h2:before{content:counter(section) “. “;} which will give every H2 element a number i.e turning “Heading” into “1. Heading”, or perhaps this: img.fig:after{content:”Figure ” counter(example,lower-alpha);} which would put, for example, “Figure a.” after every <img class=”fig”> element. Nifty, no?
Greater List-Style-Type Support - Speaking of List-Style-Type, IE8 comes with additional types according to the CSS 2.1 spec including decimal-leading-zero (01., 02.), lower-greek (α, β) and some of the more obscure such as georgian (ა, ბ) and armenian (ա, բ).
More declarations - IE8 supports lots of other useful decelerations, for example outline (think borders that don’t move the element), the fantastic display:inline-block (think a grid of icons on a page), and full support for the white-space declaration.
Finaly, full CSS 2.1 Compliance - You can pretty much sum up all of the above into one, strong point: fully compliant CSS 2.1 support. IE8 passes the Acid2 Test, (although it gets a miserable 12/100 on Acid3). Hurray!
localStorage and sessionStorage - One pretty important feature to HTML5 will be localStorage - the ability to store key/value storage in the browser, without using cookies. localStorage differs from Cookies in that it has no expiration, it is not send with every page request, can be pulled (very easily) on demand with Javascript, and it can store a huge amount more data (Each cookie can store 4kb, localStorage can store 10mb on IE8). sessionStorage is just like localStorage, but is cleared when the session is gone (i.e window closing). localStorage is an impressive feature of HTML5, although only the latest versions of many browsers support it (Firefox 3.5+, Safari 4+, Chrome 4+).
Data-URI support - In case you don’t know what data-uris are, they are strings that make up part of a binary file, usually an image. For example, a data-uri for a PNG image might look like this data:image/png;base64,iVBORw0KGg… This will then render that particular image as if it was a file. This is incredibly useful for small, compact pages - where you need a single image in an instance, or if you are needing to reduce server load through HTTP requests. You can embed data-uris into CSS and HTML, for example: <img src=”data:image/png;base64,iVBORw0KGg…”> or div{background:url(data:image/png;base64,iVBORw0KGg…)}.

When can we rid of Internet Explorer 7?

Internet Explorer 7 is definitely on its way out. IE8 is taking place of IE7, as it is available for download on Windows XP, once again without the need for WGA. IE8 comes default on Windows 7, which seems to be taking the world by storm. IE8 is certainly in a position to replace IE7 in every way. IE7’s userbase is only around 2% higher than IE6, and seems to remain in-line with IE6 as it falls, and with IE8 as it rises. As soon as May 2010 we could see IE7 drop below the 10% userbase threshold, and it could be as low as 2% by 2011, falling behind Opera. IE7’s reign will most certainly last shorter than IE6, and rightly so. By this time next year, IE7 could be all but gone.

Getting Ready for Internet Explorer 9

Internet Explorer 9 was announced not so long ago, with impressive improvements in almost every field. When IE9 hits and has a significant userbase (lets dream here and say enough to put IE6/7/8 out of the picture), our internet lives will be a lot richer:

Full CSS3 Selector Support - What? Internet Explorer 9 will fully support CSS3, ahead of time? Pinch me. But its true. Not only is that the case, but it actually passes every single selector test on css3.info. That puts it in line with Chrome 4, Safari 4, Firefox 3.5 and Opera 10! Advanced selectors like :last-child, :nth-child(), :nth-of-type(), :empty, :target, :disabled. These selectors will allow you to stop using Javascript to style pages for everything except animations.
Support for CSS3 Colour Levels - Additions to CSS3 include the ability to set rgb(), rgba(), hsl() and hsla() colours. IE9 supports these. These apply to any declaration of colour, be it border, background or text.
New CSS3 border & shadow declarations -border-radius is supported. As is border-image. Sadly text-shadow and box-shadow aren’t (in the developer preview yet). Fingers crossed they will be!
HTML5 Tags - Perhaps most impressively, IE9 will support HTML5 tags such as <video> and <audio>. Yay!
SVG Support - Internet Explorer 9 will support Scalable Vector Graphics embedded in pages, this means where you don’t need photographic images, you can use vectors instead. This will turn to be a massive improvement to the web as we know it.
XHTML - Finally, at long last, IE9 will support true XHTML. This means advocates of XHTML can finally begin to use XHTML as it was meant to be used: as xml. Confused? Read my previous post on XHTML.
JPG XR, TIFF, Colour Profiles - IE9, catching up and overtaking some browsers, will support JPG XR and Tiff Images as well as support ICC colour profiles

When will Internet Explorer 9 make our dreams come true?

Here’s the stinger. IE9 isn’t set to be released until late 2010. By which time hopefully you’ll have ditched IE6 and possibly IE7. Unfortunately IE8 will still be around for atleast another year - possibly longer as it supports CSS 2.1, corporate users stuck in there ways (those ones that wouldnt budge off of IE6 for ages) will likely be afraid to move off of IE8 for a good while. To further add sting, IE9 wont be supported on XP, meaning we’ve got to get rid of a whole population of Windows XP users before we can think about entertaining all the wonderful elements of a full family of standards compliant CSS3, SVG, XHTML browsers. HTML5 and CSS3 aren’t official standards yet either, so don’t get too excited about seeing those with wide support just yet (most browsers still use their vendor prefixes, such as -moz- for CSS3 rules). We are, however, seeing a rapid acceleration in the advancement of the web. HTML4 is getting long in the tooth now, and so it is about time to get some excellent new features. I personally can’t wait. Besides, I wouldn’t waste too much time on wondering when IE9 will come out — you’ve got plenty of CSS3 to learn before then…

XHTML: Why everyone wants it but you shouldn't use it

Sat, 27 Mar 2010 12:38:00 +0000

Everyone is asking for it these days. Go onto freelance boards, talk to clients, even on job boards, clients & companies are requiring their developers to know XHTML. The problem is, XHTML isn’t what everyone thinks it is, and that isn’t going to change any time soon.

Why Everyone Wants XHTML

Back in the dark days of the web, developers were using HTML, and a lot were using it badly. HTML, like many languages, allows the user to make a real mess of it — and as W3Schools.com quite happily states: “Many pages on the internet contain “bad” HTML.”

Bad HTML

Technically, the HTML standard was a mess; tags didn’t have to close, there was a whole range of useless tags which vacillate in and out of popularity, and lots of down right annoying tags. Things have been slowly fixed, and HTML 4.01 is a lot cleaner than its predecessors, but “back in the day” (circa 1995-7) no one could say HTML was a good language. Couple this with the plethora of horrible WYSIWYG HTML editors, the likes of Microsofts FrontPage (shudder) and DreamWeaver which frankly butcher any semblance of sensible mark-up, and you have a real recipe for disaster.

Birth of XHTML

HTML also uses a loose form of the SGML standard (because XML didn’t exist in 1995 when HTML was created), which allowed all of this mess to happen. Around 1997 the W3C realised the failings of HTML, and in part SGML and began working on a beautiful subset of SGML called XML. XML is the simpler, more restricted (in a good way) offspring of SGML that was really needed to truly standardise machine readable documentation. XML was, for all intents and purposes, the saviour of open documentation. So, with this cool new tool, W3C set to work on creating a subset of HTML using the XML standard. XHTML was born from this. XHTML took away pretty much all the crap that lurked in HTML. All those annoying and useless tags were deprecated, tags had to close properly, and because of its use of the much simpler XML format, it was much easier to maintain, implement and extend. So, back in 2000 when XHTML became an official standard, people rejoiced, we had a strict, properly typed, decent implementation of HTML. Thanks to its simplicity and strict rules, it could be rendered much faster compared to (bad) HTML, and it was easier to read thanks to the enforcement of lower case tags and proper closing. Who wouldn’t want to use it? Popularity rose for XHTML and developers quickly learnt the new standard. I admit I was one of the proponents too. XHTML was the buzzword of the 2000s, but it didn’t turn out to be the panacea people had hyped it up to be…

HTML 4.01

The popularity of this new language meant a lot of the “cutting edge” developers didn’t even notice the release of HTML 4.01 - a release which mirrored the decisions of XHTML, minus the, y’know, XML part. In fact XHML 1.0 and HTML 4.01 had an identical tag set, and could have pretty much identical looking code, minus a few slashes. Infact, HTML 4.01 was released as a standard a month earlier than XHTML. My feeling is that because these were released so close together, a big part of the perceived improvement of XHTML made was actually the improvement made from HTML in general.

Why you shouldn’t use it

So by now we realise XHTML is pretty much HTML 4.01 but uses XML, which is faster, and simpler, and better. What gives? Why shouldn’t you use XHTML then?

XHTML as HTML

Here’s the kicker - XHTML kinda doesn’t work all that well. See, with all the great work W3C does to bring the web forward, the biggest browser vendors around at the time are the true judge of how far forward we go. Want proof, just look at the current HTML5 Video debacle. In 2000 when Internet Explorer had 80-90% of the market, it was the ultimate decider on these matters. For whatever reasons Microsoft had, it released Internet Explorer 6 in 2001, without XHTML support. To rephrase that for emphasis, Internet Explorer 6 does not support XHTML. Also, in fact, the latest version of Internet Explorer to support XHTML is 9, which isn’t released yet. Awesome. In the extreme wisdom of web designers all over (including me, sarcasm btw), XHTML documents would be passed off as “text/html”, so they could be rendered in Internet Explorer. This means all browsers see these documents as HTML, not XHTML. This is important because anything you expect to happen in XHTML that doesn’t in HTML, wont happen. Anything you expect not to happen in XHTML that does happen in HTML, will, of course, happen. So to put it blankly - virtually no body uses XHTML, lots of people incorrectly use XHTML as HTML. Doing this is a really bad idea.

HTML is better

Thanks to the mess of HTML prior to 4.01, and the mess of XHTML as HTML, all the browsers today have a “quirks mode”, which is a polite way of saying a way to deal with crap code. Quirks Mode tries to overcome the inadequacies of the HTML document it is rendering, which includes typos, missing tags, missing attributes for tags, added slashes (think <br/>) and lots of other idiosyncrasies. XHTML doesn’t do this - because of its strict XML definitions, an invalid XHTML document won’t render (see also W3C). This is a double edged sword - it’s good because it is programatically correct - as the xhtml.com article states, you wouldn’t expect a C++ or PHP application to run on bad code, so why XHTML? The problem lies in that it can be excruciatingly difficult to create valid XML code. Small pages are easy, but imagine a blog - where you have to ensure every post on that blog uses valid XHTML, and every comment inside every post does the same. Suddenly you have turned your life into a never-ending user support nightmare, having to validate (or atleast check) every new post or page that gets a new comment.

Don’t use it!

So, history lessons aside, why shouldn’t you use XHTML? Lets break it down:

XHTML is not supported by Internet Explorer. IE9 is the first release to support it. Cutting your userbase by 90% is usually not a good idea.
XHTML rendered as HTML can introduce annoying problems & incompatibilities.
When you do actually use XHTML properly, it can break very easily. This won’t change either - it is meant to by design.
Proper XHTML becomes difficult to maintain when users introduce new code all the time. Sure there is lots you can put in place to prevent invalid code being introduced - but it all adds up
Bad Javascript will break XHTML documents. For example, any code with document.write() in it which includes Google Adsense by the way!

Not very compelling now is it? But what about all the benefits of XHTML? Well, for the most part, the main benefits of XHTML carry over perfectly into HTML. I recommend you take the lessons XHTML provides, and put them to good use in HTML:

Always use lower case tag & attribute names. It just makes it so much more readable.
Quote your attribute values. It will help a lot when using Syntax-Highlighting in your development environment to do so.
Close your tags. You should do this anyway to ensure your HTML is given the best chance of rendering in all browsers.
Properly doctype your HTML. This plus closing your tags allows the browser to render your code in “No Quirks” mode, lowering the chance of browser incompatibilities.
Spend time to validate your documents. Using the W3C validator service to validate your documents is a good way to make the best of HTML

Still want XHTML?

If you’re still adamant about using XHTML, then atleast use it right. Use server-side user agent sniffing or even better; content negotiation to detect if you are serving to Internet Explorer (or other non-xml-able browsers), and if so serve an HTML document, otherwise serve XHTML with the “application/xml” or “application/xhtml+xml” mime tag. Remember, if you code proper HTML, and code it as well as you would XHTML, all you’re missing out on is your <br> and <img> tags being <br/> and <img/>, but what you gain is flexibility and graceful error handling.

Swapping out your LAMP stack

Sat, 27 Mar 2010 11:33:55 +0000

The LAMP stack is the backbone of the web these days - every hosting provider uses it, sometimes exclusively. Many think their only other option is a WIMA (Windows, ISS, MSSQL, ASP) but in fact there are a whole wealth of options to choose from. When you have the freedom to pick your own server environment, should you move away from LAMP? It’s certainly a tried and tested platform, many of the top websites of the world use it - but why? How can it be improved? Well, you might be surprised to find out the different choices you have available…

L is for Linux

I love Linux. 3 of my 5 machines at home run it. It runs on my home server. I use it every day - I’ve used it to set people up with countless web sites. Linux is certainly a strong platform for your server stack. For me, Windows isn’t even an option. I’ve used Windows, but for me, Linux wins. The majority of Linux servers run on the CentOS distribution - a great distro, built on the shoulders of RedHat. I think today, however, there emerge some stronger platforms:

Ubuntu Server Edition (Linux)

Ok, ok. Ubuntu is a Linux distribution just like CentOS, so what gives right? Ubuntu Desktop is the Linux desktop, the forums swell with avid users helping each other out, Ubuntu has one of the strongest communities going. That is a good base for a server platform. Unfortunately the server platform receives the same stigma as the desktop platform - “Ubuntu is for noobs”, “Ubuntu is not a proper distribution” etc. Ubuntu’s server platform is pretty amazing though. Ubuntu’s package management; APT is a strong contender for Yum (CentOS package manager), and in my opinion beats it hands down. Ubuntu Server Edition also has a strong selection of “automagic” packages through tasksel; things like “lamp-stack” which will get you serving for web in under 2 minutes. Sure CentOS has groupinstall but I feel tasksel has more going for it, especially with APT in tow. Combine this with the use of PPAs (Personal Package Archives) (ok, they aren’t recommended for mission critical operations, but useful still) and you’ve got a powerful system which you’ll rarely have to compile source under. Ubuntu Server Edition also includes Landscape as an option which, for enterprise — especially on the Cloud, is a fantastic management platform. Also Ubuntu provides their EUC “Cloud Edition” installers, which are tailored for services like Amazon EC2. Yes indeed, Ubuntu is shaping up to be an amazing server platform which seriously gives CentOS a run for its money.

OpenSolaris (Sun Solaris)

OpenSolaris would be a definite contender for those performance-oriented administrators. OpenSolaris runs a lot of the FOSS tools you’re used to; PHP, Apache, MySQL - it’s all there. Where OpenSolaris is different, is in its architecture. OpenSolaris includes the much talked about ZFS (Zettabyte File System), which is purported to be blazingly fast and maintained free. OpenSolaris also provides a very strong platform for Virtualisation, with extremely strong tools such as Sun’s own VirtualBox, Crossbow and Xen Hypervisor. All this, and more; with Ian Murdock (Debian founder, of which many systems are based) leading the way for OpenSolaris, you know it’s gotta be good.

A is for Apache

Apache is the defacto HTTPD (HyperText Transfer Daemon), and it’s no surprise; Apache is mature, cross platform, stable and has been maintained regularly for way over a decade. It serves over 50% of the web. Being as long in the tooth as it is, though, many alternatives have cropped up which, in their own ways, show Apache to be an outdated platform - one that you should consider switching from.

Lighttpd (Linux, Windows, Solaris) - BSD License

Lighttpd (apparently pronounced “Lighty”) was created around the idea that a server should withstand 10,000 simultaneous connections, also known as the C10K Problem. That should give you an idea of where Lighttpd exceeds over Apache. Lighttpd’s site claims the likes of Youtube, Wikipedia and Meebo are all powered by the little-server-than-can (although Netcraft seems to differ). It does seem to be, however, a fan favourite of trackers all over (see PirateBay, Mininova, IsoHunt). It has risen in popularity to the point where it has emerged out of Netcraft’s “other” category in their web server statistics, even if only by a little. Unfortunately, where lighttpd fails is its configuration. I have used lighttpd a few times, and compared to Apache, it is a fair amount harder to configure (or atleast, significantly different for Apache die-hards to have difficulty), and the documentation is sparse. But hey, if its good enough for The Pirate Bay, right?

NginX (Linux, Windows, Solaris) - BSD License

NginX (pronounced Engine-X) is more of a bare-bones server. It is another server, built around the C10K Problem. It doesn’t come with the great configuration options that Apache and Lighttpd do, but it is fast. And much more popular than lighttpd (8% vs 0.35%). I haven’t used NginX enough to give you my opinion on it, but some pretty large websites use it, including Wordpress.com, GitHub and FastMail.fm. Also pretty compelling are its testimonials, which say more for it than I can.

Cherokee (Linux, Windows, Solaris) - GPL 2 License

Cherokee is shaping up to be my personal favourite for web servers. It’s as fast, if not faster than Lighttpd and Nginx, once again, another “C10k server”. But the real killer feature for Cherokee is the web-based admin panel, and associated wizards. Now I’ve got to say I’ve set up many a Wordpress install before using Apache, and it is pretty quick to get off the ground. In Cherokee, however, you can do it in under a minute, using the in built Wordpress wizard. Same goes for PHP support, Django, Ruby, you name it! Cherokee’s web interface gives you super fast access to all of these features, without you digging around conf files and killing your server because you typo’d “AllowOverrride”. If you want some big names that use Cherokee? Well, there aren’t any… but that should not stop you using it!

M is for MySQL

MySQL has had a turbulent life. It was acquired by Sun not so long ago, some took this badly, and many speculated on the outcome of MySQL. Recently, Sun was acquired by Oracle, which has only refuelled the speculation. Around the time Sun acquired it, a few engineers released open source alternatives; MariaDB, and the depressingly named Drizzle. There are, however, other efforts to improve on database utility, including moving out of RDBMS altogether…

PostgreSQL (Linux, Windows, Solaris) - PostgreSQL “BSD Style” License

PostgreSQL, the successor to the Ingres SQL database is an RDBMS very similar to MySQL. The biggest difference on the surface, is that PostgreSQL is a single layered engine, that is to say it has one storage engine, unified with the database driver (as opposed to MySQL which has MyISAM, InnoDB, Maria et all). Speed wise PostgreSQL’s storage is pretty much identical to MySQL’s; and is fully ACID compliant (whereas MyISAM isn’t, and InnoDB barely is). Otherwise, pretty much everything MySQL does, PostgreSQL does to: Inner & Outer Joins, Transactions, Stored Procedures, Triggers, the list goes on. There are many small differences that may or may not bother you - for example something that bugs me is the lack of TinyInt and MediumInt types. Another gripe I have with PostgreSQL: the lack of a decent admin interface. When you look at MySQL Administrator and MySQL Query Browser you see two very powerful yet very easy to use tools. PostgreSQL has pgAdmin 3 which in my opinion pales in comparison. Ultimately though, PostgreSQL is a well supported & documented standards oriented database engine, with speed pretty much identical to MySQL, with the added benefit of much looser licensing, and is used by many big names including Skype, Yahoo!, and the amazing OpenStreetMap.

MongoDB (Linux, Windows, Solaris) - AGPL 3 License

MongoDB is a product of the “NoSQL” movement, which is getting a lot of hype at the moment. Trying to keep within this article’s scope, “NoSQL” storage is pretty much dumb storage, non-ACID, non-RDBMS. In other words, what you get is a very simple storage layer that lets you look up a key, and get a value. Forget inner/outer joins, cascading, triggers, constraints - pretty much forget everything to do with SQL (Hense, NoSQL). The benefit of losing all of this, is that they are ridiculously faster than the likes of RDBMSes. Even faster than that. A rough estimate for MongoDB is that it is 15-20 times faster than MySQL/PostgreSQL. So you lose a lot with something like MongoDB, but you also gain a lot. You probably aren’t going to need the kind of performance MongoDB achieves unless you’re huge and struggling with the speed of RDBMS. But perhaps is especially cool about MongoDB in particular is that it uses JSON for resultsets, so you don’t have to waste time processing a resultset, just a quick parseJSON(); will get you a nice keyed array in PHP. Beautiful. MongoDB is pretty new - but SourceForge uses it.

Cassandra (Linux, Solaris) - Apache 2.0 License

Cassandra is a different beast to MongoDB, but still fits within the “NoSQL” bracket. It was written by Facebook to replace the relational database they use, inspired by Amazon’s Dynamo. Cassandra is designed to run on a cluster, which is where it’s strength lies. Cassandra is pretty much the poster boy for the NoSQL movement, with massive sites such as Digg, Reddit, Facebook, Twitter - basically every site that takes an unfathomable amount of data in and out daily. An important thing to think about here - many of these sites are still using an RDBMS, and Cassandra has not been a complete replacement for them.

P is for PHP

PHP is the double-sided coin of web development. A lot of hatred for PHP floats around, some of it justified. Parts of PHP are a huge mess, for example the whole haystack-needle-needle-haystack thing and the huge delays with PHP 6, not to mention the convoluted politics with the core developers. However, PHP is still the single most widely used server side scripting language. Period. Couple PHP with excellent frameworks such as CodeIgniter, CakePHP, Symfony, or just look at great projects like Wordpress, Drupal and ExpressionEngine, and the problems seemingly slip away. However, there are some really interesting languages that might just surprise you…

Ruby - GPL License

Ruby is a Strong Object Oriented (Strong, as opposed to PHP’s Weak Object Oriented model) language created in Japan, inspired in some part by Perl. Ruby’s main reason for success on the web is 37Signals’ Ruby On Rails project - a framework not too dissimilar to CakePHP (CakePHP started out as a “Rails” clone). Ruby is certainly faster than PHP, and nicer looking (which I feel is important, case in point). In fact, there isn’t much to dislike about Rails, or Ruby for that matter. But then you’ve not met Python!

Python - Python License (GPL Compatible)

Python is a mature and beautiful language, successor to ABC (a BASIC alternative). Don’t let it’s background fool you though - Python is nothing like BASIC. Python has a massive library of… well, libraries, an interactive shell, can be compiled or interpreted, is great on the web and on the desktop (a lot of great Gnome/Ubuntu applications are written in the Python language). Like Ruby, the code is very clean (perhaps cleaner). Python has two strong pillars of web-frameworks: Django and TurboGears. This post is pretty long already, and so I’m not going to go in depth about Python - but let’s just say after 8 years of PHP I’m about ready to jump into Python. Also, if you have a Linux or Mac OSX machine, you already have Python installed! And if you’re interested in moving away from PHP to Python, check out this site for some great migration tips!

Javascript - No License?

I bet you were pretty surprised when you read Javascript right? There’s a lot of discussion about using Javascript on the server side, also known as SSJS. This idea isn’t new, but thanks to new Javascript engines like Rhino, SpiderMonkey and V8 it becomes a viable choice. Javascript itself is a mature, well formed language, which once again has a Strong Object Oriented approach. There is one huge benefit of using JS server side: your developers (or you!) can write in one language. If your developers work in both backend and frontend this can be quite a good idea. The big downside is that SSJS, despite its age is really not very mature, many like Node.JS (which runs the awesome V8 engine) run standalone servers, which becomes a problem of scalability & flexibility. Others such as JSEXT are very promising, but for mission critical applications don’t have enough evidence to justify to your boss or client.

Bonus: Google App Engine

Google’s App Engine (GAE) is a free hosted environment for your application or service. It uses Google’s proprietary web serves such as it’s GWS web server, and it’s BigTable NoSQL datastore. You can code your apps in both Java and Python, but some bright sparks have gotten PHP to work through Java, which means you can install Wordpress on GAE! There are some downsides to GAE, especially considering it is built around proprietary web services, portability is a huge issue. But it is a worthy consideration, especially when bootstrapping a startup company, or if looking for a cheaper service than Amazon EC2.

What is right for you

Ultimately you’ll have to pick what is right for you. Many hobbyists chose the ULPPy (Ubuntu, Lighttpd, PostgreSQL and Python) stack. If you’re deploying a large scale application, you’ll most likely extend the LAMP stack with tools like NginX and Cassandra, so uh… LANCMP. The “in” side of web development are using UNMR (Ubuntu, NginX, MongoDB and Rails). Perhaps the best combinations are the hardest to make acronyms out of? Personally, I’ve become pretty sold with UCPPy (Ubuntu, Cherokee, PostgreSQL, Python), and over the coming weeks will be converting my home server to this setup, as I continue to dive into python. But that’s another story…