Simon Willison's Weblog: libraries

Text a community college librarian

2025-12-04T23:52:21+00:00

I take tap dance evening classes at the College of San Mateo community college. A neat bonus of this is that I'm now officially a student of that college, which gives me access to their library... including the ability to send text messages to the librarians asking for help with research.

I recently wrote about Coutellerie Nontronnaise on my Niche Museums website, a historic knife manufactory in Nontron, France. They had a certificate on the wall claiming that they had previously held a Guinness World Record for the smallest folding knife, but I had been unable to track down any supporting evidence.

I posed this as a text message challenge to the librarians, and they tracked down the exact page from the 1989 "Le livre guinness des records" describing the record:

Le plus petit

Les établissements Nontronnaise ont réalisé un couteau de 10 mm de long, pour le Festival d’Aubigny, Vendée, qui s’est déroulé du 4 au 5 juillet 1987.

Thank you, Maria at the CSM library!

Tags: libraries, museums, research

AI-generated slop is already in your public library

2025-02-05T01:50:01+00:00

AI-generated slop is already in your public library

US libraries that use the Hoopla system to offer ebooks to their patrons sign agreements where they pay a license fee for anything selected by one of their members that's in the Hoopla catalog.

The Hoopla catalog is increasingly filling up with junk AI slop ebooks like "Fatty Liver Diet Cookbook: 2000 Days of Simple and Flavorful Recipes for a Revitalized Liver", which then cost libraries money if someone checks them out.

Apparently librarians already have a term for this kind of low-quality, low effort content that predates it being written by LLMs: vendor slurry.

Libraries stand against censorship, making this a difficult issue to address through removing those listings.

Sarah Lamdan, deputy director of the American Library Association says:

If library visitors choose to read AI eBooks, they should do so with the knowledge that the books are AI-generated.

Via Emily Bell

Tags: ethics, libraries, ai, slop, ai-ethics, ai-misuse

Introducing Closure Tools

2009-11-06T07:33:56+00:00

Introducing Closure Tools

Google have released the pure-JavaScript library, apparently used for Gmail, Google Docs and Google Maps. It comes with a powerful JavaScript optimiser tool with linting built in and an accompanying Firebug extension to ensure the obfuscated code it produces can still be debugged. There’s also a template system which precompiles down to JavaScript and can also be called from Java.

Tags: closure, firebug, gmail, google, google-docs, javascript, libraries

YUI 3.0.0: First GA Release of YUI's Next-Generation Codeline

2009-09-29T23:38:18+00:00

YUI 3.0.0: First GA Release of YUI's Next-Generation Codeline

YUI 3 has some very neat ideas—everything is dynamically loaded, so you start with a tiny bootstrap script and call YUI().use(’module-name’) to load just the code you need. Congratulations to the team.

Tags: javascript, libraries, yahoo, yui, yui3

John Resig on Glow

2009-07-08T19:24:19+00:00

John Resig on Glow

John criticises Glow for reinventing the wheel—BBC insiders respond in the comments below.

Tags: bbc, glow, javascript, john-resig, libraries

Quoting Dion Almaer

2008-05-27T17:58:18+00:00

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all!

— Dion Almaer

Tags: ajax, browsers, dion-almaer, google, libraries

Google AJAX Libraries API

2008-05-27T17:56:47+00:00

Google AJAX Libraries API

Google are hosting copies of jQuery, Prototype, mooTools and Dojo on their CDN, with a promise to permanently host different versions and an optional JavaScript API to dynamically load the most recent version of a library. I wish they’d stop capitalising Ajax though.

Via Ajaxian

Tags: ajax, cdn, dojo, google, jquery, libraries, mootools, prototype-js

Doctype: /trunk/goog

2008-05-14T21:12:07+00:00

Doctype: /trunk/goog

Google’s newly released JavaScript library (pure JavaScript, so more along the lines of YUI and jQuery than GWT). I haven’t found the documentation for it yet, but the code is extremely well commented. UPDATE: The documentation is spread throughout Doctype.

Tags: dojo, goog, google, googledoctype, gwt, javascript, jquery, libraries, yui

querySelector and querySelectorAll

2008-02-08T11:21:03+00:00

querySelector and querySelectorAll

