We’ve already talked about some of the technology choices we’re making as a company. And while our choices on the back-end can hardly be labeled as mainstream, the most difficult choice we actually had to make was related to the client-side as it directly affects our users. Obviously, Javascript on the client is a given, and we love it. However, as most web developers know, the differences between browsers are enormous and developing for all of them is almost impossible. Still, current conventional wisdom dictates that you should support recents versions of Internet Explorer, Firefox and the WebKit based browsers (basically, Safari and Google Chrome). We, however, have decided to drop Internet Explorer support entirely.

In general, the trade-off you face when choosing which platform to develop for is between development time and a larger potential customer base that’s associated with the platform. Looking at the web right now, Internet Explorer still leads the market by a large margin. So even if it seems annoying that you have to work around some CSS bugs or still write Internet Explorer specific event handling code for a web site, the payoff in user reach will usually still be worth it. Modern Javascript libraries such as jQuery or Mootools lower cross-browser development time even more by abstracting away lots of differences between browsers, tipping the equation even more in favor of Internet Explorer support.

So why did we choose to ignore the most used browser on the planet? It’s because we decided that in our case, the development costs would simply not be worth it. Obviously, this assessment is very specific for the type of application we’re building. We didn’t just base this on a hunch, we actually have quite some experience in this field: most of us have worked on products like Xopus before. Xopus is an awesome, browser based wysiwyg XML editor. It consist of more than 120,000 lines of client-side Javascript code. A non-trivial part of that is code that completely works around standard Internet Explorer behavior because of its bugginess or complete lack of support. This isn’t about your father’s unsupported CSS selectors or the lack of addEventListener. We’re talking about stuff like having to write your own cursor because contentEditable becomes basically useless when working on complex documents. The amount of bugs that are related to contentEditable, text ranges, drag and drop and the Document Object Model in general are staggering. Most JavaScript projects, including some popular libraries, don’t even deal with these advanced aspects of the browser at all.

Now obviously, the other browsers aren’t all free of bugs. Which brings us to the second problem with Internet Explorer: lack of real progress and transparency. Even if you consider relatively easy and popular features (such as support for addEventListener), it’s hard to understand why they haven’t been implemented yet and if there is any timeline at all to implement them. That makes the probability of low visibility improvements and bug fixes in the rendering or selection code practically zero. The contrast with the open development of Mozilla and WebKit is huge, where almost everything is publicly discussed and with a focus on constant improvement of the rendering engines and pretty clear timeline.

The current state of the web is actually very exciting right now, if we ignore Internet Explorer for a moment. Thanks to HTML5 there is a lot of progress allowing us to make almost desktop class applications, with support for things like drag and drop from the desktop, background processes and offline support. All of this should greatly improve the user experience with web applications and bridge the gap with desktop applications. No amount of code or smart engineering will allow us to bring that level of experience to browsers that lack these features.

Does this mean that no complex web application should support Internet Explorer? Obviously, it depends on many factors. There are large differences between applications that are targeted to tech-savvy users (where Internet Explorer is quickly becoming a minority browser) or to large organizations (where Internet Explorer 6 is still widely used). We’re a small team and we have to prioritize our development goals aggressively. Large teams with lots of resources are in a different situation altogether. That being said, we were pleased to see that the Google Wave team also chose to drop Internet Explorer support and having Google develope the Chrome Frame plug-in.

Finally, although this might seem less important than the above considerations from a business perspective, there is the loss of friction and return of enjoyment in developing web applications again. Not developing for Internet Explorer means that we can do amazing things with CSS, use new Javascript features in our codebase, and in general rediscover the excitement of the possibilities of the web. And that makes us love web development again.

‘What’s typLAB then?’, you might ask.

typLAB is our initiative to investigate and develop new ways of creating and consuming web-based content. We aim to explore the boundaries of what’s possible using contemporary internet technologies. The result of our endeavors should enable you to read and write rich, dynamic and smart articles like you’ve never read nor written them before.

Next question. ‘Who are those “we” you keep referring to?’

We are Erik Hesselink, Sebastiaan Visser, Salar al Khafaji and Lon Boonen. That’s the team; small, smart, focused and eager to learn and share. Most of us share a history at Xopus, the web based XML editor.

One more question? ‘What about lablog, what can we expect from it?’

Through lablog we want to inform you of our ponderings and wonderings. Our steps forward, backward and sideways. We’ll write about our progress, our discoveries and the things that make us tick.

You can expect articles on HTML5, CSS3, web development in general, Haskell, XQuery, usability, semantics, JavaScript and all stuff that makes a nerd’s heart jump a beat. Or two.

And we’d love to hear from you. Through the comments, Twitter or plain old e-mail.