Did I add the kitchen sink to my style file? December 3rd, 2010

It sure feels that way.  Amazingly, a standard OpenLayers build weighs in excess of 900KB of minified JavaScript.  Granted, GZIP helps a bit, but that is a ton of stuff to ask a poor browser to interpret if you’re goal is just to display a basic map.  After a bit of poking, I found you can build a “lite” version that is only a few hundred KB and strips out most of the features.  And this is when I stopped looking.  Aside from a bloated codebase, it doesn’t really support mobile phones easily (as in limited touch support and extremely bad performance) which is kindof what I was looking to display a map on.

As I was assessing the landscape, I got this incredible sense of deja-vu.  You see, up until recently, I worked for MapQuest.  While there, I wrote a few mapping toolkits or rendering libraries and know a bit about what it takes to build one well.  The MapQuest JavaScript API, while not perfect and suffering from a host of legacy issues such as crazy projection and zoom levels, layers of backwards compatibility support and licensing restrictions, is actually a pretty compact and performant bit of JavaScript.  I rewrote it a couple of years ago when we launched our first mobile Safari website and was basically focused on limiting code size and maximizing performance.  At the time the entire mapping API was about the size of a tile to download.  It’s grown a bit since then but this is mainly through the addition of layer upon layer of legacy support and a number of bits needed to run MapQuest.com on the desktop.

With this experience in mind, I was upset to find that despite massive innovation over the past few years on the server side of open source geo, basically everyone is still focused on OpenLayers on the client side.  And OpenLayers is in desperate need of a reboot – which the dev team is doing as part of a 3.0 rebuild.  This is a great thing for anyone needing a full map-centric JavaScript map library, but it still leaves a niche for a super-lightweight, DOM-centric map library to fill in on the low end.

So you know where this is going… I started writing yet another JavaScript mapping library.  I want it to be small and fast for doing simple things (which in my experience comprises 90% of the use cases).  I’d also like it to work very closely with the DOM.  This isn’t 2005 when we were all trying to build crazy abstractions on top of the DOM to hide it.  I want to be able to have the library do enough to manage the coordinate system, tiles, etc and then just let me start attaching DOM content instead of working through layers of leaky abstractions.

It’s not all there in the head yet, but what I’ve got now will render standard web mercator tiles at arbitrary resolution, supports smoothly zooming between native resolutions of the tile server and supports attaching arbitrary DOM elements to the map by either adding a “positioning delegate” object (which is what complex elements like a Tile Layer use to draw themselves) or falling back to the default delegate which just assumes that the element has a geo property which contains a Lat/Lng and pixel offset and will take care of managing things from there.

So, very not done yet, but it weighs in at 7KB raw and 3KB gzipped.  I expect that to perhaps double by the time I get non-brain-damaged background tile invalidation and event handling in place.  I don’t really plan to add more than those basics.  The rest can be managed through normal DOM manipulations, of which there are a plethora of tools and approaches.

Here’s the GitHub repo: https://github.com/stellaeof/nanomaps

This entry was posted on Friday, December 3rd, 2010 at 8:52 pm and is filed under geeky, nanomaps. You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.

One Response

December 7th, 2010 at 5:25 pm
Stella Laurenzo » Blog Archive » Working Version of Nanomaps Says:

[...] my previous post, I discussed a little project I started to create a super-small, no frills JavaScript map display [...]

Leave a Reply