Thx

CHeers,

Jelenia góra , jelonka

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…

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…

There’s a lot of power here, and it takes a while to absorb it all…

I’m sorry, but inline event handlers doing alert('hello') don’t impress me, and neither does onload="init()" on a body element. 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.

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.

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 ($left is set above it):


<j:Button text="Relative" click="sender.startAnimator(ID_anim2);" style="position: absolute; left: 0px; top: 50px">
<j:Animator animatorId="anim2" propertyId="$left" to="100" relative="true"/>
</j:Button>


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


<body onload="document.write('My First Application:<br />\nHello, World.');">
</body>