For the last several years, I’ve taken some time off around the end of the year to work on a special project. In 2004 I ported some of Rick Jelliffe’s code from Java to Python. In 2005, I made an editing pass over a novel I wrote the previous November during NaNoWriMo. This year was a little different. I:

Worked. Enough stuff is going on with the day job that I couldn’t take a full week off.

O’Reilly sent me a copy of the new 1000 page volume from David Flanagan. (Apparently, being an O’Reilly author gets you on their list for freebies.) A bunch of business ensued, and the book sat around unread for a while.

I’m not using JavaScript day-to-day anymore, but I used to during the Cardiff LiquidOffice days. I was responsible for an Ajax version of the forms engine (except nobody had thought to call it Ajax back then; the best we had was the clunky name ‘DHTML’). The 3rd edition of this book from 1998 was instrumental in my development as a JavaScript programmer. Because of that book, I stopped treating JavaScript like a scripting language, and started treating it like a programming language. I filled the margins with various notes.

When the 4th Ed. came out in 2002, I gladly picked up a copy. The most heavily-annotated section in my 3rd Ed. was gone! So over time, I kept coming back to the 3rd Ed. The new volume wasn’t enough of an improvement to overcome my intertia found scribbled in the margins.

The 5th Ed., I’m happy to say, is all I’ll be needing from here on. The language section is thoroughly updated, including contemporary coverage of closures and classes. The browser reference section is also massively improved and presented as a unified whole rather than fragmented sections. There’s a ton of new material, including all the XMLHttpRequest stuff that got me started, and about working with Flash.

Summary: this is a good one to have on your shelf, even if you have an earlier Edition. -m

Comments Off on Review: JavaScript: The Definitive Guide, 5th EditionPermalinkFiled under stuff

This “click-through” license on an Edison-style phonograph cylinder has been making the rounds. But don’t miss the front side: a giant photo of Edison himself, and his name in the largest font possible. As the photo caption says:

They really weren’t concerned with artist promotion, I guess.

From day one, the record companies have been more concerned about their own well-being than artists, it seems. -m

Last week, I visited Erik Wilde, Bob Glushko, and students up at Cal. No major announcements, just some sharpening of discussion points.

Since this was my first visit to Berkeley, I finally got to tell the joke “thank you for your OS”. Maybe you had to be there.

The intentional web is a formalism for describing “why the font tag is evil”. I often work with 3rd party integration languages, and the markup design is, without exception, crap. I hypothesize that the reason for this is jumping into solution-space before fully understanding problem-space. This seems to apply to lots more than just font tags; I lumped in WML and about half the world’s ajax sites for good measure.

Microformats are a formalism for describing “why creating a new markup language for my CD collection” is evil. Could XForms have been done as a microformat? No, microformats require a strong intentional foundation language, and HTML forms ain’t it. Is the proposed W3C approach an instance of “a deadly two-pronged attack”, a la Yahoo! Photos + Flickr? We’ll see. It does seem like that road leads to a namespace apocalypse, highlighting the fundamental difficulty namespaces hoists on attempts to usably extend HTML and XHTML at the same time. A namespace apocalypse may not be a bad thing.

On namespaces, I went over most of the points from my recent article. I won’t rehash that here.

What are some practical and implementation issues around XForms or the lack thereof? Focusing on mobile, as reason #1 I gave the lack of commercial-grade java browsers, discussed here previously. The state of mobile browsers is appalling, other than Opera and S60. Terms like “model” and “field” are troublesome, because the confuse the problem domain (the real world) and the solution domain (the computer). Browser vendors have been too inwardly-focused, both now and during the first attempt at salvaging HTML forms, leading to a premature jump into solution-space. But perhaps XForms dwelled for too long in the problem space…

Maybe I’ve mellowed some, but increasingly I’m able to look at both sides of issues. A useful skill for Information School students, wouldn’t you agree? -m