[madrobby]

The point is that Emile is 50 lines of code and can be wrapped up for any purpose in about 2 minutes (export to some object).

Dustin wanted a different API to call upon, so he had to change some stuff, again relatively easy, because it basically fits on a screen in a text editor.

Let's not forget, all of this is open source, and it's meant for adaptation, forking and to be built upon. (Note that Emile was very much a proof-of-concept, with no emphasis on beatuiful, reusable code; it was written as a teaching tool for a talk on CSS animation I gave two years ago at Fronteers.)

[slexaxton]

I agree, but I think the point of Tom originally linking it was to show that Dustin had integrated a micro-framework (from you), and couldn't get a response from you (even to say the stuff you mention above) and eventually closed the ticket.

It's not my own commentary, though. I was just clarifying to Amy why the argument that seemed entirely unrelated was at least tangentially related. Personally, I would have just modified it and went on my way :D

[polotek]

Actually Dustin's pull request is a bad example entirely. He wanted to change the whole API of emile. He liked the functionality but it didn't work for how he wanted to integrate it into ender. If an API doesn't work for you, you're kind of screwed, whatever library you're using. You either hack it yourself or you ask the maintainer. If some API of SproutCore wasn't to your liking, then what?

Dustin could've written an adapter around emile to expose the api he wanted to for ender. But that would defeat the purpose of ender which is to cleanly integrate several great micro frameworks. He didn't have to wait for Thomas. He wanted to explicitly. It was a goal of his to keep the dependencies pure.

Dependency hell is a problem with integrating several different frameworks. But I'm not sure this is the best illustration of that.