Friday, June 23rd, 2006
Jitsu: New XML Markup Based Ajax Framework
We have a new Ajax framework just released.
Jitsu contains an integrated set of tools to enable developers to build and deploy sophisticated user interfaces for web applications. These include an Xml markup language, page compiler, data binding engine, JavaScript runtime, control library, runtime inspector, animation engine, cross-platform library, Ajax, and back button support.
The framework focuses on offering:
- Designer friendly
- Rapid iterations
- Open source













Hm, the syntax looks quite restricting in terms of what you can do with it. Furthermore, I don’t know why this couldn’t be done with libs like prototype etc. From the sample above in regular JS:
<body onload="document.write('My First Application:<br />\nHello, World.');">
</body>
Did you look at the site? There’s a pretty comprehensive tutorial that goes through controls, animation, and so on. It also has great API documentation, and if you use a lot of XML, this has some great data binding features.
So it’s a neat idea, but I see three fundamental problems:
First, it really lacks a compelling reason to switch for most people. There’s a pretty steep learning curve, and I can’t see a lot of people wanting to make that investment.
Second, you have to keep your web application or site as a project, and to see each change you have to compile it. It allows you to mix Jitsu code with HTML and then the compiler separates out the two into separate files, but unless I’m writing web applications in Java (thanks, no), compiling my web application is something I prefer to avoid at all costs. Imagine developing a web application with HTML templates–make a change for the server side, you have to compile; make a change for the client side, you have to compile. Ouch.
Third, it has one foot in its XML syntax and the other still in JavaScript. For some operations you can use just the Jitsu syntax on its own. But if you want to do something more complex, you have to drop into JavaScript. For example, consider this (
$leftis set above it):Even with all the syntax stuff, you’re still ultimately calling a JavaScript function,
sender.startAnimator(), and passing a JavaScript object,$left. It sort of feels like a partial solution.So anyway, I can’t imagine ever having any reason to personally use it.
(As a side note, it would be nice if people who posted stories on Ajaxian provided SOME commentary… At least a little.)
The developer experience is much better than you’re suggesting. Jitsu includes a local cross platform tiny web server for the development process that will automatically recompile your pages on demand, so it feels just like loading a page, with a slightly greater delay. It really isn’t like typical edit-compile-run development.
Further, compiling buys you a lot. Browsers may be better than they used to be, but they’re still poor large scale execution environments, with very basic garbage collection algorithms. Every javascript library we’ve seen has a fair amount of data and execution overhead that could have been eliminated with a compile step. We’ve focused heavily on optimizing out as much as possible at compile time for this reason – you don’t pay much price for a lot of the power we offer, like being able to extend controls with subclasses, or converting from fully bidirectional data binding to quick rendering of read-only data.
As for it being a partial solution, the example you gave was intended to show extensibility. Canned component libraries that aren’t extensible usually mean you end up writing your own. Right now we’re erring heavily in the direction of generality, to avoid this. We want you to be able to escape to javascript. We fully expect to can the sweet spot of behaviors so you don’t have to go to javascript unless you need to (animating being a good example). And we would love feedback on what you think these behaviors might be. (Remember that you’re looking at an early preview. This isn’t even beta code yet.)
Jitsu’s data binding isn’t just for xml. In fact, our current back end transport is JSON (we expect to make this pluggable). It’s just that the data objects that are created on the client are expressed in xml, since this gives us all kinds of cool abilities with metadata (like automatically being able to determine what kind of control to use to show a data type, or how to validate particular user input). So I’d rephrase what you said to “if you use a lot of data.”
We agree with you somewhat on the learning curve. There’s a lot of power here, and it takes a while to absorb it all (any comments on opaque docs are very welcome). If you’re just wanting to add a few doodads to a page, don’t use Jitsu. But if you’re building something interactive that renders from any amount of data, and want that to be easy and robust, you might check it out.
I’m sorry, but inline event handlers doing
alert('hello')don’t impress me, and neither doesonload="init()"on abodyelement. Without real examples I can’t judge what your framework has to offer to me, and event the little I did see doesn’t compare to the elegance and inspiration of libraries like Prototype or jQuery.Also, I take it the name — Jitsu — is supposed to be a ninja reference, in which case it’s spelled wrong, as you romanize è¡“ (skill, method) as jutsu.
Ken,
Thanks for the reply. The problem with a local server is that nearly all of these applications will also be dependent on server-side languages like PHP, Perl, etc. and may also depend on web server-specific things like mod_rewrite. Not being able to view the final page when all the elements are composed together is something I would quickly become frustrated with. And often the JavaScript will be interdependent on these pages and the URL schemes, especially in the case of Ajax. I think what would be more helpful is a daemon (both Unix and Windows) that automatically compiles pages as you save them.
As for behaviors, I would copy Dojo, Scriptaculous, YUI, and the rest and hope that the data binding features are enough to motivate people to use a non-JavaScript-only solution. If the comments here are any indication, though…
Poni, I guess it isn’t obvious how many examples there are on the Jitsu site. What you saw is the first “hello world” app, which of course is less intended to impress than it is to illustrate. We’ll have to do something to clarify that.
One of Jitsu’s biggest strengths is in how well and deeply it separates presentation from data and behavior. Here’s another example to demonstrate this. Click on the source markup to see how it’s done.
Matthew, thanks for the great feedback. A filewatcher is an excellent idea. Stay tuned.
Ken
Matthew:
I agree. Were adding a “Proxy” to Puny to address the issue of developing the UI locally but still connecting to remote data services .
Also, once you get used to developing locally, you quickly grow to love it.
See How can my local Puny server connect to data
Thanks for the reply. The problem with a local server is that nearly all of these applications will also be dependent on server-side languages like PHP, Perl, etc. and may also depend on web server-specific things like mod_rewrite. Not being able to view the final page when all the elements are composed together is something I would quickly become frustrated with. And often the JavaScript will be interdependent on these pages and the URL schemes, especially in the case of Ajax. I think what would be more helpful is a daemon (both Unix and Windows) that automatically compiles pages as you save them.
As for behaviors, I would copy Dojo, Scriptaculous, YUI, and the rest and hope that the data binding features are enough to motivate people to use a non-JavaScript-only solution. If the comments here are any indication, though…
Good and usefull.
Thx
CHeers,
Jelenia góra , jelonka
Useful information Thanks you.
I am interested in the topics discussed but have been feeling a little
intimidated by the thought of the work.
I’m not sure though how to start with everything. Jitsu is something new to me. Please give me a link to some tutorial or the likes.