Image: Penn Provenance Project/Flickr

Some sites no doubt generate their TOCs by hand, or assemble them server-side somewhere in the CMS, but building a table of contents doesn’t need to be complex or low level. In fact, so long as your HTML is well structured, you can easily generate a table of contents on the fly, using JavaScript.

Chris Coyier, of CSS-Tricks fame, recently posted a nice tutorial walking you through the process of creating a table of contents like the one used on Coyier’s CodePen site. The tutorial uses jQuery, but, with a little tinkering, you should be able to adapt the code to work with your favorite JavaScript library (or no library at all).

Here’s Coyier’s take on the benefits of using a dynamically generated table of contents:

1. It’s easier – write the JavaScript once and it can create the table of contents on every page you need it.
2. It’s more reliable – the JavaScript isn’t subject to authoring errors.
3. It’s still accessible – A table of contents is good for the general concept of accessibility, but it is a bonus (not having it doesn’t ruin the page) and nearly all screen readers run JavaScript.

For all the code, and a detailed explanation of what’s going on, head on over to CSS-Tricks.

Amiga pinball wizard.

To view the emulator, which was written by developer Rupert Hausberger, you’ll need a browser with support for WebGL and WebAudio, as well as a few other HTML5 APIs. I tested the emulator in the latest version of both Chrome and Firefox and it worked just fine.

If you’d like to see the code behind the Scripted Amiga Emulator, head on over to GitHub.

Happy Friday afternoon time wasting.

JSTerm, an experimental Firefox add-on for JavaScript developers, has hit version 2.0.

The JSTerm Firefox add-on — not to be confused with the HTML5 Telnet Emulator by the same name — adds a “jsterm” button to Firefox’s Developer Toolbar. Click the button and you’ll get a JavaScript terminal for live coding, prototyping and quick JavaScript experiments. JSTerm behaves like a typical shell terminal with history, tab completion and plenty of key bindings.

Version 2.0 offers performance improvements, a new option to undock the terminal into its own window, global history shared across sessions and support for OS X’s fullscreen mode.

To try out JSTerm you’ll need Firefox 16 (currently in the Beta channel) since JSTerm uses the new Graphical Command Line Interface we covered in our Firefox 16 beta review. JSTerm also takes advantage of the built-in Firefox Source Editor to highlight JavaScript and a sandbox to eval JavaScript.

If you’re thinking there are already several tools for Firefox that cover this ground, well, you’re right. The built-in Scratchpad and WebConsole both offer similar tools, though neither is quite as nice for quick prototyping and experimenting. Developer favorite Firebug also has a Console for JavaScript developers, but it lacks the nice syntax highlighting you’ll find in JSTerm.

For more details on JSTerm and a changelog of everything that’s new in this release, check out Mozilla developer Paul Rouget’s blog. To have a look at the code behind JSTerm, head to GitHub.

Is your browser running on high octane? Image: Barbara L. Hanson/Flickr

The Google Chrome team has added a new set of JavaScript benchmarks to the web, dubbed “Octane“. Octane joins the ranks of other test suites like WebKit’s SunSpider test and Mozilla’s Kraken.

Google’s Stefano Cazzulani, Chrome Product Manager, writes on the Chromium blog that, despite a plethora of benchmarks on the web, Google wanted a new suite with “new benchmarks created from full, unaltered, well-known web applications and libraries.” The result, says the company, is a test suite that better reflects performance in “real web applications.”

Of course what constitutes “well-known web applications and libraries” is left to Google’s Chrome team to decide, and, perhaps not coincidentally, Chrome scores quite well on Octane’s hand-picked suite. That’s not to say that Chrome isn’t actually quite fast, but it does highlight the main problem with browser-maker benchmarks — the browser vendor creating them almost always seems to score the highest on them.

I ran the latest version of each of the major web browsers through Octane on a 2008 MacBook Pro (average of five runs each):

• Safari 6: 6007
• Chrome 21: 8517
• Firefox 14: 5351
• Opera 12: 3330
• Internet Explorer 9: (tested in VMWare, but IE9 didn’t render the page.)
• Mobile Safari (iPad 3): 553 (incomplete test, typed arrays aren’t supported in Mobile Safari).

Naturally the results will vary depending on your hardware, particularly your graphics card, but in all my tests Chrome won by a large margin.

To see the actual tests — which include a 2D physics engine, a 3D rendering engine culled from translated C++ along wit PDF.js and other libraries — head on over to Google Code where you’ll find the source for the entire suite. Also be sure to read through the FAQ for more info about the thinking behind Octane.

Papa don’t code. Image: Wikimedia.

It’s unlikely Ernest Hemingway would have thought much of programming. Staring at a screen all day hammering out Perl doesn’t seem like something Papa would have enjoyed. A typewriter in the Cuban sun was more Hemingway’s bag.

But what would it have looked like if Hemingway had cracked open Vim and written a few web apps? Angus Croll, an engineer at Twitter, has one answer in a great post that looks at how some famous writers might have written code. Here’s Croll’s take on how Hemingway might have written JavaScript:

Code reduced to its essentials with no word or variable wasted. It’s not fancy; maybe it’s even a little pedantic — but that’s the beauty of Hemingway’s writing. No need for elaborate logic or clever variable names. It’s plain and it’s clear and it does what it has to — and nothing more.

