Adopt a general-purpose library for DOM, etc tasks

[tmcw]

There are several parts of modest-maps that are reimplementing parts of jQuery, Ender, etc, and a majority of users are already using one of these libraries. Thus, it might constitute a decrease in overall file size and reduce the energy needed on generic DOM tasks, browser-equality, etc., to start using a library for these parts.

The two options that most readily come to mind are jQuery and Ender. Since there's a lot of crossover between the two APIs, trying out one and switching to the other might not be too costly. jQuery certainly has a lot more adoption off the bat.

[RandomEtc]

If you don't mind me asking: is this a request or a proposal?

I'm extremely reluctant to fully require jQuery but I see how it could help foster adoption (and familiarity) and more contributions to the core library. I'm inclined to say it should never happen to modestmaps-js, but at the same time I'd be very supportive of a modestmaps-jquery fork. That's me personally but I suspect @migurski agrees (we're the two people most likely to be working on the project at the moment).

One option would be to start writing extensions (e.g. interaction handlers, pop-up info-bubbles, map controls, etc) that use jQuery. If those start to seem essential then it would be more compelling to bring jquery into the core library.

In all this discussion it's worth remembering that Modest Maps as it stands is <7KB when gzip compressed and minified. And that's using YUICompressor which is not as effective as UglifyJS or Closure Compiler. So size might be a bad motivation... :)

Ender is more intriguing to me because of the modular component parts. As mentioned on another issue I can see a strong case for replacing Modest Maps' own addEvent/removeEvent/cancelEvent utilities (and the image onload/onerror handlers) and the CallbackManager class (for addCallback, removeCallback etc) with https://github.com/fat/bean - if it doesn't increase file size and doesn't introduce issues with older browsers then I don't think it would be controversial. For those already using Ender or Bean it could be left out of the core build but it could be bundled by default.

[tmcw]

Cool - I'll add more later, but just to clarify - totally a loose proposal, just a more appropriate place to talk about this than the double/single click issue. If something like this is viable, I could certainly get time to work on it.

[RandomEtc]

Thanks for the clarification. Several people have talked to me about adopting Modest Maps more formally so I'd like to help that happen. And, as it's no longer core to my daily work, I should probably find a way to gracefully retire from maintaining it. The few issues that I filed in the last few weeks are the things people ask for most often that seem in keeping with the general Modest Maps philosophy... I'd like to see those through, perhaps in a single sprint/hack-day with other like-minded folks, and then perhaps revisit this thread and see where Ender is at. I'm certainly impressed by their philosophy and can see myself reaching for it before jQuery in future.

[tmcw]

Got it - totally understand that there's not much bandwidth to work on this right now. Looks like you're going into Cinder stuff, which looks... insanely cool. I & other devseed can pick up some tasks if needed, since Modest Maps is filling this not-OpenLayers-but-compatible-with-IE hole that unfortunately Polymaps can't do. It's been really awesome so far, and I've been working on some generic extensions for our stuff. (there are also solid plans to switch TileMill/Stream onto it soon).

[migurski]

Just to throw in my two cents: there's a big assumption in what you're saying, that the majority of users are using jQuery or Ender. Since I'm not one of those users (unless I can't avoid it) I'm really going to be more interested in a rationale that's a bit less of a slippery-slope. =)

Tom explained a bunch of this to me recently, and my understanding from him has been that the real reason to use something like jQuery inside the library is to hide DOM code that's perceived as ugly and therefore an impediment to participation from jQuery fans. Does this sound accurate? Is it enough to replace the parts that do DOM traversal with jQuery? Must all the goofier UI bits of jQuery ride along?

[tmcw]

@migurski - you're right - I still think it's a majority, but it's not 100%. Some of the more interesting users might not be using jQuery and might be using something else, and to force them to use it is rough.

I think that Ender - or just requiring 'something that looks like $ and has some methods' could alleviate the concern that you're dragging along the admittedly bloated capabilities of jQuery?

[RandomEtc]

Goofier UI bits of jQuery definitely do not have to ride along. That's also a slippery slope argument ;)

For me this would be all about cleaning up the (event and DOM handling) internals of Modest Maps with something that is more robust and feature complete like Bean or jQuery. UI stuff is something we don't currently have any of, and it remains to be seen whether jQuery would be of assistance there.

[migurski]

