David’s Web Development Blog

Maybe this comes as a no-brainer for a lot of you, but I’ve found that unless I’m super-comfortable with writing a bit of code I know will work, I find myself constantly checking it to make sure it’s working properly, each step of its journey to completion.

This constant checking of code may in passing resemble unit testing, but it’s quite different.  It’s a progressive adding of units to the whole, then constantly checking the whole.

Of course this comes with an obvious downside: it seems to take a lot longer to complete the code.  On the plus side, the finished product is free from at least obvious bugs.  That’s because at each step of the way to completion, if there’s a problem, I sit down and tackle that problem and nip it in the bud.  Knowing that the problem is probably in the recently-added code makes testing a lot more easier than looking at the complete product and slowly narrowing it down, and commenting out whole sections of code in the process.

Maybe this technique isn’t for everyone, but it’s seemed to work for me so far in producing quality code.

But on the other hand.. maybe everyone does this?  I really don’t know!  I just can’t imagine sitting down to write huge sections of code without ever testing it progressively along the way.  Maybe this is some esoteric rule of programming.  Or maybe it’s just too completely obvious for anyone to mention, so they don’t? 

The second edition of Nicholas C. Zakas’s Professional JavaScript for Web Developers has just been released, and thanks to the YUI Blog, there’s an entire chapter (Chapter 18: Advanced Techniques) available for free online.

I do have the first edition but so far haven’t sat down to read it.  Skimming over the free chapter, however, is pretty interesting.  Early in the chapter, Zakas explains a technique called “lazy loading” that carries quite a different meaning from the “lazy loading” I’m familiar with (which involves delayed loading of images “below the fold” or delayed script loading, for instance).

Instead, the type of lazy loading Zakas is referring to is something such as a function written to handle an XMLHttpRequest (XHR), which you should be familiar with, as it’s the basis for the Ajax craze (no worries if you don’t know it - we all didn’t know it at one time, but if you’re reading this isn’t probably time you read up a bit on it!).  The reason for writing the function to handle XHR is because of browser discrepancies: IE uses ActiveXObject and all other browsers use XMLHttpRequest.  Ok, no big deal, so we’ll write an if-then statement to check which one’s supported, right?

The trouble is that most people would be satisfied with this.  And no worries, it’s a solution that works, right?  But Zakas explains that this if-then statement will end up being run more than once, when that need not be the case if it were optimized.  To optimize it, the function runs once and then redefines itself based on which XHR property was supported, thus jettisoning the if-then statement, which at that point is unneeded.

Awesome!

And that’s just part of chapter 18!  Hmm, that’s got me really interested in the rest of the book.  Time to give it a read

jQuery 1.3 was released today, on the third anniversary of jQuery.  The speed comparisons in the release notes should be enough to convince anyone to upgrade.  It shows even a marked increase in speed against jQuery 1.2.6.  There’s no comparisons against YUI however, but I’m sure all the improvements of the impending release of YUI 3.0 (including all the event bubbling and such) should warrant someone to investigate eventually.

More interestingly, this version of jQuery uses a new Javascript selector library called Sizzle, which is lightweight (3k minified and gzipped) and is being billed as a standalone “engine” which doesn’t have any dependencies.  It looks like a great way to get some CSS3-esque selector abilities (things like :first or :last) without commitment to implementing a whole JS framework (like jQuery).

Here’s some of Sizzle’s features as described on its website:

Features:

• Completely standalone (no library dependencies)
• Competitive performance for most frequently used selectors
• Only 3KB minified and gzipped
• Highly extensible with easy-to-use API
• Designed for optimal performance with event delegation
• Clear IP assignent (all code held by the Dojo Foundation, contributors sign CLAs)

Code Features:

• Provides meaningful error messages for syntax problems
• Uses a single code path (no XPath)
• Uses no browser-sniffing
• Caja-compatible code

If you’ve done any sort of work with rounded corners on webpages, you know that they can be tricky to pull off.  In any case, it’s a lot harder than it really should be.  Working with rounded corners is almost like adding graphical borders around elements as if the CSS border property didn’t exist.  It’s a lot of effort for something seemingly so minor.

While it may not be completely representative of the majority of web developers, I have been noticing a subtle shift away from rounded corners.  For instance, late last year, Google Reader eliminated its rounded corners (along with a few other “Web 2.0″ trends like drop shadows).

Firefox rounded corners

