Building Rich-Client-Like Web Apps With Echo

An anonymous reader writes: "IBM developerWorks is running a feature on the 'Echo' project, which is used for creating web apps that 'look and act like rich clients.' Echo uses HTML and JavaScript to render a user-interface in the browser instead of client-side plugins like Java WebStart. The API is similar to that of Swing. The article examines an example email client written with the technology. The framework itself is built on Java servlets, and is distributed under the LGPL. More examples can be found here."

Comments

advantage?

[ddd2k]

I don't see the problem of using a servlet-applet combination for interactions with a server through a user-friendly graphical interface inside a browser. It really isn't asking much for a graphical designer to learn how to use Swing and java graphics APIs.

Re:advantage?

[josepha48]

Hmm some companies dont like applets. Also applets can be really time consuming to download and don't always work in the browser. This is not to say that javascript on the client side is going to be any better. I can write a boat load of scripts to crash a web browser though ;-).

However the big thing at many companies today is 'do you have a web front end?' No, oh were going to someone who does. Why cause its considered 'cool and new and in and hip'. Yeah okay that's crap, but talk to an exective and that is what many want for some reason. My companies president is just this way. He wanted a java web application front end. He didn't know what he was asking, but he wanted it anyway. What a dumbass huh?

Why is this happening? Maintenance and deployment. I can setup a webserver and when I need to push an update to the software out to the users I just update the webserver and everyone gets it. Java applets may get broken if the right VM is not on the client. Javascript is pretty basic and much of it can be coded to work well with both IE and mozilla and netscape. There is plenty of browser detection code in JS already out there. Rich clients are what people want too.

Also this means that one can lock down a desktop system so that it only has a web browser and everything a user does is done using the browser. Similar to the old green screen models, only now the client is a little more powerful.

Imagine having ot go and install software on 3000 users desktops. Asking users to install software themselves can sometimes be asking for disaster. mac's update is pretty good, but now you just have to get the users to run the update.

Software push is the way that companies want to go, and the web offers them the easy way to push.

Yeah everything is 'web this / web that' but so what?

Anyway, this whole echo stuff is just allowing a java developer to develop code for a rich client that happens to be a web browser without having to think about cookies and maintaing state. What's so bad about that. Hey if you don't like it dont use it.

Re:advantage?

[TodLiebeck]

I don't see the problem of using a servlet-applet combination for interactions with a server through a user-friendly graphical interface inside a browser. It really isn't asking much for a graphical designer to learn how to use Swing and java graphics APIs.

:D

I take the point here to be "How does Echo fit with the needs of the creative/graphics design team when building applications?" Certainly a valid question.

First of all, I'd like to make clear that Echo isn't based on Swing, and you don't wind up using the Java graphics APIs all that much (they're only used when you want to dynamically generate images, which isn't necessary in most applications). Echo has enough similarity with Swing that your underlying statement is still valid: creative designers are not going to be working with it.

The interactions between designers and developers when building an Echo application will be the same as they would have building a rich/thick-client app. The responsibility is placed on the developers to integrate the graphical elements designed by the creative team into the application. We can "get away with this" for a couple of reasons:

- Echo is best used in scenarios where rich clients would be otherwise. Such applications don't tend to be "Web-site-like", where presentation is everything, and visual pieces are modified every few weeks at the whim of the marketing department.

- The API used by Echo developers to lay out user-interfaces is easier to work with than HTML. For example, there are dozens of little tricks used by web developers to get HTML tables to lay out content correctly. It's not uncommon to have to do quite a bit of arithmetic calculation if you want to construct, for instance, a table that has fixed width cells, margins, paddings, and some cells spanning multiple columns (I'm sure some might think I'm full of it here, but I bet their tables don't look right on all platforms/browsers :)). Anyway, point being, Echo's Grid component offers a much simpler interface and performs such calculations (and many other table rendering tricks) for the developer. You can even do things like allowing cells to fill empty space in a particular direction. The result is that the effort required of the developer to integrate visual design elements into an application isn't anywhere close to what it is with a traditional roll-your-own-HTML app.

While I'm at it, one other thing I need to mention is that Echo doesn't make use of any applets. It's all servlet-based, and the client-side user interface is rendered using only HTML and JavaScript. (Although it is possible to write Echo components that embed items such as Applets, movies, or Flash objects).

Re:This is dumb

[redtail1]

I don't see the downside to a framework for writing apps whose target audience is any computer with a browser.

