I thought I was being clever with my DimensionalMap subproject:  bootstrapping on top of the Map object to build a multi-dimensional hashtable.  Then I started using it heavily in my Verbosio Templates subproject to implement a very customized Document Object Model in JavaScript.  With over 900 Jasmine tests passing, execution time was averaging about 4 seconds.

However, I suspected my use of DimensionalMap was unnecessary – particularly since I was working with only one dimension at the time.  So in a quick experiment, I replaced the code that used it with code using WeakMap.  Total execution time with the same tests:  about 1.5 seconds.

Ouch.  I still think the API is a good one, but clearly the implementation has issues.

Hey, kids!  Wanna build your JavaScript profiling skills?  Help me find the spots that are causing unnecessary slowness!  I’ll be happy to write a letter of appreciation for anyone who wants to take it on.  As always, the code is available under Mozilla Public License 2.0, GPL 3 and LGPL 3.  (Childhood not required for participation.)

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

This cannot possibly be good for our developer community.  Think about it:  Visual Studio has a much more developer-friendly C++ debugger than GDB on Linux – that’s why when I’m writing C++ code, I prefer to do it in Windows.  Certainly it means many of us will be stuck on VS 2010, and Mozilla will have to support code written for before the C++11 standard for quite a while.

It wasn’t that long ago that I implemented timeouts for XMLHttpRequest.  If I’d had to make do with the VS2011 Express compiler… I’d be on Linux.

Pay-to-play sucks when it’s pay-to-make-the-Internet-better.

I decided I had to write my own Document Object Model implementation because the models available to me just won’t meet my requirements.  That involves writing a lot of code, though, and ensuring that Element nodes, Text nodes, etc. all implement Node properties like firstChild, childNodes, etc., and methods like appendChild() correctly.

To lend a hand, I wrote a little InterfaceChecker library for ensuring that tests on a base class are run on derived classes.  (I know, JavaScript uses prototypes instead of proper classes; I’m using the concept’s meaning here.)  In principle, I need to only do three things:

• Write tests for the Node interface’s methods and properties
• Designate Element as inheriting from Node, and
• Provide some functions to build “typical” instances of Element,

My InterfaceChecker will run the Node tests against the “typical” instances of Element, for example.  It’s not DOM-specific, either:  I can do the same to arbitrary JavaScript constructors, like a theoretical Shape and Circle pairing.

This code is for debugging purposes only; in my opinion, it’s a little extreme to include these tests in a production environment.

Please, let me know what you think!

Over the last few years, there’s been a big movement on making Mozilla code really, really fast.  Which is wonderful.  A fair bit of this has been in “quick stubs” – specifically, optimizing how JavaScript (aka JS) code calls into C++ code.  For instance, the HTML input element has a quick stub for the value property, bypassing much of the XPConnect gobbledygook.

This post is about the reverse:  frequent calls from C++ code to JS code.  Calls like that don’t have the direct path.  They go through XPConnect.  This is understandable – JS code can do pretty much anything under the sun.  Plus, there aren’t many areas where C++ calls on JS.  The most notable spot is DOM event listeners, but again, they can do anything.

On the other hand, there are specific interfaces where the JS author is supposed to do only very simple things – or where the first few actions taken are validation (“does this event have a keyCode I care about?”).  The NodeFilter interface from DOM Traversal comes to mind.  It’s supposed to check a node’s properties and return a simple value.  A NodeFilter you pass into a TreeWalker or NodeIterator will be called for any node of the specified node types.

This is the kind of thing I look at and think, “Why don’t we get XPConnect out of the way, by having native code do the repetitive work?”  JavaScript is a glue language, where you can connect components together.  So we could use JavaScript to assemble a C++-based NodeFilter, which then gets passed into the native TreeWalker.  The purpose of this “intermediate filter” is simply to call on the JS code less frequently.

Now, I admit, node filters aren’t the most compelling case for pre-assembly.  (I have my reasons for wanting that, but they’re not common cases on the Web, I suspect.)  An event listener, though, would be more compelling.  I’d wager a native ProgressEvent listener, filtering on the readyState property before possibly executing a script-based callback, would be nice.  So would a native keypress event listener, based on keystrokes to a form control.

