The HTML5 specification introduces the

The above quote is from the Audio Data API extension that joins a bunch of juicy developer work in Firefox 3.7.

Thomas Sturm has taken that API and created a spectrum visualization a kin to some of the great work by Scott Schiller (using Flash).

There is a new onaudiowritten attribute:

that lets you get access to info such as the spectrum:

Add to that the ability to write audio....

Nice work all around.

modulr is a CommonJS module implementation in Ruby for client-side JavaScript

Ruby? what does that have anything to do with it? Ah, its from one of those Prototype guys isn't it.... Yup, Tobie is at it again, this time with modulr:

modulr accepts a singular file as input (the program) on which is does static analysis to recursively resolve its dependencies.

The program, its dependencies and a small, namespaced JavaScript library are concatenated into a single js file.

The bundled JavaScript library provides each module with the necessary require function and exports and module free variables.

This can also help sharing that CommonJS code. I recently did just that and had some:

I just came across this wonderful Gist on gitHub:

In case you want to use YUI3 but really really like jQuery syntax :) OK, it breaks the whole sandboxing idea of YUI3, but that's a small price to pay, right?

Bass Schouten is a cool name, and the Mozillan has presented Direct2D hardware acceleration.

You have to grab Firefox nightly, do the about:config / gfx.font_rendering.directwrite.enabled game, but then you get to see it in action.

IE9 showed off how they will support hardware rendering, and I am sure we will see more at MIX, but it is very cool to see this across the board.

CSS Transforms/Transitions/Animations are going to feel like butter in 2010!

Works even in IE6

Love that quote from the color picker over at RaphaelJS land. This plugin by Dmitry Baranovskiy gives you an easy color picker in short order:

Andrew Hoyer shows his canvas Fu with Cloth, a great experiment using nice physics.

What makes this simulation special is the speed at which everything is computed. Javascript (the language this is written in) is not exactly the most efficient language for this type of computation. This being said, much time was spent squeezing out every little detail that slows things down.

The most computationally expensive part is trying to satisfy the constraints. To do this requires the calculation of distance between two points. This is easy to do with a little math, but that often involves an expensive square root. This is something that cannot simply be thrown out either, so what do you do? You approximate it. There are lots of mathematical tools for approximating functions, in this case I chose the first couple terms of a taylor expansion.

Check out his fast vector, constraints, and finally the cloth itself.

Marcus Westin has created a new templating language called fin. It is an interesting beast, and he gave us a run down:

Since this past November I've been working on a realtime templating system I call "fin". I'd love to get some eyes on it, and hope that you'll find it exciting. There is no demo, but quite a bit of information and if you're on OS X it's trivial to get the system set up on your own machine.

The basic idea is this... Rather than describing your data, you describe how you want your data to be viewed. Fin takes it from there in terms of persisting new data as it gets created. In addition, all views of any piece of data is globally synchronized. If one computer makes changes to a user's name for example, then those edits are reflected for anyone viewing that user's name as well, keystroke by keystroke. The way you create value views and input views goes like

PLAIN TEXT

HTML:

1.  
2. <div> User name: (( Value user.name )) </div><div> Edit user name: (( Input user.name )) </div>
3.  

More detailed examples can be found here.

You can also chain references to items, for example (( Value user.friend.name )). Now, if user.friend.name changes, then the Value view is instantly updated. Even cooler, if the user's friend reference changes to a new friend, then the value view will accurately reflect the new friend's name.

To get started on OS X 10.6 is as easy as

git clone git://github.com/marcuswestin/fin.git
cd fin
sudo make install-node
make deps
make run-couchdbx

And voila! Just navigate to localhost/path/to/fin/examples/from-html.html and you're good to go.

Would we all like Steve to sit down with us on our project and do a performance case study? Well, we may not get that, but we are getting to at least sit in on others.

Steve has kicked off his long awaited series that runs performance case studies on third party content. I have been talking to Steve about this for a couple of years, so it is great to see it. It is a sensitive topic as you never want to show up a team when you are just trying to help and educate.

First on the block? The Digg widget.

Steve goes into detail and finds a lot of short comings. You could probably guess some of the bad actors. Mr. document.write() appears for example. We get the problems, and proposed solutions to the issue. Steve also tries to note what a user of third party content can do regardless of if the third party guys fix their issues (put in iframe!).

Here are the most important performance issues along with recommended solutions.