Yes, there are other ways to do it. Why do you feel threatened by another one?

swing, eh?

[BortQ]

The API is similar to that of Swing

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!!!

That is all.

I've already made such a system

[mithras the prophet]

echo <<<html>
<head>
<title>My rich-client-like web app</title>
</head>
<body>
[ note to self: put forms and javascript and stuff here ]
</body>
</html>

EOQ

Inefficient and Slow

[slashkitty]

I found this to be the worst web development ever. Using javascript to instead of regular links makes it slower and messier. Just because the application may be a little easier to write doesn't make it a good idea. In the email example, the login form submit uses javascript. The link to view the email uses javascript and reloads both frames, very inefficient. It also seem to do multiple submits/redirects just to load one page. One could have just used to highlight the table row, instead of reloading the entire window. Not only that, but the app doesn't even work in Mozilla for me!!

web apps that 'look and act like rich clients'?!

[uradu]

Don't think so. Their sample apps behave JUST like regular old web apps because that's what they are. The webmail example looks and feels pretty much like any other webmail client, with a "dead" HTML message list that refreshes the entire page when clicking one message, just to highlight it. What one usually understands by a rich GUI is that there are high-level components for common visual elements such as lists, trees, tabs etc, that provide more or less complex functionality. The highest level component I see in their stuff is the HTML table. Yay! Maybe they just didn't demo the right stuff, but so far the main gain seems to be the GUI programming paradigm on the back-end. Which is nice, to be sure, but a rich client it ain't.

what echo is used for....

[jp_fielding]

DISCLAIMER: i'm an echo user...so i'm biased

as some comments above state, echo will not cure little timmy's cancer.. it is a tool like all other tools and has it's place.

why not just deploy thick clients....? maintaining thick clients (or at least getting a jvms installed and running) is a pain.

it can use higher amounts of memory, it uses a lot of javascript, it can even generate a lot more html than 'absolutely' necessary.

that said, it's main purpose is for deploying 'rich' clients, generally on high bandwidth connections like a lan or corporate network.

for these possible issues (as they can be mitigated), you get 'real' component reuseability, massive refactoring support, type safety and last but not least..... no more need for html or linking.

these last 2 may seem trivial and even unnecessary, but the more important question, is why would you want to know these things? is it important when editing documents? is it important when writing thick client code to know exactly how each pixel is going to be written, and for that matter, that it's absolutely the most efficient?

the strangest part to me is why hasn't something like this already come about. every other language, java included, has some form of a Windowing Toolkit, why not a Web Windowing Toolkit. people started editing html files, then started making them dynamic, then just kept on going (myself included) like forrest gump. but why, when we began actually writing applications didn't we stop and build the tried and true abstraction models that have proven themselves over and over. if that had happened with thick clients, would we not be writing those in some form of pixel markup language?

anyways, it's not perfect (but i think it's quite close), but for that matter nothing is, but i tried it, and i don't know if i have it in me to ever go back, it was just way too much work before. i can only suggest you make the same leap.

Good luck for those who are willing to try it, it's an investment that returns.

Warning, Echo does not work with Firebird 0.6.1

[TodLiebeck]

akweboa164 wrote:
Each of the sample apps don't seem to work in Mozilla Firebird 0.6.1.

Thanks for pointing this out. On looking into it, Echo does NOT appear work on Firebird 0.6.1 on either Windows or Linux. 0.6 works properly, as does a fresh nightly build that I downloaded just a minute ago. Mozilla 1.0-1.4 also should work fine. Mozilla and its derivatives are very much in the "first-tier" of target environments for Echo. It's quite frustrating to see that this problem with 0.6.1 was not previously noticed.

The particular piece of code that appears to be tripping up 0.6.1 is a single line of javascript:

history.go(1);

This is used to ensure the browser is always on the latest page of the history at all times. When executed in Firebird 0.6.1, a JS exception occurs indicating that the "history object has no properties". On further investigation, it appears that the history object does not exist in 0.6.1. I'm guessing that this is a problem in this particular version of Firebird, as no other browser encounters this issue, including previous and current (nightly build) versions of Firebird. The O'Reilly JS (rhino) book seems to think the code is legal too.

If this problem presents itself in future versions of Mozilla, Firebird, or any other browser, we'll have to modify the browser detection startup script to disable this feature based on browser type (unless of course I'm wrong and history.go() is no longer fashionable).

