JavaScript meetup

Yesterday, as previously mentioned, lots of people met up to talk about JavaScript. I got to meet ppk and Dean Edwards for the first time, which was great. And we talked about things. The original idea was to talk about some fairly heavy technical stuff like what to do about the onload handler, but after Jeremy’s presentation at @media 2005 it became clear that we need less effort going into solving minor technical minutiae and lots more effort going into PR for JavaScript.

You see, developers out there seem to fall into the following categories:

  1. People who already know about the power of the DOM and unobtrusive scripting. A good proportion of whom were in the pub yesterday talking about this.
  2. People who have bought into web standards, are using tableless design with CSS, don’t really know about JavaScript, but want to know more. This is a large proportion, we think, of current CSS hackers.
  3. People who used JavaScript a while ago and have since dismissed it because it was a pointless language that let you do image rollovers and make websites that depended on it.
  4. People who haven’t bought into the web standards deal at all.

Clearly we can’t target everyone at once, and the consensus was that the people to target are category 2, experienced CSS hackers. The advantage here is that they are already using clean markup and modern techniques; since DOM scripting pretty much requires this approach, we don’t have to sell these people on the benefits of web standards, because they’re already doing it.

The major flaw, it seems, is that if you’re not a programmer then JavaScript is a bit difficult to get to grips with, and CSS designers are, in the main, not programmers. For people like me, it’s easy to gloss over the basics: what a variable is, what an array is, what an object is, what a function is. You see, all the power and elegance in JavaScript, the thing that makes it really great for putting together DOM applications, is that objects and functions and arrays are all the same thing. When you realise this then a whole vista of power opens before you; if you get this and how the DOM works then everything else that’s doable, all the cool scripts and techniques, becomes obvious. Pretty much, anyway.

So, what we need is things that explain how the basics work. The issue with that, though, which Dean Edwards pointed out, is that you’re not trying to teach people JavaScript, you’re trying to teach them programming. And that’s not all that easy. If you write a guide to what variables and functions and objects and arrays are then no-one will read it because that stuff is very, very, very boring. The approach we kicked around was to carry on writing demonstrations of cool techniques, but, when doing that, throw in a bit of a “basics” explanation on one point. So, next time you write a reusable library to make tooltips appear or something, in the explanation don’t just say “and we build a list of all the tooltips”: explain what a list is and how it works. Don’t try and explain everything from first principles, just one thing. And over time, people can pick up cool reusable techniques, which everyone likes, and learn about one important building block at the same time. Look for articles along these lines from various people.

The WaSP are also going to hopefully get on board; there were four WaSPs at the meeting, which helps (Chris Kaminski being one I hadn’t met before), and they have a lot of mindshare in the community, which should help.

The brave new future we’ve talked about is coming. It’s time to show everyone else how they can be part of it.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • (no mentions, yet.)