Being a JavaScriptMVC contributor, I m extremely biased. But I ll try to give the best answer I can.

JavaScriptMVC has also taken years to develop. But instead of focusing on ui functionality, it focused on the layers just below that. There are a few reasons for this:

1. You can find a jQuery widget to meet almost every need. There s no reason to compete these plugins. Instead, JavaScriptMVC tries to work with them.
2. Most people need one or two custom widgets / controls. JavaScriptMVC wants to make building and maintaining these pieces as easy as possible.
3. Flexibility+API. I m not sure exactly how to say this one ... but here s my best shot ... With JavaScriptMVC, we wanted every layer of the application to be as easy to understand and maintain as possible. This is why we picked jQuery as our low-level library. It s API is about the best abstraction for the dom possible. People typically go directly from the low-level API to build the Widget/Control. This is why most jQuery widgets code look very dissimilar. We wanted a middle layer that organize our code and promote best practices, while providing enough flexibility to meet almost any requirement. So with JavaScriptMVC, you get very solid low and middle-level layers. But, you don t get widgets.

JavaScriptMVC has testing, error reporting, and documentation baked into the framework. The testing is the most impressive part. It has integrated selenium and envjs testing.

My recommendation would be to go with SproutCoreif your requirements can be built pretty straightforward with SproutCore. But if you know jQuery, have to build a lot of custom controls, or need really awesome testing, use JavaScriptMVC.

Funny, because just a month back or so, our team evaluated exactly these 2 frameworks head to head. We ended up choosing JavaScriptMVC, and I ve been working hands-on with it for about a month.

I like it ... but, I was a HUGE proponent of SproutCore. I had never heard of either framework before we eval d them, but once I saw SproutCore and looked under the hood, I was very, very impressed. Honestly, I don t think there s anything out there that can give you the kind of power it gives. Yes, you ll have a learning curve, but it s the kind of thing that lets one person accomplish the work of 5 or 10 once you know it.

So I d use SproutCore in a heartbeat.

That being said, JavascriptMVC (aka "JMVC") is nice. It doesn t really give you a ton on top of jQuery itself. You will still have some infrastructure to build yourself (depending on how complicated your requirements are). This is both a pro and a con. One nice thing about it is that, if you need to dig into the details of some piece of JMVC, you can ... it is not so incredibly huge that it is impenetrable.

In summary, there s not a thing wrong with JMVC. But there is, in my opinion, nothing even in the ballpark with SproutCore.

I think that the main difference between them is that SproutCore includes a GUI while the JMVC is something low-level without any graphic, so if you need a GUI you can t use JMVC without including other scripts like the jQuery UI or jQuery plugins.

You said that "JMVC might just be better because it doesn t try and do too much" i don t agree with this, it took years before SproutCore 1.0 was released, so developers had the time to make a great product.

I suggest you to use SproutCore, maybe you ll have to learn more things, you ll spend more time to practice and understand everything, but you ll learn how to use a very good framework that can be usefull also for future projects.

Sproutcore-2.0 eliminates the ui-constraints and plays nice with completely custom app-uis.

http://blog.sproutcore.com/announcing-sproutcore-2-0/

http://blog.sproutcore.com/dispatches-from-the-edge-dropping-in-a-sproutcore-2-0-application/