The whole post is funny and well worth a read, particularly if you happen to have come to programming from a background in liberal arts. Other authors Croll covers include Shakespeare, Dickens, Bolaño and my personal favorite, surrealist Andre Breton. Also be sure to check out Croll’s JavaScript blog.

Wired.com Font Bombed. Image: Screenshot/Webmonkey.

We’ve already showed you how to turn any webpage into a game of Asteroids; now you can add Font Bomb to the list of ways to destroy text of the web.

Font Bomb is a fun little JavaScript bookmarklet you can use to plant bombs all around a webpage. Just drag the bookmarklet to your bookmarks bar and then head to a page you want to destroy. Click the bookmarklet and then start clicking anywhere on the page to plant bombs.

Then, thanks to a little magic from CSS 2D Transforms, the text starts flying — perfect for a little Friday afternoon amusement. (It’s also not a half-bad way to take out some frustration on trolls: Don’t feed them, just blow up what they wrote and move on.)

Font Bomb was created by Philippe-Antoine Lehoux. The code is available on GitHub (CoffeeScript) and there’s some discussion on Hacker News if you’d like to know more.

Lake.js: It's lakes all the way down. Image: Lake.js

Sometimes it’s easy to forget how far the web has come in the last decade, which is why we like the otherwise somewhat useless Lake.js. Lake.js is a JQuery plugin that creates a shimmering reflection of an image, an effect that dates from the days of Geocities — back when the web was nothing but one pixel gifs and under construction banners.

The appeal of Lake.js isn’t just about nostalgia though, it’s also a nice reminder that the web no longer needs to rely on terrible Java applets (the main source of cheesy lake reflections in the early days), or any other proprietary technologies to build shimmering lake effects. Today web standards like HTML, CSS and JavaScript can pull off not just lakes made of <canvas>, but things that were, until very recently, almost inconceivable.

Sure some of the web’s most common tools might still be hacks (CSS floats anyone?), but at least when we want cheesy rippling water we don’t have to download a 120 MB “applet” anymore.

Also, the first person to port Lake.js to pure CSS… please e-mail us when you’re done.

Google has released an experimental version of the Chromium web browser with support for the company’s new Dart programming language. Dart, which is Google’s attempt to improve on JavaScript, has thus far not enjoyed much support outside of Google, but the company continues to push forward with its own efforts.

The new development preview version of the Chromium browser, the open source version of Google’s Chrome browser, contains the Dart Virtual Machine. This release, which Google is calling “Dartium,” can be downloaded from the Dart language website. At the moment it’s available only for Mac OS X and Linux. Google says a Windows version is “coming soon.” Keep in mind that this is a preview release and intended for developer testing, not everyday use.

Google originally created Dart to address the shortcomings of JavaScript and ostensibly speed up the development of complex, large-scale web applications.

While there is much programmers might like about Dart, it is, like Microsoft’s VBScript before it, a nonstandard language from a single vendor created without any regard for the existing web standards process. The new Dartium release is the first browser to include a Dart Virtual Machine and, based on the response from other browser makers to the initial release of Dart, likely the only browser that will ever ship with a Dart VM. For its part Google says it plans to incorporate the experimental Dart VM into Chrome proper in the future.

The company also has a plan for all those browsers that aren’t jumping on the Dart bandwagon — a compiler that translates Dart to good old JavaScript. In this scenario Dart ends up somewhat like CoffeeScript, a JavaScript abstraction that makes more sense to some programmers.

For more details on the new Dartium browser and the latest improvements to the Dart VM, be sure to check out the Google Code Blog announcement.

It may have started as a lark, but the annual JS1K contest has long since ceased to be a joke. This year’s contest is already in full swing and notable for a spectacular 3-D drawing of a rose rendered using less than 1,024 bytes of JavaScript.

The JS1K contest seeks the web’s best JavaScript creations, with one small catch — the code used must be less than 1k. It might sound insane considering that some JavaScript frameworks — just the frameworks! — are over 100k, but since it began several years ago, JS1K’s experiments have never failed to impress.

One of this year’s most jaw-dropping efforts to date is developer Román Cortés 3-D rendering of a rose. Relying on Monte Carlo methods to keep the code size down, Cortés’ code draws a very nicely shaded 3-D rose for the love-themed 2012 edition of JS1K. You can check out the live demo on the JS1K website.

One word of warning: Part of what makes Cortés’ rose so small is that much of the heavy lifting is handed off to the processor. The demo code brought my CPU use over 100 percent and kept it pegged there the entire time it was open in Safari. Firefox and Chrome both managed to keep the number down to roughly 93 percent, but suffice it to say that a procedurally generated 3-D rose will tax your CPU.

To see how Cortés created the code behind the rose, be sure to visit his blog which offers a very thorough tutorial explaining how and why the code works. There’s also a great write-up on Cortés’ previous JS1K effort, a 3-D Christmas tree. Also be sure to check out the other submissions to this year’s JS1K contest on the JS1K website.

If you’ve got some impressive but terribly small bit of JavaScript code up your sleeve, fear not; the JS1K contest will continue accepting submissions through Wednesday, March 14, 2012. Details on the rules and submission process can be found on the JS1K website.