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!
<snip/>
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
Right.
* 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
[1] http://www.crockford.com/JSON/
[2] http://archive.dojotoolkit.org/nightly/testtools/
[3] http://www.edwardh.com/jsunit/
[4] http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
