cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Date Wed, 07 Dec 2005 15:56:43 GMT
Berin Loritsch wrote:
> In the exchange below I did some creative snipping to emphasize where 
> we are not 100% aligned on vision.  Below I will bring out my points, 
> knowing that I'm not the guy who sets the tone for Cocoon.

We are collectively setting the tone, and your inputs are very valuable!


> I can infer from Sylvain's vision that he sees value in using 
> JavaScript on the server as well as on the cient.  And why not?  We 
> have the solution already in place.
Yep. Several reasons for this:
- JS provides a more concise writing, which is great when you write the 
glue code of your application,
- my experience is different than yours, as I've seen many people using 
Cocoon being unable to write a Java class but perfectly able to write a 
flowscript to drive page flow, display forms and glue components together.

> Now, the Pros of using JavaScript that I can see are as follows:
> * Common syntax on server and client
> * Easy to use Java objects in JavaScript code
> * Easy to add support for continuations
> The cons I see are as follows:
> * API depends on bound objects (not consistent between client and server)
Yep. Now stuff like JSON [1] can allow for *very* easy client/server 
communications in Ajax scenarios.

> * No testing framework for JavaScript Code
People writing Ajax libraries are getting serious about unit tests. Have 
a look at [2] and [3].

> * Requires embedding a JavaScript runtime in the server
Rhino will be embedded in JDK 1.6 (or whatever its name)

> * We can't use the same debugger in our IDE to step through server 
> side JavaScript code

> * No IDE support for JavaScript
There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4] 
that does autocompletion of function and argument names, plus tooltips 
and all that stuff. It even accepts additional completion description 
files that we could generate automatically from the API that we expose 
to the JS engine.

> * It's another language to have to learn
Yeah, but a language that many people already now.

> The testing framework for JavaScript is easily overcome.  We could 
> create something to get that working.  In Java 6 (still being worked 
> out) JavaScript is supposed to be embedded into the core, so when the 
> IDEs tool for Java 6, my objections involving IDE and debugger will go 
> away--but that is a ways off still.  Which leaves us with the API con 
> and the learning con.
> I will stick to my guns for my belief that JavaScript will fail in its 
> mission to bring "less technical" people to work on the server side.  
> Less technical people need all the handholding they can get, so 
> without IDE support and a well defined API they won't know what to 
> do.  That does not mean that JavaScript is evil, or that it doesn't 
> have a place on the server or in Cocoon.  I just think we are kidding 
> ourselves if we think it will allow less technical people to do a 
> programmer's job.

Again, I have seen semi-technical people doing great things with JS. Not 
all the bells and whistles of the full J2EE stack, but some fairly 
advanced stuff they could never have done with only the Java API (nor 
PHP, btw).

So the flow controller is really a place (and the *only* one actually) 
where I value having two implementations, one in Java and one in JS. 
However, these two implementations should really be a very thin layer on 
top of a common controller infrastructure, both to reduce the effort and 
ensure long-term consistency.

> What's your preference for the vision?
> [ ] All web apps written in JavaScript
> [ ] All web apps written in pure Java
> [X] Mix and match (not as simple, but is status quo with today)



Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message