jQuery, MooTools, Prototype, YUI and Dojo all have at least one thing in common; they’re all partial abstractions of JavaScript, the “official” client-side programming language. Each of these frameworks enables further abstraction whether it is through “plugins”, “extensions” or “classes”. So where does the abstraction end? Or rather, where should it end?

The point in abstraction is to make something simpler by factoring out details. If we take jQuery for example, it abstracts away cross-browser pains; it essentially covers up the difficulties. This can make for faster development but can sometimes result in an abstraction leak.

The law of Leaky Abstractions, a term coined by Joel Spolsky, states that “All non-trivial abstractions, to some degree, are leaky”. A “leak” occurs when an abstraction breaks and you have to resort to a lower level abstraction to solve the problem. So, if jQuery fails to provide cross-browser sanity in a particular situation then you’re left to battle it via “pure” JavaScript (a lower level abstraction).

This highlights a common controversy: is it necessary to know JavaScript at all? Are you comfortable operating on a wafer-thin high-level abstraction like jQuery, MooTools, Prototype or any other framework? What’s your course of action when your beloved abstraction leaks?

How low can you go?

So, given that all abstractions are, to some extent, leaky, how low should you go? I think this can be answered with another question, how low can you go given the constraints of the platform? With our jQuery example the platform is the browser; this piece of software does not offer anything lower than JavaScript, so surely that’s as far as you should go!

Similarly, with CSS frameworks like BlueprintCSS and 960gs you should go as low as you can, which, in this situation is CSS itself.

Using frameworks is absolutely fine as long as you know the technology on which the abstraction was formed. If you want to use jQuery, learn JavaScript; if you want to use a CSS framework then learn CSS!

This get’s more complicated in the area of software engineering because the platform allows you to go very low. Should all .NET developers know how to write C++, should all C++ programmers have a strong grasp on Assembly? I can go on forever…

It’s a compromise!

If we define “control” as a reasonable level of supervision over a piece of functionality (whether it’s a form validator or an image cropper) then it has a negative correlation with abstraction; in other words, the higher the level of abstraction, the less control you have.

Recently I discussed the benefits of creating a jQuery plugin but I failed to point out the obvious flaw: by creating a plugin or extension for any framework you’re raising the level of abstraction even further covering up the details), thereby decreasing the level of control someone has over it. Fortunately, because it’s JavaScript, we never really lose control; we can change the plugin source at any time. But the end user of your plugin probably won’t know JavaScript to the same extent as you. The level of control they have is dictated by the level of customisation you offer with the plugin; but, the more customisation you offer, the bigger in size the plugin will be. Therefore the entire process is a compromise between control, simplicity, and most importantly, speed!

The higher the level of abstraction the slower it will be. Higher abstractions may speed up development time but the processing time will usually be longer.