Something similar was my discovery that the very popular Twitter actually only displays rounded corners in Firefox.  Why only Firefox?  Thanks to the Firefox proprietary spiffy and quick proper -moz-border-radius CSS property:

//make all four corners round in Firefox
-moz-border-radius: 4px;

And of course it’s always nice to have fine-grained control of each separate corner:

//make specific four corners round in Firefox
-moz-border-radius-bottomleft: 4px;
-moz-border-radius-bottomright: 4px;
-moz-border-radius-topleft: 4px;
-moz-border-radius-topright: 4px;

But note that viewing in IE or Safari will be the conventional square corners.  But it doesn’t look bad, really.  In this case the rounded corners can be considered progressive enhancement for users with Firefox.

Webkit rounded corners

Within the past few months I also discovered a proprietary “border radius” property in Webkit browsers (Safari and Chrome): -webkit-border-radius, which works the same way as the Firefox border:

//make all four corners round in Webkit
-webkit-border-radius: 4px;

And the more refined control:

//make specific four corners round in Webkit
-webkit-border-top-left-radius: 4px;
-webkit-border-top-right-radius: 4px;
-webkit-border-bottom-left-radius: 4px;
-webkit-border-bottom-right-radius: 4px;

So if you want a painless way of pulling off rounded corners, you can now achieve that with pure CSS for browsers such as Firefox, Safari, and Chrome!

However, all together, these represent the minority of web browsers.  If you want your precious rounded corners in IE as well, then you’ve got to go back literally to the chopping block to slice and dice some images.

Javascript rounded corners

OR you could even try newer methods, which use Javascript (specifically jQuery) to painlessly implement the rounded corners.  Then you can go back and work on the stuff that really matters…

John Resig has a really informative writeup at his site detailing the process of finding and reporting browser bugs.  In addition to describing a good bug report, he gives the following direct links for reporting bugs for each mainstream browser:

• Mozilla/Firefox
• WebKit/Safari
• Internet Explorer 8
• Google Chrome / V8 JavaScript Engine
• Opera

Not only this - he also gives some advice regarding downloading the very latest builds of these browsers.  Testing with these builds allows the development teams to nip problems in the bud and will therefore save you and many other developers future headaches.

Here’s some links for downloading the latest browser releases:

• Firefox Nightly Release
• WebKit/Safari Nightly Release
• IE 8 Betas, IE 8 Weekly Builds
• Google Chrome Nightly Builds
• Opera Desktop Team Blog

(via John Resig’s blog)

So you have your webpage.  And you have your visitors.  You’ve spent all your time trying to make a cool visual and interactive experience, but chances are you’re viewing your webpage mostly from the cache, and you never realize how slow your webpage is actually loading for everyone else, what with all of those images used in the layout.

Try deleting your browser cache and loading your page cold.  Kinda slow?  Here’s some things you can do to speed it up (many of these tips are from Yahoo developers):

1. Cache your dynamic webpages.

TONS of webpages these days are displayed dynamically, mostly from PHP-based webpages.  The classic setup is to have PHP fetch page data from a database, commonly MySQL.  So what’s the problem?  It’s slow.  It crashes when too many visitors try to access the database at the same time.

It’s a pity, too, since though these users are fetching “dynamic” content, most of them are actually fetching the same data.  In other words, data that might as well be a static HTML page until it’s updated again.  This is essentially a cache.  It works independently from the database, and thus and isn’t limited by its shortcomings.

If you run a blog using Wordpress, I recommend WP Super Cache (even though I’ve occasionally had some issues with it).

2. Use HTTP Compression (gzip)

Configure your server to gzip served components.  This GREATLY reduces the size of plain text content.  To use this in Apache, use mod_deflate.

3. Optimize images

Ooh, now we’re getting to the meat of it.  Unless you also host files or videos, images will be the largest part of your webpages.  As such, wouldn’t it be nice if there was a way to optimize them?  Well…