Thanks again!

Re:This is dumb

[MacroRex]

Yes, options are always good.

Echo seems interesting, and there is also Millstone, which is truly terminal independent, whereas Echo seems to be browser only.

Fundamentally the two platforms seem to be very similar, just take a look at the HelloWorld examples: HelloWorld with Echo, HelloWorld with Millstone.

The important thing about a platform like this is the default component library, and at least Millstone has a versatile and strong component set that's also as small as possible. Take a look at their feature demo that showcases the basic components. The feature demo itself runs on Millstone.

The code is not valid!

[bertilow]

The Echo HTML code isn't even valid!

Such applications could break in future browsers. Browsers tend to become stricter and stricter. Only valid HTML is future-safe.

They can't even put a correct doctype declaration in the HTML!

And frames are crap anyway, even if you do the code right.

Re:The code is not valid!

[TodLiebeck]

"The Echo HTML code isn't even valid!

Such applications could break in future browsers. Browsers tend to become stricter and stricter. Only valid HTML is future-safe."

Rendering correct and "future-safe" HTML is a very critical concern in the development of Echo. In a few cases Echo will even render alternate non-standard HTML based on the results of browser detection. As we all know, browsers often don't conform to the spec. I'd personally love to be able to dump all such "workaround" code, but end-users appreciate things looking and working correctly far more than adherence to the HTML specification.

The goal is to keep Echo as close to the spec as possible. If you see something in particular where we have deviated from the specification incorrectly, please, please, please let us know. Post something on the mailing list, developer forums, or even in reply to this comment. It would be greatly appreciated.

Another issue you might find when validating Echo's generated HTML code is that some validators get tripped up by some of the URIs. W3C's for example doesn't care for the following img "src" attribute:

src="/EchoWebMail/webmail?E_id=E_ls&E_z=107a6_ 0"

"They can't even put a correct doctype declaration in the HTML!"

All Echo rendered HTML documents have a DOCTYPE declaration. If you see one that does not, please let us know. I would definitely consider this a bug.

Also, if you're referring to character set-related issues, please understand that we do provide this information in the HTTP response header. If you're cutting and pasting the source into a validator, this information will be lost.

"And frames are crap anyway, even if you do the code right."

I would disagree. Breaking up code into smaller documents that may be independently refreshed has performance advantages. Frames can be a major pain when developing page-based applications, but Echo's JavaScript libraries take care of these problems to ensure the developer doesn't have to deal with them. For example, when a user clicks a button in Echo, the server will be notified of all changes (e.g., modified text fields) in every frame and window of an application. This is performed by storing the form values in a single non-visible frame that is submitted in response to the user performing an action that requires server interaction. The response to this request will contain JavaScript directives to re-render other frames and windows of the application, thus eliminating the "big problem" encountered with frame-based apps where the developer would be required to know which frame was to be refreshed in response to a specific user action.

For more info on how Echo does this, take a look at:

http://www.nextapp.com/products/echo/doc/hltov/int eraction.html

Re:Doesn't work in Firebird

[TodLiebeck]

This framework is appalling. I'd expect better from IBM, and I don't even have that high an opinion of them!

This framework isn't written by IBM. The article is on IBM developerWorks, which is a developer's resource site that often publishes material on open-source third-party products.

Standards compliant XHTML and CSS are the way to go with Web based apps. Sure, on old/non-standard browsers the pages might look like ass, but they should work.

Unlike this.. which only seems to work in my IE6, but not my browser of choice.

Echo does not work with Mozilla Firebird 0.6.1. It works with 0.6, and with the latest nightlies. To the best of my knowledge, this appears to be due to a bug in Firebird. (Please understand that it's possible I'm wrong on that, I'm still looking into the matter). Keep in mind though that the stable Mozilla series (1.0-1.4) is very much a first-tier supported platform for Echo. Firebird support *is* important, as even though its not an officially stable release yet, it is a very cool product, and is tremendously popular among developers. See this post for more information on this problem:

http://developers.slashdot.org/comments.pl?sid=778 63&cid=6917761

Echo doesn't render in XHTML yet (it presently renders HTML 4.01 transitional, and does use CSS as much as possible). We will go to XHTML when it makes sense to do so (Which I personally hope is sooner rather than later). Please also take a look at this recent post of mine if you'd like more info on how we deal with specification compliance:

http://developers.slashdot.org/comments.pl?sid=778 63&cid=6924701