Echo Web Framework

As far as server-side vs. client-side Echo3...

I've been writing a lot of client-side code lately, and personally now prefer writing code client side. And saying this is probably going to get me laughed off the forums, but part of the reason I like the client-side approach is *because* you get to write everything in JavaScript instead of Java.

A big part of the reason for this blasphemous statement is that I find hierarchal component construction to be of enormous benefit to UI code. It's just easier and more pleasant to write this way. Take the case where you need to redesign a UI to where another container exists at some mid-level of the hierarchy. With "flat" code this can be a very annoying task, but when you can see the hierarchy in your code, it's a cakewalk. Not having to name every container element of the UI (e.g., outerPane, topCenterPaneContainer, lowerRightSplitPane) is a major feature as well. See the "Technology / JavaScript Development" section of the Echo3 Demo app @ http://demo.nextapp.com/echo3csjs/ for an example.

It's also incredibly convenient to create event-driven code in JavaScript (using Core.method() to create method references). Combining that with simply defining event objects on the fly, e.g., this.fireEvent({ source: this, type: "foo" });, writing event-based code becomes so trivial that it's the easiest approach available....there's not even a hint of temptation to just pass around an object to avoid having to declare a Listener interface and event object class.

Yeah, JavaScript is certainly not without fault, but I'm finding more and more that it seems to be a wonderful platform for creating UI code. And yes, server-side Java development with Echo3 certainly makes more sense in many cases.

You can mix client-and-server side development with Echo3. The Rich Text Area is a good example...it's what's referred to as an "Application Rendered Component". It *is* a client-side Echo application, which is wrapped up inside of a component. Using this methodology let us re-use the Echo menubar, windowpane, coorselect, and various layout components to create it...so it winds up only being about 1,000 lines of code in its current state IIRC. Any data inside of the application can be synchronized with the server via properties on the wrapping component object. There is some documentation available for this, albeit incomplete at present: http://echo.nextapp.com/site/node/63

GWT vs. Echo3 client....

I'm terribly biased of course. GWT certainly has a very interesting approach. If I'm writing client-code though, I'd rather write it in JavaScript, for the reasons previously mentioned.

As far as comparing, I'd make certain that a GWT user interface can offer adequate performance with large UIs, and that code modules can be incrementally loaded. Again, I'm obviously ridiculously biased, and don't mean to talk down on a competitor's product here, but I believe Echo3 has strengths in these areas over GWT so I'm compelled to mention them. Obviously get both sides of the story (the other being unlikely to be offered by people who prefer Echo).