WebKit now supports the W3C Selectors API. Expect the various JavaScript libraries to add this as an optimisation to achieve massive speedups (Prototype are already working on it).

Tags: javascript, libraries, prototype-js, queryselector, safari, selectors, w3c, webkit

Low Pro For jQuery?

2008-02-03T22:16:04+00:00

Low Pro For jQuery?

Dan Webb on why he prefers Prototype over jQuery: “The one big reason was that, while jQuery was super simple and concise when working on smaller projects, it offered no help in structuring larger applications”.

Tags: dan-webb, javascript, jquery, libraries, lowpro, prototype-js

jQuery 1.2.2: 2nd Birthday Present

2008-01-15T08:59:34+00:00

jQuery 1.2.2: 2nd Birthday Present

The API stays the same, but there are some healthy speed improvements, a new way of adding custom events and (most importantly) .ready() now waits for the CSS to be ready in addition to the DOM.

Tags: css, documentready, dom, javascript, jquery, libraries, ondomcontentloaded

YUI 2.4.0 released

2007-12-05T15:32:31+00:00

YUI 2.4.0 released

Lots of great new features, but the one I’m most excited about is Selector: YUI finally has a CSS query engine.

Tags: css, javascript, libraries, selector, yahoo, yui

dojo.NodeList API docs

2007-11-08T11:16:57+00:00

dojo.NodeList API docs

Support in Dojo for jQuery-style chaining operations.

Tags: chaining, dojo, javascript, jquery, libraries

Upgrading to Prototype 1.6: real world examples

2007-10-24T19:19:44+00:00

Upgrading to Prototype 1.6: real world examples

I still don’t find Prototype as intuitive as jQuery, but the API improvements between 1.5 and 1.6 are very impressive.

Tags: javascript, jquery, libraries, prototype-js, radiantcms

Protoscript

2007-09-07T22:55:26+00:00

Protoscript

JavaScript tool designed for easy prototyping of JS interactions; powered by YUI and jQuery.

Via Bill Scott

Tags: bill-scott, javascript, jquery, libraries, protoscript, prototyping, yui

Building a JavaScript Library

2007-08-24T16:02:59+00:00

Building a JavaScript Library

Slides from John Resig’s Google Tech Talk. Some great tips in here, including: make your APIs orthogonal, look for common patterns, keep things extensible and write the documentation yourself.

Tags: api-design, googletechtalk, javascript, john-resig, jquery, libraries, slideshare

jQuery for JavaScript programmers

2007-08-15T02:27:08+00:00

When jQuery came out back in January 2006, my first impression was that it was a cute hack. Basing everything around CSS selectors was a neat idea (see getElementsBySelector) but the chaining stuff looked like a bit of a gimmick and the library as a whole didn't look like it would cover all of the bases. I wrote jQuery off as a passing fad.

Over the past few months it's become clear to me exactly how wrong I was. jQuery is an exceptionally clever piece of engineering. It neatly encapsulates an extraordinary range of common functionality, and provides a clever plugin API for any functionality not included by default. It takes a core abstraction - that of a selection of DOM elements - and extracts as much mileage out of it as possible. Most importantly, it does so in a way that obeys best practices and plays well with other JavaScript code.

Most introductions to jQuery focus on designers and inexperienced developers. I'm going to try to explain why jQuery should be of interest to experienced programmers as well.

Namespacing

The key to writing good, reusable JavaScript is to zealously manage your namespace. JavaScript provides a single global namespace (the window object), and many programmers (and some libraries) add symbols to this with abandon. Global variables are evil! Smart developers minimise their number of global objects, using techniques like the module pattern.

jQuery introduces just one symbol to the global namespace: the jQuery function/object. Everything else is either a directy property of jQuery or a method of the object returned by calls to the jQuery function.

What about language enhancements? Most libraries provide some variation of map, filter and strip, functions that are sadly missing from the JavaScript engines that ship with most browsers. Some libraries directly extend JavaScript's built-in String and Array classes, but this can be a risky strategy. String.prototype and Array.prototype are themselves global namespaces, and adding properties to them brings the same risk of collisions as being careless with regular globals.