1. 9 HTTP requests, 52 kB transferred over the wire, and 107 kB of JavaScript (uncompressed) is a lot of content for a single widget.

   Recommendations:

   • Concatenate these three scripts: JS_Libraries, widgetjsvars, and omnidiggthis. (eliminates 2 HTTP requests)
   • Run Page Speed’s “Defer loading JavaScript” feature and see how much of the JavaScript is not used. If it’s sizable, delete it. (This feature is currently broken in the latest version of Page Speed, but a fix is imminent.) (eliminates ?? kB)
   • Optimize the images – widget-logo.png and get-widget.png can both be reduced by ~3 kB. (eliminates ~6 kB)
   • Sprite widget-logo.png and shade-com.png. (eliminates 1 HTTP request)
2. The widget’s scripts block the main page’s content from downloading. Looking at the waterfall chart, the main page includes the image “digg-waterfall.png” (row 10). Notice how this image doesn’t start downloading until after all the scripts for the Digg widget are received.
   Recommendations:
   • Instead of loading the scripts using document.write, load them without blocking other downloads. The scripts are already suffering from race condition behavior, as evidenced by this comment from widgetjsvars:
     1: if (!digg || !digg.$) setTimeout(function() { diggwb(obj); }, 200); //hack for IE not loading scripts that are included via document.write until it decides too

   So it probably isn’t too much work to avoid race conditions when making all the scripts load asynchronously.

3. The widget’s stylesheet blocks the main page from rendering in IE.

   Recommendations:

   • Instead of loading the stylesheet using document.write, load it via JavaScript as described in 5d dynamic stylesheets.
4. Four of the resources aren’t cached long enough.
   Recommendations:
   • Two scripts aren’t cacheable because they have an expiration date in the past. widgetjs is part of the snippet, so it can’t have a long expiration date, but something like an hour or a day would be better than a date in the past. widgetjsvars could have a far future expiration date since its URL is specified in widgetjs.
   • The three images are only cacheable for a day. They should have a far future expires header since the image filename can be change if it’s modified.
5. There are approximately 30 inefficient CSS selectors. Because this stylesheet is part of the main page, the selectors will cause the overall page to render more slowly when these selectors are applied to the elements in the main page.
   Recommendations:
   • Reduce the performance impact by simplifying these CSS selectors.
6. Four of the resources have ETags which reduces their cacheability.

   Recommendations:

   • Configure the ETags for widget.css, widget-logo.png, get-widget.png, and shade-com.png.

This is just the first example. What else would you like to see Steve tackle?

David Anderson: "TraceMonkey has rocket boosters, so it runs really fast when the boosters are on, but the boosters can’t always be turned on."

Opera's new JIT compiler Carakan is doing well as we just posted. What is Mozilla doing with TraceMonkey? A lot.

Mozilla JägerMonkey adds method based JIT (of V8 and Nitro fame) to keep the boosters on.

We learn more from David Mandelin and David Anderson.

The Opera team has released 10.50 for Mac and along with it some impressive performance numbers:

• Stabilization Improvements: You will find that this build is much more stable than the pre-alpha build.
• More polished user interface: The whole UI is more polished now. We're still not done yet, and expect more polishes and improvements in the builds to come.
• Opera Unite: Opera Unite now works with this release. You can browse through and download unite apps through the Unite Apps Repository.
• HTML5 <video>: This beta now supports the html5 <video> tag.
• Widgets as standlone apps: We've already talked about widgets as standalone apps, but this functionality was till now, only available in windows builds. Now even in this build of 10.50 beta for mac, you can use widgets as standalone apps. Check out this ODIN post by Patrick Lauke on standalone widgets for more information.
• New Developer Tools Menu: You can go to 'View->Developer Tools' Menu to access common and usefull tools for developers, such as Opera Dragonfly, cache information, the error console, the source code of the page, and more.

Gregg Keizer talks about the performance side of things

According to tests run by Computerworld, Opera 10.5 was nearly 15% faster than Safari for Windows and almost 20% faster than Google's Chrome, the previous No. 1 and No. 2 browsers. Opera's preview was more than twice as fast as Mozilla's Firefox 3.6, over eight times faster than Opera 10.10, and 10 times faster than Microsoft's Internet Explorer 8 (IE8).

We tend to talk a lot about WebKit, Moz, and IE.... congrats to the Opera team on their impressive work.