document.getElementById(‘elem’) will always be faster than $(‘#elem’)!

Food for thought…

I was originally quite sceptical about the usefulness of this "technology" but I’ve come to realize where its true value lies, here’s an overview:

The first thing to note about Ubiquity is that it’s not a new technology; it’s a platform which makes use of current technology. Technically it’s a "Firefox addon" and that’s all it will ever be to the end user, but for us it is a usable platform on which we can develop specialised commands tailored to the user.

The reasons I was initially sceptical about Ubiquity:

• It’s not new; it takes pre-programmed commands and executes pre-programmed functionality, nothing special
• I heard about it a while ago (like 3-4 months ago) but didn’t hear of it again until 3 days ago.
• I could make something similar with a GreaseMonkey script. (I eventually realized I was totally wrong!)

Even after my subsequent realisation I wouldn’t say it’s a very revolutionary piece of software; essentially it’s just as I stated in the first bullet point, a pre-programmed interface with a limited comprehension (limited in that it only understands pre-programmed commands).

What can Ubiquity do?

• It can do anything!
• … with certain obvious limitations!

Developing for Ubiquity

This is so easy; in fact, you should go and download Ubiquity right now and try it out!

Here’s a quick tutorial; we’re going to create an MDC (Mozilla Developer Center) search command so we can search on the fly (scroll down to see the end result):

I thought I’d explore a more conventional and structured approach to the traditional rant. So here goes, a few things that bug me (quite a lot) when surfing the web:

Before I begin, please note that these opinions are my own – I hope I don’t upset anyone!

Unconventional navigation

Navigation is probably the most essential aspect of a website, it’s layout and usability is of absolute importance and must not be mistook for "just another element". Conventions are there for a reason; so that people know what the hell to do when landing on your homepage. Don’t try and be clever!

People always try and be too clever by extending they’re company’s tagline or motto into the navigation. Here are some examples of BAD NAVIGATION:

• PURPOSE | TRUST | PRIDE | RESPONSIBILITY | SCALE | FUN
• WHAT WE DO | WHAT WE’VE DONE | WHAT WE’RE THINKING | WHO WE ARE
• SURFACE | SUBSTANCE | SPEAK

While you may be able to decipher the meaning behind each navigation item they are definitely not conventional; Mr and Mrs Average wouldn’t find it very easy! I imagine navigating through websites with naming like that shown above would be easiest for children or people who’ve never touched the internet; it’s these people who have no preconceptions about how the internet works and what the conventions are.

Here’s a "translated" version of the above examples:

• ABOUT US | PORTFOLIO | NEWS | POLICIES | JOBS | GAMES
• SERVICES | PORTFOLIO | BLOG | ABOUT US
• HOMEPAGE | ARTICLES | FORUM

The difference between the two versions is clear; it only takes an impulsive millisecond to understand the latter set while it takes a great deal longer to understand the original set!

This isn’t just conversation; I genuinely get bugged by this kind of thing – people trying to be too clever, especially when there are conventions in place.

Over responsiveness

First rule of engagement: If you’re going to give something a hover state then it should be clickable! A hover state of any type, whether it’s a change in colour or underlined text, insinuates that the element can be clicked. The only time I find this acceptable is with tabular data, it’s useful when an entire row is highlighted because it allows you to see corresponding columns clearly. Most other scenarios bug the hell out of me!

Also, I hate when a website attempts to anticipate what I’m going to do. An example of this would be when buttons trigger events onMouseDown instead of onClick.

Functionless Controls

These are normally a result of a lack of degradability. When something looks like a button and I click it and nothing happens I get annoyed (and I’d imagine most people would too!). So, please make sure JavaScript controls are not visible when JavaScript is not enabled.

Ego Inflation Badges

What’s an ego inflation badge? – Well, here are some examples:

Feedburner stats will soon be seen in the same light as those hideous web counter LCD displays you used to find in website footers. Yes, they’re popular now but soon everyone will realize just how tacky they are. Yes, they can be integrated quite nicely into the design of a site but that doesn’t mean they’re any less egotistical.

As for the valid XHTML/CSS nonsense, I cannot stand them! Validation means nothing, it is only a means to crush bugs and any browser issues you may be experiencing, beyond that it’s just a totally unnecessary formality. If you have one of those ‘valid…’ badges a the bottom of your site, get rid of it! I used to have one ages ago but I soon came to realize how utterly pointless they are. If you do insist on having one then at least make sure your pages are actually valid! (otherwise it’s like you going to an anti-fur rally wearing a fox scarf!)

Donate!

I hate exiting the supermarket and seeing an old guy with a charity tin muttering words of plead right in my face! But I manage to walk past without punching him in the face because I say to myself, "It’s for charity; a noble cause". But I definitely draw the line when it’s not for charity – i.e. those massive Paypal donate buttons on personal websites. I’m totally okay with it on open-source projects but when it’s on somebody’s personal portfolio or blog I get annoyed. Having a ‘donate’ button (of any type) on your personal website suggests three things:

• "I’m so crap at my job that I can’t get money by conventional means"
• "I think I’ve helped you so much through my witty blog posts that you should pay me!"
• "This new ‘donate’ button will make me look more professional!"

Would Jeff Atwood suddenly start demanding money to continue blogging? No! So you shouldn’t either!

‘Clickjacking’, if you haven’t heard of it, is a method used by malicious individuals to trick users like you into clicking something without you knowing what you’ve clicked. It’s also known as UI-redressing and only works in browsers that support frames/CSS.

The idea is simple: An iframe is positioned above what looks like a clickable button on a website. This iframe is invisible to the user (opacity:0) and so the user unknowingly clicks on the iframe which may contain anything! This can be achieved through CSS alone, no JavaScript is required. A variation of this technique involves the use of JavaScript to move the iframe around the screen inline with the user’s cursor, therefore achieving the same thing but without having to convince the user to click on a button.

Background info

I believe the original concern was related to Flash and how a user could unknowingly enable their webcam and microphone so the attacker would have access. There are some other examples shown here: http://www.grc.com/sn/notes-168.htm.

Adobe resolved this issue in October of last year with a new release of Flash Player. Obviously this only offers protection for that particular exploit – gaining access to webcam/microphone; other more rudimentary techniques still work perfectly today.

Last week Nettuts’ editor Jeffrey posted about a new screencast competition. This isn’t my entry – it’s just a test-runner to see if I’m any good at the whole screencast thing. It’s a 30-minute screencast about event delegation in jQuery and in it I explain event bubbling/propagation and then go on to demonstrate how to develop an event delegation plugin for jQuery.

Note: The quality isn’t too great but if you make it full screen it’s much better!

Thanks for watching, if you have any feedback I’d love to hear it! I’m planning on recording my entry for that competition soon, it’ll also be on jQuery although I’m not sure of the exact topic yet…

As far as the internet is concerned, you’re a spammer until proven otherwise. In fact, many websites require us to pass a test just to prove that we are human. We might fool ourselves into thinking that we have the whole bot/spam think under wraps but truth be told, it’s much worse than we think; it’s controlling us!

In a perfect world we’d be able to detect a spam-bot from it’s movement around a website without having to interrupt a visitor (who could potentially be a human); actually, in a perfect world there would be no spam-bots at all but, due to the greed and idiocy of mankind, such perfection will never be achieved…

If there’s a crux to this entire issue then it would be this question: How exactly can we use technology to determine between something which is human and something which is not? It is definitely possible but with current methods we’ll never be able to guarantee a spam-free environment.

There is another really big problem though: many spam messages you’ll receive on a daily basis will have originally been typed out by a real human!

Take this example, I received this as a comment on an older post at 7:46pm tonight:

My name is Sabrina and I’m new to this site.

According to this message, a person, probably female, has arrived at my website and has been so enthused that she’s decided to write about her recent accomplishment (the accomplishment of being new to a website)!

Five things about this message make me 99% sure it’s spam

About a month ago I decided to begin on the long and tiresome journey of learning regular expressions. I even bought the book! So, in this post I’m going to share some of the awesome things I’ve learnt so far on my "journey".

The first thing to note is that I’m no way near the end of my journey and I’m still very much a novice in this area, so if an expert happens to stumble across this post I would very much appreciate some light-hearted critique! If you’re a novice like me I hope you can gain something from my ramblings.

Unrelated: I’d like to attribute the top speech bubble in the image to the right to XKCD. It’s from this comic!

Defining Regular Expressions in JavaScript

Most modern programming languages have support for regex (regular expressions) but I’ll be focusing on JavaScript’s implementation because that’s what I’m best at! It doesn’t really matter though because the typical regex notation varies little between implementations (As far as I know).

Like everything in JavaScript you can either create a regex pattern by using literal notation or by calling the constructor function of the ‘RegExp‘ object:

// Using a regex literal:
var myRegexPattern = /Regular expression goes here.../;
// Calling upon the object:
var myRegexPattern = new RegExp('Regular expression goes here...');

More info on the two methods can be found here: developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Regular_Expressions

The first method (using a regex literal) is faster than the second but it compiles your pattern when the script is evaluated as opposed to the second method (Calling the object constructor) which compiles your pattern at runtime. So, if you wanted to include some variable data (perhaps from user input) in the pattern then using the object constructor is your only option. e.g:

I thought I may as well join in and give my best shot at forecasting the happenings of 2009 within the web industry.

Before I begin on what is bound to be a whole load of rubbish I’d like to share a few of the predictions from BT (British Telecom) [PDF] which were made back in 2005 (the following are expected to happen between 2006 and 2012):

• "Self destructing DVDs used for video hiring" (Erm…)
• "Personalised adverts on Radio" (Not yet)
• "e-ink screen advertising billboards" (Cool idea, but no)
• "Live CD-based OS distributed in newspaper" (What’s the point?)
• "MP3 Net downloads dominate over CD distribution" (I think this has happened)
• "Supercomputer as fast as human brain" (well we’re close)
• "Paypal migrates onto high street" (has this happened?)

My predictions

Good news for jQuery

This isn’t really a prediction, more of an obvious truth. jQuery’s recently acquired corporate endorsements (Nokia, Microsoft) will ensure the library’s ’survival’. jQuery 1.3 will surely be another smash hit, and with it, jQuery’s (Aka Mr Resig’s) monopoly will continue to grow. Sizzle will prove fantastic and will be massively adopted, not just by other libraries, but also as a means to quicker DOM traversal/management without the overhead of an entire library (web developers are bound to adopt it as a single entity).

jQuery will eventually (probably by the end of 2009) plateau at a high usage level and will remain largely static on a comparative level, however it will certainly continue to grow alongside all other JavaScript frameworks/libraries.

Other libraries will continue to grow steadily. MooTools will probably gain more exposure and more web developers will pick it up as a skill. In general, web designers/developers will become more accustomed to using frameworks and libraries, not just on the client-side either. YUI’s ‘market share’ will remain largely static. The status of the JavaScript framework ‘industry’ will remain largely oligopolistic although, as I’ve said, jQuery will definitely remain the most popular!

IE6 < 10%

Before the end of 2009 IE6 will probably fall below the 10% usage mark with the majority of it’s users adopting IE7, possibly IE8 later on in the year. More websites and web developers will stop supporting the browser completely. If things go to plan, I’ll probably drop support of IE6 around July although, to be honest, it probably won’t save us as much time as we think it will.

Smashing Magazine is probably the most popular web design blog of 2008, it has over 100,000 subscribers and publishes about 6/7 posts per week. I’m sure many web designers and developers think of it as the ‘goto’ resource for tips, tricks and advice but unfortunately it’s probably only a small handful of these people who are able to separate the good content from the not-so-good content. By "not-so-good" I either mean outdated or simple incorrect.

The purpose of this post is not only to weed out some of the not-so-good content but also to offer more modern solutions.

I want to have this post finished before lunch so I’ll only be covering a couple of the JavaScript follies of which there are quite a few:

POST: "jQuery and JavaScript Coding: Examples and Best Practices"

"This post was quite a good one actually, it covered many important features of the jQuery JavaScript library and touched on a few basic but essential good practices such as unobtrusive coding, degradability and accessibility." – this would’ve been my review if I was at least a tiny bit satisfied!

Rule #1 under the "Unobtrusive DOM scripting" section of this post dictates that you should separate JavaScript functionality. This is the central theme of unobtrusive coding – to make sure the content (HTML), the CSS (presentation) and the JavaScript (behaviour) are all separated and that the only line of dependency is backwards. By this I mean that the content should not depend on JavaScript and neither should the presentation but the JavaScript can depend on the content and the presentation. This SM article illustrated this practice with a code snippet:

BAD: <a onclick="doSomething()" href="#">Click!</a>  
GOOD: <a href="backuplink.html" class="doSomething">Click!</a>

The ‘good’ alternative may seem suitably unobtrusive at first but the chosen class name is definitely not! All elements should be named according to their content/meaning – giving an element a class of ‘doSomething’ is just as bad as giving it a class of ‘Button2pxBorderWhite’. HTML content should reside quite suitably on it’s own – when you add your JavaScript enhancements, ideally, you shouldn’t have to touch the HTML, even to add ‘hooks’. Fortunately the DOM API and the various JavaScript libraries available make DOM traversal incredibly simple, so adding ‘hooks’ (IDs/classes etc.) just for the benefit of the behavioural layer is not necessary and is somewhat obtrusive.

I was out today doing a little bit of Christmas shopping and decided to pickup the latest copy of the ‘net’ magazine. I like to see if they have anything good to say, usually I’ll find at least one pretty decent article which might offer up something innovative and interesting. This copy however was quite a disappointment… Have a look:

You might be thinking, "Wow, I ought to pick up a copy too!" – Well, don’t; there’s nothing interesting in there at all! In fact, just by the cover, this magazine could quite easily have been a copy from 12 months ago (apart from the ‘2009′ bit) and nothing inside the magazine is particularly thought provoking or innovative either. Just for this post’s sake we’re doing to ignore the ‘iPhone’ nonsense on the front-cover because I don’t see platform specific development as of a prime importance.