Yeah, not complaining that all those bits have to come-with, more like asking whether they do because I don't actually know! Can we do things like conditional loads, pulling in the selector parts of one of these libraries if they're not already detected as loaded from the beginning? I've used jQuery but I'm not at all familiar with Ender: do they have analogous interfaces for doing traversal? $('div#foo') vs. £('div#foo') or something?

[RandomEtc]

jQuery is a single library that can't be split apart (apart from the selector engine). However, jQuery UI is a separate, optional library and not part of the core jQuery download.

Ender is a blend of several tiny libraries. The whole point is that it can be split apart. DOM selection and events could be used without animation, for example. Ender doesn't do UI.

Both jQuery and Ender provide selector libraries that can grab DOM elements with CSS-like selectors.

[RandomEtc]

Food for thought: http://www.slideshare.net/rmurphey/the-jquery-divide-5287573 (especially slides 45-47)

More at http://blog.rebeccamurphey.com/modern-javascript and http://www.dagolden.com/index.php/1446/is-javascript-the-new-perl/

And also http://tomdale.net/2011/04/imagine-a-beowulf-cluster-of-javascript-frameworks/ and http://mir.aculo.us/2011/04/11/i-for-one-welcome-our-new-micro-framework-overlords/

I know where I stand on this subject (small libraries please; the browser is the framework already) but Rebecca's presentation in particular is food for thought. There are thousands of examples of jQuery and Google Maps integration. Who are we catering to if we adopt another library/framework here instead of holding our ground and keeping Modest Maps minimal?

Other things to compare are http://leaflet.cloudmade.com/ http://www.tile5.org/ https://github.com/aseemk/seadragon-ajax (non-Free) and of course http://polymaps.org/ ... which evolutionary niche is MM supposed to occupy? :)

Just throwing stuff out there...

[migurski]

Thanks Tom - digesting

I'm glad to know that jQuery has a core separate from the UI components, that's definitely a big plus.

[migurski]

Wow, Rebecca Murphey is my new hero for putting into words what I've always felt about omnibus libraries but could never quite articulate. Tom Dale's piece, maybe not so much: I suppose I agree with him that re-inventing the wheel is not the best thing for JS developers to be doing, but if there's one thing a summer with Mike B has taught me it's that this particular world is still in heavy flux, and that maybe trying to figure out how to propagate ajax changes to the DOM (his example) really is where energy needs to be spent.

Anyway, Tom and I just had a chat about the various changes to the library that we've all been discussing. Personally I'm motivated and excited about the idea that we ditch things like prototype in the library, but I'm more motivated by the idea that the library as a whole move forward with a well-communicated version number and us as its invested maintainers, so I'm happy to toss the issue of new/prototype if it's going to require too much of a rewrite.

I feel more positive about the idea of bringing in some of Ender's component (not Ender) to perform tasks such as DOM selection and events.

@tmcw is the non-use of these libraries hindering you in any way right now? Is there something you'd like to do but don't feel that you can, because they are not included? Are you hoping to dig into the internals yourself and feeling put-off by the raw DOM parts?

[tmcw]

The non-use of a general library isn't really hindering what I'm doing so far - and using one would ideally not change the API much. I've been mainly just looking for various tweaks that could be useful for the library, and started to find some places where utilities are provided for things that are currently done with custom code. Like storing data associated with DOM elements can be handled by $.data, utils can be blown away by either library, events are normalized in jQuery, etc.

Not to say that it's a necessity - I've actually started an relatively extreme experimental branch and found that there's only a smallish loss to code size by switching to a library. For the time being, probably a smaller jump would be useful.

One of my concerns is that to handle more complex stuff, like double clicks and single clicks on the same map, the amount of generalized event-related code starts to increase. It would be a terrible fate if growth in that direction led to Modest Maps having its own events system like OpenLayers, of for that matter, anywhere near the size of general utilities that OL contains.

Can we create tickets for other tasks that you talked about with Tom?

[migurski]

Avoiding OL's reimplementation of Java is a big plus.

[RandomEtc]

Can we create tickets for other tasks that you talked about with Tom?

Issue #22 is for discussing changing our use of prototype/new. I think everything else is covered.

[tmcw]

I think we're good to close this for now - I've actually tried out moving all of the DOM-work of Modest Maps into jQuery, and didn't see a great size or clarity improvement. Actually pretty great as a learning opportunity - very ready to start returning to more straightforward javascript where jQuery isn't required. My next bit of work dealing with complex events might make me start looking at events microlibraries, but as far as the DOM, we're good.