jQuery provides a number of language enhancement functions, but each one is made available as a property of the jQuery object: jQuery.each, jQuery.extend, jQuery.grep, jQuery.map, jQuery.merge and jQuery.trim. There's no chance of these colliding with someone else's code.

The infamous $ function

I wasn't being entirely truthful when I said that jQuery was the only global symbol introduced: the $ symbol is also set up as a shortcut for jQuery. Thankfully, this is done in a non-destructive way: if you need your old $ function back (if you are already using code based on Prototype, for example) you can call jQuery.noConflict() to revert to the old $ function.

If you want the convenience of the $ function for jQuery without colliding with some other use of the global $ function, the jQuery documentation suggests the following idiom:

(function($) {
    // Within this block, $ is a reference to jQuery
    // Neat, huh?
})(jQuery);

Attaching everything to the $ symbol was one of the things that made me initially dismiss jQuery as a gimmick. For some reason thinking of it in terms of the jQuery symbol makes everything seem a lot more sensible, even though I'm happy to use the $ shortcut in my own code.

Selecting some elements

Every jQuery operation starts with selecting one or more nodes from the DOM. jQuery's selection syntax (really a domain specific language) is an interesting hybrid of CSS 1, 2, bits of CSS 3, some XPath and a few custom extensions as well. I won't describe it in detail here, but here are some useful examples:

