[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    [Poll] We need to align on one point (was Re: [Vision] Knowing When
From:       Berin Loritsch <bloritsch () d-haven ! org>
Date:       2005-12-07 14:23:25
Message-ID: 4396F05D.9030106 () d-haven ! org
[Download RAW message or body]

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)

[prev in list] [next in list] [prev in thread] [next in thread]