Why do it yourself? Somebody else already did it for you!

Wouter Bos — Mon, 07 Dec 2009 20:29:15 +0000

Sometimes the possibilities you have as developer seems endless. Do you or your company need a CMS? Lock yourself up for a few weeks and you have one. In need of an online video player? Look for a tutorial online and create your own.

Creating something from scratch can be empowering. It also gives a sense of control, because you can determine what the specifications should be of a product. Better: you don’t only know the specifications by heart, you also know just what strings you need to pull in your code. Getting to know a product that you didn’t code from scratch seem hard to master. And it can even harder to know it’s limitations. That’s not a situation that you want to be in, when talking to a customer. And so it seems better to stay in control and build an application of your own for your own needs.

A CMS for everyone

And so in-house coded CMS systems pop-up everywhere. But why? Are the ideas of those companies about Content Management Systems so different compared to what is already on the market? Most likely not. In many cases the euphoria of having your own CMS will turn to into a slowly simmering frustration because the time needed for bug fixes and feature request doesn’t match at all with the time that’s available.

We all know that creating a product needs time. But what we tend to forget is that keeping a product “healthy” and up-to-date also costs a lot of time in the long run. And so we have a plethora of CMS systems with loose ends and incomplete functionalities. Most of the time with an unfinished “help”-function.

For years I was accustomed to do as much as you can yourself. But now that the internet is getting bigger and bigger, you see companies specializing. Some companies are focusing on only one or a few products like a CMS, while the creators of websites ask themselves: “Am I better in building a CMS or in creating websites?” In most cases it’s the latter. And so it’s better to find a product that helps you to do the job fast instead of slowing you down.

Example: a quick flash video player

Now you may think that a CMS is an obvious thing you shouldn’t build yourself because the codebase is so large. Well, lets take something that needs less lines of code: a simple Flash video player. Many companies have developed their own Flash video player. Because it’s just relatively easy to do. But again: why? Most of the time such a in-house coded player has minimal documentation, if at all. And if you find documentation it’s likely out of date. What really bugs me if you’re asked to just “Fetch that player from our previous project”. Like that’s an acceptable codebase.

I recently decided to go with the open source Flow player. I fell for the various options to customize the player. Soon I discovered all kinds of advantages you wouldn’t have with your own code: Forums, wizards and extensive documentation. I could send a designer a link to a wizard that enables him to skin the video player at a basic level. I also could pass the player to another team member without having to explain every step in the code. The documentation is online, help yourself. Let me continue with my work.

Another example: Javascript libraries

Libraries really can speed up your work. They do not only provide lots of canned functionality, but libraries like Prototype, Mootools and jQuery can also really speed up your own coding. jQuery really helped me to code faster, more stable and in less lines of code. It made coding in avascipt even more fun.

There are lots of resources out there. As a web developer you need not only to know your code languages, you also need to know when to use some existing code and know where to find it.

No related posts.

What you can’t do in IE’s Quirks Mode

Wouter Bos — Thu, 26 Nov 2009 23:00:26 +0000

As most of you probably know IE can render websites in either Quirks Mode or Standards Compliant Mode. Standards Mode is the mode that is most compatible with other browsers like Firefox, while Quirks Mode exists for backwards compatibility purposes. IE automatically chooses one of these modes by looking at the first line of the HTML code. Check out Quirksmode.org and Wikipedia if you want to know more about both modes and how to trigger them. But in case you want the short summary: if you don’t start your document with a DTD like the example below, IE will render the website in Quirks Mode.

I only build websites in Standards Mode, so Quirks Mode is an almost non-existent issue for me. This week, however, I had to restyle an old website. And while rewriting the CSS I remembered that the difference between the two modes goes farther than just a difference in box model. Simple things you’ve learned to rely on in Standards Mode are gone in Quirks Mode.

No `* html`

If I want a class to specifically target IE6 or IE7 I always prepend selectors with * html (IE6) or *:first-child+html (IE7) in case the rendering is a bit off with other browsers. But that simply doesn’t work in Quirks Mode. On Wikipedia there’s a list of browser bugs you can exploit in CSS. I chose to exploit the ”!important quirk“ since future browsers will just ignore the invalid CSS code that only runs in IE6 and IE7.

To use the ”!important quirk“ you misuse the !important keyword. Normally that keyword is used like this:

.classname {
    width: 100px !important;
}

The !important keyword ensures that the width of 100px cannot be overruled by other styles unless you use another !important. In IE6 and IE7 any keyword that starts with a ! works like a !important, so you can write something like this:

.classname {
    width: 100px; /* works in all 'normal' browsers' */
    width: 150px !lteIE7; /* for IE 7 and lower */
}

No fancy selectors

What surprised me much more is that some advanced selectors like the attribute selectors are not possible in IE7 when running in Quirks Mode. So the CSS code below will only work in Standards Mode:

table[width='160'] { /* this selector will not run in IE7 Quirks Mode */
    width: 100px;
}

The same holds true for selectors like :first-child, the Adjacent Sibling (+) Combinator and the Child (>) Combinator. Bummer.

Why not use conditional comments?

If you want to have some classes that are specifically targeted towards IE6 and IE7, Conditional Comments are the easiest and safest thing.

But I prefer CSS filters above conditional comments. By using CSS filters I have all the styling of an element in one page and not scattered around in different CSS files. In most cases I only use conditional comments to hide CSS code that won’t validate.

More information about conditional comments

Code for the sake of Technorati: 4252WKT38H9D