

Yahoo’s Mojito is Now Open Source - gcb
http://developer.yahoo.com/blogs/ydn/posts/2012/04/yahoo’s-mojito-is-now-open-source/

======
stephen
GWT has done the "run the same code on either client or server" for years now
(2006) and, IMO, it's not a silver bullet.

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.

Maybe something magical about JavaScript/node.js will make "write once, run
anymore" actually happen this time, but history isn't in its favor.

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.)

~~~
i5ao
Mojito doesn't try to be "write-once run-anywhere." It doesn't provide any UI
or device abstraction layers by itself, beyond what YUI has always done.

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)

------
blueprint
Here are some of Mojito's existing Node.JS counterparts:

* <https://github.com/substack/dnode>

* <https://github.com/tblobaum/nodeQuery>

* <https://github.com/socketstream/socketstream>

~~~
sh1mmer
I wouldn't call those directly equivalent, although they are in the same
space.

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.

~~~
blueprint
That's what I gleaned too; maybe "alternative" would have been a better choice
than "counterpart".

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.

~~~
sh1mmer
DNode is about Node APIs on the client, where as YUI is about x-client code.
As such I'm assuming moving YUI based rendering back is a lot more x-client
compatible than using DNode to mimic Node's I/O interfaces.

I think my point is that sharing JavaScript isn't the biggest challenge in
this space. Having a cross-browser rendering system that also runs effectively
in Node is.

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.

------
mey
From a security perspective, this description scares me a little. There is a
big difference from code executing in a trusted environment vs code executing
in an untrusted environment. Not sure a clear approach on the "correct" way to
manage this issue has come out from these cross platform products.

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).

~~~
underwater
I don't think it's so bad if you have a clean server side API that enforces
your business rules. The application code can then be run anywhere.

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.

------
wisty
OK, so it's MVC javascript (like backbone.js), with node.js in the backend,
and some kind of move towards local storage + synchronization.

They say that it's not yet totally done. I'm guessing sync is the hard bit.

------
debacle
I was honestly expecting much much more. Yahoo has talent, and YUI was the
best library out there when it was new.

~~~
ary
YUI was released the same year as jQuery. Care to qualify that a bit?

Edit: Had my dates wrong.

~~~
debacle
YUI was more extensible, followed (mostly) good JavaScript patterns (making
heavy use of the module pattern), had relatively good cross-platform support
and an easy to understand interface.

To top it off, the documentation was top notch.

~~~
jmathai
> 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.

~~~
digamber_kamat
That is not true. YUI community is pretty vibrant and the developers go out of
the way to help you.

~~~
jmathai
Here's an example.

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. <http://developer.yahoo.com/yui/connection/>

JQuery's page has it listed immediately. In fact, 2 variants above the fold.
<http://api.jquery.com/jQuery.ajax/>

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.

~~~
debacle
You're looking at the current version of the documentation. jQuery didn't have
nearly as good documentation five years ago, and YUI's was much better than it
is today (I think YUI3 is a step back for Yahoo).

~~~
jmathai
So jQuery's has gotten better and YUI's has gotten worse?

I just know that when I did try it (2009) I felt the same as I do today.

------
raphinou
<http://webtoolkit.eu> is for me the future of web development: let the
framework handle all the plumbing. Mojito claims to blur the client/server
boundary. With Wt, you don't see it anymore. If you're a web developer, really
worth a try!

~~~
oblique63
Sounds similar to GWT: <https://developers.google.com/web-toolkit/>

aside from being in c++, any other differences or reasons why one might choose
this over GWT?

~~~
raphinou
It is not similar to GWT: GWT is client side only, with Wt you develop one
code-base all in one language (C++ or a JVM language) that handles
transparently server side and client side operations, including communication
between both sides.

------
shirkey
Using the @ symbol as the hook for a function call would seem to be not only
dangerous (corner cases of email or twitter address) but also superfluous --
if Mojito is acting as the web server, shouldn't _every_ request be mapped to
some sort of functional request, even in the case of serving static content?
If it isn't acting as a web server, would the proxying server in front of it
be routing the appropriate functional requests to Mojito?

~~~
i5ao
the "@" prefix is only a short-cut if you haven't defined any routes. Mojito
also defines app-level and mojit-level static routes.

------
jberryman
So mojito is some kind of cocktail that runs on the client and the server and
is for "apps"...?

------
jzhou
It's final people, with Mojito, NODE TRULY BECAME THE FUTURE WEB. Thanks,
Yahoo!

~~~
mrinterweb
I'm pretty sure it is safe to say that node will be the only technology the
web will ever need from now until the end of time for all web dev tasks. Great
job we did it.

------
whirlycott1
Note to self: try not to make announcements on April 1st lest they get
mistaken as jokes.