jQuery('div.panel'): All divs with class="panel"
jQuery('p#intro'): The paragraph with id="intro"
jQuery('div#content a:visible'): All visible links inside the div with id="content"
jQuery('input[@name=email]'): All input fields with name="email"
jQuery('table.orders tr:odd'): "odd" numbered rows in a table with class "orders"
jQuery('a[@href^="http://"]'): All external links (links that start with http://)
jQuery('p[a]'): All paragraphs that contain one or more links

Of particular interest from the above are :visible and :odd, which are jQuery specific extensions. Also note that the attribute selectors use an @ sign, in common with XPath rather than CSS 2.

The selection language is extremely rich, and is similar to regular expressions in that time taken to learn it will pay off many times over.

Doing stuff with them

The object returned by a jQuery selector call is an interesting beast. It represents a collection of DOM elements, and behaves a bit like an array - it has a length property, items can be accessed by index and (most importantly) Firebug treats it as an array when displaying it in the interactive console. This is a clever illusion; the collection is actually a jQuery object, incorporating a large number of methods which can be used to query, modify and extend the collection of selected elements.

There are three principle categories of jQuery methods: those that manipulate all of the matched elements, those that return a value from the first matched object, and those that modify the selection itself.

I won't list all of the methods (see visualjquery.com for that), but I'll illustrate with some examples. If you have Firebug you can try these out interactively: use this Insert jQuery bookmarklet first to load the jQuery library in to any page, then paste the code examples in to the Firebug console.

jQuery('div#primary').width(300);: Set the width of div id="primary" to 300 px.
jQuery('p').css('line-height', '1.8em');: Apply a line-height of 1.8em to all paragraphs.
jQuery('li:odd').css({color: 'white', backgroundColor: 'black'});: Apply two CSS rules to every other list item; note that the css() function can take an object instead of two strings.
jQuery('a[@href^="http://"]').addClass('external').attr('target', '_blank');: Add a class of "external" to all external links (those beginning with http://), then add target="_blank" for good measure. This makes use of chaining, described below.
jQuery('blockquote').each(function(el) { alert(jQuery(this).text()) });: Iterate over every blockquote on the page, and alert its textual content (excluding HTML tags).
jQuery('a').html('Click here!');: Replace all link text on the page with the insidious "Click here!".

Here are some examples of methods that read values from the first matched element:

var width = jQuery('div').width();: How wide is the first div on the page?
var src = jQuery('img').attr('src');: What's the src attribute of the first image on the page?
var color = jQuery('h1').css('color');: What colour is the first h1?

There's a pleasing symmetry at work here: the methods used to set attributes (when passed two arguments, or an object representing multiple settings) can instead be used to read values if called with only one argument. This symmetry is used throughout jQuery, making the API much easier to commit to memory.

Finally, there are methods that modify the set of selected elements itself. Many of these also provide simpler ways of traversing the DOM:

jQuery('div').not('[@id]'): Returns divs that do not have an id attribute.
jQuery('h2').parent(): Returns all elements that are direct parents of an h2.
jQuery('blockquote').children(): Returns all elements that are children of a blockquote.
jQuery('p').eq(4).next(): Find the fifth paragraph on the page, then find the next element (its direct sibling to the right).
jQuery('input:text:first').parents('form'): Find the form parent of the first input type="text" field on the page. The optional argument to parents() is another selector.

Chaining

The jQuery team frequently boast about jQuery's support of chaining, even to the point of declaring that "jQuery is designed to change the way that you write JavaScript" right on the front page. Personally I found this a big turn-off, so I'm happy to say that you can make good use of jQuery while avoiding lengthy chains of methods entirely.

That said, chaining can be used for some neat tricks. In addition to chaining a bunch of DOM manipulation methods together, you can use jQuery's end() method to push and pop a stack of the selected element contexts. This is a little hard to explain; essentially, every time you use a method that changes the selected set of elements (such as children() or filter()) you can later use end() to revert back to the previous selection. Jesse Skinner gives a neat example of this in action in his tutorial Simplify Ajax development with jQuery:

$('form#login')
    // hide all the labels inside the form with the 'optional' class
    .find('label.optional').hide().end()
    // add a red border to any password fields in the form
    .find('input:password').css('border', '1px solid red').end()
    // add a submit handler to the form
    .submit(function(){
        return confirm('Are you sure you want to submit?');
    });

That whole thing is essentially a one-liner. It selects a form, finds some elements within that form, applies changes to them, reverts the selection back to the original form and assigns a submit() handler to it.

It's a cute concept, but you don't have to use it if you don't want to. I'm quite happy splitting my code up with a few self-documenting variable names.

DOM manipulation

jQuery offers a few smart ways of making large scale manipulations to the DOM. The first is quite surprising: the jQuery function can take a snippet of HTML which it will turn in to a DOM element (it actually looks out for a string that starts with a less than sign):

var div = jQuery('<div>Some text</div>');

You can use chaining to add attributes to the div once it has been created:

var div = jQuery('<div>Some text</div>').addClass('inserted').attr('id', 'foo');

Now append it to the body tag:

div.appendTo(document.body)

Or prepend it to a known location using a selector:

div.prependTo('div#primary')

Handling events

All JavaScript libraries need an event handling utility and jQuery's is no exception. As with attr() and css(), the event methods serve dual purpose: call them with a function to assign an event handler; call them without to simulate that event being triggered:

jQuery('p').click(function() { jQuery(this).css('background-color', 'red'); });: Set up paragraphs so that when you click them they turn red.
jQuery('p:first').click(): Send a fake "click" to the first paragraph on the page.

Similar functions exist for the other browser events - mouseover, keyup and so on. Note that within an event handler the 'this' keyword is set to the element that triggered the event; using jQuery(this) is a common idiom to enable jQuery methods on that element.

A couple of event related functions deserve a special mention:

jQuery('a').hover(function() {
    jQuery(this).css('background-color', 'orange');
}, function() {
    jQuery(this).css('background-color', 'white');
});

hover() is a shortcut for setting up two functions that run onmouseover and onmouseout.

jQuery('p').one('click', function() { alert(jQuery(this).html()); });

one() sets up an event handler that will be removed after the first time it has been fired. The above example causes all paragraphs to alert their contents once the first time they are clicked.

jQuery also supports custom events, through the bind() and trigger() methods (for which click() and friends are just shortcuts). Custom events can take arguments, handled using an array passed to trigger():

jQuery(document).bind('stuffHappened', function(event, msg) {
    alert('stuff happened: ' + msg);
});
jQuery(document).trigger('stuffHappened', ['Hello!']);

Unobtrusive scripting

This is a topic that is very dear to me. I still believe that the best Web applications are the ones that are still usable with scripting turned off, and that the best way to achieve that is through unobtrusive scripting, with events being assigned to elements after the regular page has been loaded (see Unobtrusive Scripting and Hijax for more).

jQuery has excellent support for this. Firstly, the node selection metaphor is core to both jQuery and unobtrusive scripting as a whole. Secondly, jQuery ships with a solution to the window.onload problem based on Dean Edwards' work getting a "DOM loaded" event to work cross-browser. You can set a function up to run when the DOM is ready for it like so:

jQuery(document).ready(function() {
    alert('The DOM is ready!');
});

Even better, you can shortcut the above by passing your function directly to jQuery():

jQuery(function() {
    alert('The DOM is ready!');
});

jQuery and Ajax

jQuery has the best API for Ajax I've seen in any of the major libraries. The most simple form of an Ajax call looks like this:

jQuery('div#intro').load('/some/fragment.html');

This performs a GET request against /some/fragment.html and populates div#intro with the returned HTML fragment.

The first time I saw this, I was unimpressed. It's a neat shortcut, but what if you want to do something more advanced like display an Ajax loading indicator? jQuery exposes custom events (ajaxStart, ajaxComplete, ajaxError and more) for you to hook in this kind of code. It also offers a comprehensive low-level API for more complex Ajax interactions:

jQuery.get('/some/script.php', {'name': 'Simon'}, function(data) {
    alert('The server said: ' + data);
}); // GET against /some/script.php?name=Simon

jQuery.post('/some/script.php', {'name': 'Simon'}, function(data) {
    alert('The server said: ' + data);
}); // POST to /some/script.php

jQuery.getJSON('/some.json', function(json) {
    alert('JSON rocks: ' + json.foo + ' ' + json.bar);
}); // Retrieves and parses /some.json as JSON

jQuery.getScript('/script.js'); // GET and eval() /script.js

Plugins

Considering the amount of functionality you get out of the box, jQuery is actually pretty small - it comes in at 20KB when minified, even smaller when gzipped. Additional functionality outside the framework is handled using plugins, which can (and do) add brand new methods to the existing jQuery instance object. If you want to be able to run:

jQuery('p').bounceAroundTheScreenAndTurnGreen();

jQuery's plugin mechanism provides documented hooks for adding that method to the jQuery system. The ease with which these can be created has attracted an impressive community of plugin authors; the Plugin directory lists well over 100.

One really nice touch is that you can add custom selectors in a similar way to custom methods. The moreSelectors plugin adds things like "div:color(red)" to match divs with red text, for example.

Leaky abstractions

In my new-found respect for jQuery, I've been struggling with one philosophical blocker. For the past few years, I've been advising people to only pick a JavaScript library if they were willing to read the source code and figure out exactly how it works. My reasoning was based on Joel Spolsky's classic essay The Law of Leaky Abstractions, which points out that the more complexity your APIs are hiding, the more trouble you'll be in when some of that complexity leaks through. Browsers are the leakiest abstraction of them all, so being able to dig yourself out of a hole when the library fails to cover for you is of paramount importance.

jQuery uses some really arcane tricks to achieve its functionality - parts of it (like the selector code) are positively terrifying. If understanding exactly how the library works is necessary, jQuery must be a poor choice for the majority of developers. However, the enormous popularity of jQuery combined with a distinct lack of horror stories demonstrates that this is not the case.

I think I'm going to have to reconsider my advice. The way the library works isn't the issue: it's understanding the underlying issues, and knowing what kind of browser differences there are and what kind of techniques your library is using to fix them. No library can protect you 100% against weird browser behaviour, but as long as you have a grounding in the underlying theory you should be able to figure out if a problem stems from your own code, your library or the underlying implementation.

To conclude

I hope I've made the case that jQuery isn't just another library - there are enough interesting ideas in there to teach even the most hardened of JavaScript programmers some new tricks. Even if you don't intend on using it, it's still worth spending some time exploring the jQuery ecosystem.

Tags: javascript, jquery, libraries, plugins

Quoting Tom Occhino

2007-07-08T07:29:16+00:00

MooTools is not compatible with any other javascript framework. If you "definitely need to work with prototype" (which you don't, since the frameworks each provide all the functionality you need to use only one or the other) then learn how to do what you want to do in prototype. Otherwise, learn to use MooTools to do all the things you want to do. They simply do not work together, and I promise they never will.

— Tom Occhino

Tags: javascript, libraries, mootools, prototype-js

Dojo 0.9 Update

2007-04-29T20:18:13+00:00

Dojo 0.9 Update

Big changes are under way in the Dojo camp.

Tags: alex-russell, dojo, javascript, libraries

Quoting Paul Graham

2007-04-07T08:22:55+00:00

Microsoft saw the danger of Javascript and tried to keep it broken for as long as they could. But eventually the open source world won, by producing Javascript libraries that grew over the brokenness of Explorer the way a tree grows over barbed wire.

— Paul Graham

Tags: javascript, libraries, microsoft, paul-graham

base2

2007-03-23T17:59:34+00:00

base2

Dean Edwards’ new JavaScript library which adds useful cross-browser features based on upcoming DOM standards (the Selectors API, DOMContentLoaded, addEventListener and more).

Tags: addeventlistener, base2, dean-edwards, domcontentloaded, javascript, libraries, selectors

Rules For JavaScript Library Authors

2007-03-23T17:53:11+00:00

Rules For JavaScript Library Authors

The guiding principles behind Dean Edwards’ base2 library, entirely applicable to every JavaScript developer.

Tags: base2, dean-edwards, javascript, libraries

Notes on JavaScript Libraries

2006-06-26T15:03:00+00:00

@media 2006 was a blast. Great talks, great people and some of the highest production values I've ever seen at a conference (check out the bags!).

I sat on the JavaScript Libraries: Friend or Foe? panel, with PPK, Dan Webb, Stuart Langridge and Cameron Adams chairing. It was my first participation in a panel and I really enjoyed it - I've always liked the Q&A bit of giving talks. JavaScript Libraries are an enormous topic but I felt we did them justice considering the time available. For the record, here are the key points that I wanted to get across:

Large JavaScript applications need some kind of library - even if it's one built especially for that application. There are a number of problems in JavaScript (most of them originating with browser incompatibilities) that any moderately complex application will need to deal with - things like normalised event handling, DOM node selection, sane animation or drag and drop. Solve these problems once so you can get on to the interesting task of building the application. If you can find a library that solves them for you so much the better!
The big four. Dojo, MochiKit, Prototype/Scriptaculous and the Yahoo! UI Library are the top of the pile as far as I'm concerned. They cover the bases effectively and each one offers something interesting that makes it worth studying in its own right. If you plan to evaluate some existing libraries these make an excellent starting point.
Leaky abstractions. Joel Spolsky's essay The Law of Leaky Abstractions is my favourite of all of his online articles. It's basic tenet is that abstractions that are designed to save the programmer time inevitably leak, and if they leak at a lower level of abstraction than the programmer is familiar with they prove almost impossible to debug. Paradoxically, the more time saving abstractions you are using the more you actually have to know.

JavaScript is possibly the leakiest abstraction of them all, thanks to the many different browser environments it runs in. If you rely on a library to abstract away the browser bugs from you you are certain to run in to a bug that you can't fix sooner or later. Don't use libraries as crutches; if you're not prepared to figure out what the library is doing for you you'll end up in a world of pain further down the line.
Community and documentation matter. As with all open-source software, it's a good idea to get a feel for the amount of community activity around a project before you commit to building on it. The big four all have active communities, which means less bugs, more support and a faster rate of improvement. Likewise, good documentation is invaluable.
Libraries should play well with others. Reusable code that excludes other code from being reused has severely limited long-term value. In JavaScript, that means that libraries that mess with Object.prototype or pollute global namespaces should be treated with caution. The Prototype library was a major culprit here, but thankfully has cleaned up its act (at least with regards to altering Object.prototype) in recent releases. It's all very well saying that you'll always be using code built with your core language modifications in mind, but you may well change your tune when you try to incorporate Yahoo! or Google Maps and everything breaks.
Go with the grain. If you take the time to learn it properly, JavaScript is a powerful and surprisingly elegant language. Good JavaScript code takes advantage of its dynamic, functional nature. Libraries that promise to take the pain out of JavaScript by writing the code for you probably aren't as smart as they seem. Abstractions leak.

Dan Webb has a good comparison of the big four on SitePoint, although he did overlook YUI's Animation library which I consider a highlight.

For more accurate coverage of the @media panel itself, take a look at my co-worker Paul Hammond's detailed notes.

Tags: atmedia, dojo, javascript, libraries, mochikit, prototype-js, speaking, my-talks, yui