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.
Torsten Curdt wrote:
Berin:
... I envision a Cocoon which takes its principle strengths in
separation of concerns to make developing web applications easier.
... I envision a Cocoon where I only have to learn Java and XML to
be affective. ...
Sylvain:
... I envision a Cocoon where people can use a single unified
scripting language for both the client and the server. ...
Torsten:
... I envision a cocoon where flow is not a 2nd class citizen.
The conflict in vision is actually between Sylvain and I. OK, conflict
is a strong word, more like we are not on the same page. Both Sylvain
and I are aligned with Torsten, but we most likely have different ideas
on how to get there.
Bottom line: I am in favor of Java Flow, and avoiding embedding any
scripting languages in the core. If you want to add a scripting
language front end, I would suggest it be an add-on. Why? Because it
both simplifies the design, and it minimizes the number of things the
user (in my experience it is always a Java developer) has to learn
before they can be effective.
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.
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)
* No testing framework for JavaScript Code
* Requires embedding a JavaScript runtime in the server
* We can't use the same debugger in our IDE to step through server side
JavaScript code
* No IDE support for JavaScript
* It's another language to have to learn
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.
Now, my chief goal and my chief vision for Cocoon is to simplify the
number of concepts a user has to learn before they are effective with
Cocoon. That might mean that we provide JavaScript as the only way to
interact with the core. All web applications would be written in
JavaScript from control to helper functions. Or all web applications
would be written in Java from control to helper functions. It is
incredibly awkward to mix and match as the default way to do things. It
is difficult to explain when and where to use which language. Now, for
advanced users who don't mind the mix and match, I have no problem with
having tutorials on how to do that properly.
What's your preference for the vision?
[ ] All web apps written in JavaScript
[ ] All web apps written in pure Java
[ ] Mix and match (not as simple, but is status quo with today)