• For large images: Optimize using smush.it, which compresses images losslessly.  But sometimes it’s just not worth optimizing images, and in that case smush.it will let you know exactly how much space (or lack thereof) was saved during compression.
• For small images: consider using CSS Sprites.  To be honest, sprites are a pain in the neck to pull off, so try using an automator.  I hadn’t heard of webpage sprites until recently.  Think of this: you have 10 small icons that need to be loaded.  If they are separate images (traditional), there will be 10 separate requests to the server.  Instead, put them all into one file and position only the element you want with CSS.  The result?  Just one server request for 10 separate images.  Does anyone actually do this though?  Yes!  For one, Yahoo uses this for the navigation icons on their front page, and they pride themselves in having a fast load time.
• And if you’re planning on resizing content, resize it yourself.  You don’t want the user to download more than they have to, just to have their browser go ahead and downscale it after downloading.  I STILL see webpages with full-resolution photos used as thumbnails.  Stop doing this, people!
• Also, unless you want some sort of image animation, do use PNG instead of GIF.  Not only is it usually smaller and lossless, contrary to popular belief its transparency attribute is actually supported in all major browsers, including IE 6 (boo, hiss).  That is, if you’re using PNG8 with index transparency and not alpha transparency.

4. Minify Javascript and CSS (and maybe HTML?)

Once your Javascript and CSS is finalized and ready to go, use a minifier to remove at the very least extra unneeded spaces and comments.  The downside is you have to keep separate unminified versions that are actually readable by human eyes.  And they have to be reminified every time you make a change!

And if you’re adventurous enough, also minify your HTML.

5. Use YSlow for Firebug.

But take its advice with a grain of salt.  For instance, most small-time websites (including mine) don’t use a CDN (content distribution network), so don’t worry when you get handed that F grade.

6. Put your CSS at the top and Javascript at the bottom

Position matters.  Yahoo found that putting CSS at the top of the page, will give the appearance of the page loading faster.

Likewise, it found that putting Javascript at the bottom of the page forced the browser to first render content above it before calling the script.  Makes a lot more sense to render visual content before interactive content.

Or, if you want to get fancy, you can even…

7. Dynamically load Javascript

Putting Javascript at the bottom of the page should work, but if you want full control of when your scripts are loaded, you can load them dynamically.

For example, if you’re using the YUI framework, the only Javascript you need to call from your HTML directly is YUI Loader, which acts as a seed and will dynamically load additional YUI components (as well as other CSS and JS components) after the page has finished loading.  Neat.

8. Dynamically load images “below the fold”.

A working example of this is Yahoo! Shine.  Notice that the images load as you scroll down the page.  This is accomplished with the YUI Image Loader utility.

While it’s awesome for performance, for some reason I don’t find the effect annoying at all.  By its description I would expect to be annoyed by it.  But as long as the images load fast as I scroll, it’s actually sort of a positive reinforcement that the webpage is responding to my scrolling.  Weird.

9. Reduce requests by combining HTML, CSS, and Javascript (but only if you have TONS of visitors)

Experienced web developers will DEFINITELY balk at this one.  “But David, we’re supposed to keep everything separated!”  I know, I know!  It’s been stressed many times that web developers should separate their content (HTML) from their styling (CSS) and interaction (Javascript).  No inline styling, no inline scripts, etc, etc.

While this is good for maintaining your website and just plain good practice, I’m unsure if it really speeds up loading of your webpages.  What makes me unsure?  Take a look at the sourcecode of the Yahoo frontpage.  Other than looking like a complete mess, notice that there’s a LOT of inline CSS and Javascript.

Ok, by now it’s obvious I’m really familiar with all things Yahoo, so let me use another big example.  Check out the code on Google!  Same thing: inline CSS and scripts.

What gives?  Like my previous tip on using CSS image sprites, it’s always good when you can reduce server requests.  Especially for hugely popular sites that live and die on “uptime” and serving webpages fast.

But this is probably not so useful for the average Joe, where those extra requests are really not noticeable.  In that case, keep your CSS and Javascript separated from your HTML!

10. For PHP: use flush();

Another trick that Yahoo pioneered.  By default, PHP will only send your browser data once it’s parsed together your complete webpage.  So while the header and footer content might already be rendered, it might take just a little bit longer to get the body content.  Using flush() will send to the browser all the content already rendered.  This will result in a faster response, so the user’s browser can start grabbing content requested by the outputted HTML.

Need more tips?  Check out these related articles:
Yahoo’s best practices for speeding up webpages
YUI Blog: Image Optimization (4-part series written by Stoyan Stefanov)
20 Tips and Tricks to Speed-Up Your Wordpress Blog
25 Ways to Speed Up your Website

Know a useful tip that’s not listed?  Leave a comment below!

http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf

