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.

swing, eh?

[BortQ]

The API is similar to that of Swing

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!!!

That is all.

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.

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.