Slashdot Mirror


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."

8 of 70 comments (clear)

  1. Re:advantage? by josepha48 · · Score: 4, Informative
    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.

    --

    Only 'flamers' flame!
    Does slashdot hate my posts?

  2. Warning, Echo does not work with Firebird 0.6.1 by TodLiebeck · · Score: 3, Informative
    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!
  3. Millstone by Anonymous Coward · · Score: 2, Informative

    Another similar framework you might want to take a look is Millstone. Main fundamental difference is that Millstone provides themes through usage of XSL. Some of the UI-components look really nice in the default theme (demo can be found here).

  4. Re:This is dumb by MacroRex · · Score: 5, Informative

    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.

  5. Re:Gain, less pain by innerlimit · · Score: 2, Informative

    I didn't see someone mentioning Bindows yet.

    Yes, I know it's Win/IE only...

  6. Re:advantage? by TodLiebeck · · Score: 3, Informative

    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).

  7. The code is not valid! by bertilow · · Score: 3, Informative

    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.

  8. Re:Doesn't work in Firebird by TodLiebeck · · Score: 3, Informative

    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