Yahoo’s Mojito is Now Open Source

http://developer.yahoo.com/blogs/ydn/posts/2012/04/yahoo’s-mojito-is-now-open-source/

by gcb • 14 years ago

130 36 14 years ago

developer.yahoo.com

wisty• 14 years ago

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.

debacle4• 14 years ago

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

ary• 14 years ago

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

Edit: Had my dates wrong.

debacle4• 14 years ago

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.

thezilch• 14 years ago

At the time and for at least a year following...

  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

jquery has come a long way with documentation, but then YUI has evolved even further in becoming a modular library.

dmethvin• 14 years ago

Can you be more specific about what is missing?

debacle4• 14 years ago

It's not about what is missing. It's about what is there. The monolithic web development 'MVC' platform thread is dead and gone. Mojito is a behind the curve also-ran, definitely not New Hotness.

wavephorm• 14 years ago

  Yahoo has talent, and YUI was the best library out there

No not really, and not it wasn't. Yahoo's UI library didn't really offer any radically new concepts. It was a recap of other libraries. For example instead of TinyMCE you could use YUI's editor which did almost the same thing, instead of jQuery you could use YUI's dom code, and so on.

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.

gcb• 14 years ago

> For example instead of TinyMCE you could use YUI's editor which did almost the same thing

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.

but YUI did wonders to save us from java and OO programmers that didn't want to "get" javascript but wanted to publish code anyway. it was a library for OO in javascript like no other. now YUI3 is mixing all concepts and going nowhere in particular. sad.

i5ao3• 14 years ago

jQuery is pretty great, but YUI shines in bigger projects for larger teams. The 1) module system, 2) conditional loading 3) combo loading and 4) and bias for structuring your code with pub/sub; these really really help in cases where there might be many javascript mini-apps running on the page who can't know anything about the other.

jQuery has these things too, especially recently, but YUI enforces this... for better or worse, in a more "enterprise-y" way

blueprint2• 14 years ago

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

sh1mmer2• 14 years ago

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.

blueprint2• 14 years ago

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.

KaoruAoiShiho• 14 years ago

Those aren't really in the same league. It's more like this: https://github.com/codeparty/derby

jberryman• 14 years ago

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

whirlycott1• 14 years ago

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

stephen• 14 years ago

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

mseebach• 14 years ago

I think the domain of validations that are independent of server resources is larger that you express. There's the whole "consistency" check - if X is checked, Y and Z must be filled out etc. Also, check-digit checks on values such as ISINs[1] (real-life example).

1: http://en.wikipedia.org/wiki/International_Securities_Identi...

i5ao3• 14 years ago

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)

raphinou2• 14 years ago

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• 14 years ago

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?

truncate• 14 years ago

Maybe because GWT compiler is horribly slow.

raphinou2• 14 years ago

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.

jzhou2• 14 years ago

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

mrinterweb• 14 years ago

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.

mey• 14 years ago

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• 14 years ago

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.

shirkey• 14 years ago

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?

i5ao3• 14 years ago

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

Yahoo’s Mojito is Now Open Source

Related Stories