Beyond trivial validations (not null, length check), most of interesting the business logic you run on the server assumes server resources. E.g. a chatty/optimized db connection, or a wire call to some backend service that the client can't make directly.
Don't get me wrong, it is nice, for some formatting, validation, etc. purposes. I just don't see server-side-only code going away anytime soon. (Which I'm sure is not what they're saying, I'm just musing here.)
It's an MVC app framework, oriented towards composing modules/widgets-- aka mojits. If you want to render your stuff server-side, you can. If you change your mind, it's a pretty trivial change-- and in fact you could do it at runtime (Yahoo has a search product in beta that does this after instrumenting the connection/device speeds).
There will always be server-side only stuff, but at least you don't need to switch languages or frameworks when you decide what to do where.
A sweet spot might be an online/offline HTML5 app that uses YQL or other webservices, for which you want to provide desktop, tablet, and smartphone versions and/or native versions via phonegap or similar.
That said it's definitely not for everyone, and it's still a very young project.
(disclaimer: I work at Yahoo)
One of things Mojito is supposed to do is allow progressive enhancement (for performance, etc) by allowing you to define how much rendering takes place on the client and how much on the server.
In one of my recent projects I used EJS and DNode to fairly easily implement a system for determining where the rendering takes place. I don't have anything to monitor connection quality & client capabilities though, so Mojito may prove useful when it matures.
While you could use DNode to make that, I'm wondering if it would be nearly as robust as what they are trying to do.
Edit: Note, this is a double edge sword (do I as a user trust the code dynamically loaded at run time?) but I was referring to it from the perspective of the operator (what methods executed must be correct and can't risk being modified in execution).
I assume you'd write code for client side execution (i.e. don't fetch unneeded data, reduce round trips) and get the the server side excecution and a battle tested public API for free.
This seems similar to the approach Parse is promoting with their service.
They say that it's not yet totally done. I'm guessing sync is the hard bit.
Edit: Had my dates wrong.
To top it off, the documentation was top notch.
Serious? That's what drove me away. It might have been top notch academically but for real life use I found it painful to get answers and simple code problems fixed.
The top hit on Google for "make an ajax request with (YUI|jquery)" the documentation page is the first hit.
YUI's page is here, the line of code to make the request is well below the fold.
JQuery's page has it listed immediately. In fact, 2 variants above the fold.
I'm not saying one is right and another is wrong. I'm just saying jQuery's gets more adoption. It's easier and people tend to like that.
I don't, for example, understand why I have to scroll past the YUI dependency configurator to get to the syntax I'm looking for.
I just know that when I did try it (2009) I felt the same as I do today.
1. Yahoo hosted scripts, including roll-ups
2. UI components and styles
3. The best documented library, both outside and inside thde code, hands down
4. More feature complete (ex. one I can recall off the top of my head, form handling of upload inputs didn't exist in jquery, and extending jquery internals was/is a nightmare in comparison)
5. The best documentation, hands down
6. Yahoo hosted scripts, including roll-ups
7. The best documentation
Yahoo has talent, and YUI was the best library out there
I didn't really expect anything amazing from Yahoo. They'd need to come out with something truly extraordinary to make me pay attention. And given their webpage hasn't changed since 1998 I doubt that will ever happen.
jQuery has these things too, especially recently, but YUI enforces this... for better or worse, in a more "enterprise-y" way
that's like saying glibc is worthless because you can run your ISO C programs the same. and you are ignoring all the POSIX work done to it.
YUI widgets, i agree, are a little meh.
aside from being in c++, any other differences or reasons why one might choose this over GWT?