Awesome! This looks vaguely familiar, but I’m not sure I’ve read it before.  There’s a lot of great tips here - definitely helpful to read before you start planning your website.  It’s easier to implement this stuff in the development phase than when the site is already live!

(via creativetechs.com)

As you may or may not know, there are users across the internet who don’t have Javascript.  Yes, that might be shocking and terrifying, but you have to deal with it!

Good websites try to code in such a way that allows all users to access content, with or without Javascript or other plugins.  This is what’s coded first.  Then all the cool Javascript interaction and such is added on top later, for Javascript-enabled users (the majority).  This is called Progressive Enhancement, a buzz word you should know about if you’re in the web development business.  I’m sorry to say that I myself didn’t know anything about this until recently, when I immersed myself into more modern web development.  Oh yeah, and when I was asked about it on my internship interview with Yahoo.  How embarassing that I had to confess I hadn’t even heard the term…

Anyhow, long story short, the <noscript> tag comes in handy.  Code rendered inside this tag will only render when the user doesn’t have Javascript enabled.  So at the very least you do something like this:

<noscript>Sorry, this site requires Javascript.  (and I was too lazy to make the site work without it)</noscript>

I’m sure someone will find this useful, even though it might seem obvious to the veteran developers.  Someone who might benefit might be this site I came across today (to be fair, it looks like it was developed a while back, since the layout uses tables).

I was a bit confused at first because I saw the common “This page requires that JavaScript is enabled on your browser” message.  I thought something was wrong with my computer, since obviously I have Javascript enabled.  But then I realized the text is hard-coded and displays for all users.

All the developer had to do was put that text in <nocode> tags!  But instead it results in some confused visitors.

One of the first things I learned at my internship over the summer was the difference between Standards and Quirks mode.  Basically, the idea behind quirks mode is for browsers to be backwards-compatible.  If a webpage is missing a DOCTYPE tag or has some sort of “transitional” doctype tag, the page will be rendered according to the previous version of the browser.  So say we’re using IE7 and we run across a page that has no doctype specified.  IE7 will assume it’s an old, outdated page, and will render the page just as it looked in IE6.  That’s quirks mode.

So obviously it’s pretty important to have a doctype tag if you want your webpage to display in Standards mode, as expected.  For instance, it’s mostly recommended to use this this code right before the <html> tag:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Dustin Diaz at Google, taking into account the fact that “every byte matters”, chopped down the doctype to the following:

<!doctype html>

After using the huge ugly doctype declarations for years, I can see why someone would be skeptical that this simplified doctype achieves the same results.  I was skeptical myself, so I tried it out.  With the help of Browsershots and a little Javascript property called document.compatMode, I was able test out the doctype in various browsers.

The test I used: when a document is in Standards mode, document.compatMode is equal to ‘CSS1Compat’.  Otherwise, the document is in quirks mode and document.compatMode is equal to ‘BackCompat’.  I wrote a little script that simply tests for this property.

Ok!  So does our shortened doctype actually force pages into Standards mode, as we hoped?  Yes, for 100% of browsers I tested.

Based on my own tests and thanks to BrowserShots, I was able to see that all of the A-grade browsers are forced into Standards mode.  That means IE 6.0 and 7.0, Firefox 2.x and 3.x, Opera 9.5x, and Safari 3.1x.  That’s the majority of web browsers right there.

But the test also passed on other browsers.  In my opinion, Google Chrome and IE 8.0 should both be A-grade by now, but aren’t officially listed as such by Yahoo (yet).  But don’t worry, they both passed, as well as a host of other crazy browsers I’ve barely heard of or never heard of (mostly *nix-based): Navigator 9.0.0.5, Mozilla 1.7.8, SeaMonkey 2.0, Avant 11.7, Flock 2.0, K-Meleon 1.5.0, Epiphany 2.22, Galeon 2.0.6, Minefield 3.1, Iceape 1.1.10, Iceweasel 3.0.1, Shiretoko 3.1.

So did anything fail the test?  Well, as it turns out, IE 5.5 and below don’t define the Javascript property document.compatMode.  So they simply leave it undefined.  In other words, they have no Quirks mode.  They are the older browsers.  For them, there is no Standards compliance mode.

That’s it.  Nothing outright failed.  It’s perfectly safe to use that simple doctype if you want Standards compliance mode.

Related:
Link to my test script
Simplified doctype now in use in Google search (view the source code)

(Ajaxian via Dustin Diaz’s blog)