There’s even a bit of precedent in the Mozilla Firefox code:  the “browser status filter”.  I admit this poorly-documented web progress listener has caused me pain in the past, as it filters quite a lot… but that’s the point:  it hides a lot of unnecessary cruft from JavaScript code that frankly doesn’t care!  I also think JavaScript typed arrays are a point of comparison.

I think a few intermediate filter classes like this could have a measurable impact (ok, maybe small) on frequent calls from C++ to JS.  I don’t know if they would… but I think in the right places they could.  The major downside I can see is to readability of the code.

Opinions welcome!

I’m still working on my prototype XML editor, Verbosio, through yet another infrastructure project.  This time, it’s through a “multi-dimensional hashtable” concept, bootstrapped from ECMAScript Harmony WeakMap objects.  You can read about my “DimensionalMap” concept and plan here.  That’s not why I’m writing, though.

When I’m working on a typical project, I’m usually alternating between three windows:

• the browser
• the editor
• a shell or command prompt

That’s a little painful.  For DimensionalMap, I’m deliberately keeping the various components in different files, and assembling them together via a Makefile.  This gave me an idea:  what if a special URL could re-run make and force these files to rebuild?

First, the Makefile, which launches Firefox (given a path to the browser) with a custom profile.  Second, a custom protocol handler which I call “jasmine:”, after the very nice Jasmine test harness, which DimensionalMap uses.  This protocol handler’s sole purpose is to call make build before loading the Jasmine test page.

Effectively, that reduces me to two windows to work with:

• the browser
• the editor
• a shell or command prompt

It makes a difference.  Now, if I knew how to incorporate Komodo Edit or Bespin/Ace/Cloud9 as a local file editor extension into the custom profile, it’d be down to one window.  That would be very, very nice indeed.

DimensionalMap is under MPL/LGPL/GPL tri-license.  Comments, reviews and patches are quite welcome.

I’ve stated before that I work with Mozilla code on three different operating systems.  My desktop supports Fedora Core 15 and Windows 7.  My MacBook runs MacOS 10.6.  These three give me coverage on all three platforms.

That said, I realized a few minutes ago each system serves a different purpose for me:

• With Fedora, I get fast compile times, especially incremental builds, and fast test execution.
• With Windows, I get a really good free debugger with Visual Studio Express.
• With Mac, I get portability:  I can write my code on the go.

It’s actually a pretty good situation, I think.  Is anyone else in a similar situation?

Many years ago, the Mozilla Application Suite implemented support for a jar: protocol.  This protocol states you can refer to ZIP-compressed files inside an archive served as application/jar-archive or application/x-jar.  A typical URL would look like jar:https://alexvincent.us/somepath/target.jar!/test.html.  The idea is that you download one file, target.jar in this case, and your browser extracts the rest of your files from that URL.

Today, Mozilla Firefox uses it as part of how they store their user interface (omni.jar these days) on the local file system.

It’s a pretty interesting concept.  There’s been a large push in recent years towards JavaScript minification, to reduce download sizes.  This is especially true as scripts have recently ballooned to hundreds of kilobytes.  If you have a lot of JS, HTML, CSS, XML, and other plain-text files that rarely change, it might be worth putting them into a single JAR for users to fetch – you get additional compression on top of your minification, and there’s one HTTP request instead of several.

With one major catch, though.

As far as I can tell, Mozilla Firefox is the only major browser to support the jar: protocol.  This is not news.  Even Google Chrome has not implemented support for the jar: protocol.

Naturally, Firefox’s history hasn’t been perfect with the jar: protocol.  They did fix the one issue I found publicly available about it, and wrote about it on MDN. I’m not aware of any other issues, so theoretically they should be safe to use.

I’m thinking about using this capability on my website.  For my “Visualizing the DOM” series I’m developing, I have a lot of JS files that I’m using, including some library files.  Ogg Vorbis doesn’t compress so well (on a 9 minute audio I received a 1% benefit), so I won’t include that.  Alas, if I lock out all the major browsers except Firefox, I’m not going to be too happy.  The good news is that the HTML file which loads my “theater” application is PHP-generated – so based on the user agent, I can probably send the user a JAR archive (to Firefox users) or the uncompressed files directly.

Comments welcome!  Particularly if you think this is a good or a bad idea.