Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
IBM Java Programming IT Technology

Building Rich-Client-Like Web Apps With Echo 70

Posted by timothy from the stack-em-like-bricks dept.
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."
This discussion has been archived. No new comments can be posted.

Building Rich-Client-Like Web Apps With Echo More

Building Rich-Client-Like Web Apps With Echo

Comments Filter:

  • advantage? (Score:5, Funny)

    by ddd2k ( 585046 ) on Tuesday September 09, 2003 @07:51PM (#6916525) Homepage
    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? (Score:5, Informative)

      by josepha48 ( 13953 ) on Tuesday September 09, 2003 @08:49PM (#6916926) Journal
      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.

      • Quite easy, really.

        1. Install Linux on a good server.
        2. Write your program in whatever language.
        3. Install an X server on the clients.
        4. Profit!

        There you go. Just one place to update when you need to change something. Although not even that is needed. I maintain a program that doesn't have such a huge amount of users, but it has auto-update already. We even have support for blocking too old programs. So it's really not such a big problem.
        • Now try and do that where many of the clients are behind firewalls only allowing HTTP traffic through, are on slow connections, and are not permitted to install software like X Servers on their desktops.

          Step 4 seems to fade away quickly...
          • Um, I'm talking about corporate environments where everybody is on a LAN and nobody has any problems with getting the program.

            For users that need to access the program from home it's of course much more efficent to run it locally. Home users usually aren't limited to only HTTP, though.

            And in any case, a normal mail client needs much less bandwidth than webmail.
            • Most of our clients use cytrix, and they don't want to run Linux, as they don't always 'trust' it. Yeah whatever I run it and have no problems, in fact while they are fighting worms and virus I'm still working away ;-). But they need outlook and office and calendaring and have been hocked into the ms .net stuff and so they work in the windows world. At present they are actually more interested in web services then web frontends. Many want to create their own frontends to our systems, but he ones that do
        • OK, so this thread is so cold that nobody will read this, but hey, I have to say it: In the corporate environment where I work, people are not allowed to load software; the IT department does that. Even if IT were willing to support yet another program (the X server) it would take time for them to evaluate X servers and choose one for their "standard." Then my clients would all have to budget to buy it (because you know IT isn't going to choose a "free" one -- the old there's_nobody_to_sue_if_it_doesn't_wor
      • I am always surprised how much we can get away with developing web apps. While I wouldn't use Echo simply because of the bandwidth it is eating to pull these tricks off (and the probable breakage with minor browser revisions), I can't tell you how often the recommendations for our app is to "windowize" it more. No thanks: I love the fact we can patch once and all our users are "fixed". New features just release: no downlevel users, no data upgrade problems (on the user side).
      • Somehow the other people responding to this post were able to overlook this:

        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?

        I thin

    • Re:advantage? (Score:3, Informative)

      by TodLiebeck ( 633704 )
      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 u

      • The responsibility is placed on the developers to integrate the graphical elements designed by the creative team into the application

        As a web applications developer who comes from a traditional software development background, I would state most emphatically that responsibility should be placed on the creative team not to make the mistake of believing that the user interface of an application is the place for their graphical elements.

        Usability principles apply just as much to a web application as

  • This is dumb (Score:2, Interesting)

    by Curien ( 267780 )
    Ooh! Look! I can put every application known to man in a web browser!

    Web browsers are turning into the Emacs of desktop computing, and it's pissing me off. If you want a front-end, write a front-end, possibly in Java. When you need to communicate with the server, open a friggin socket. Or use XWT [xwt.org] or some other XML-RPC [xmlrpc.com]-based solution.

    Oooh! But it's web-based! Fscking marketroids.

    • Re:This is dumb (Score:4, Insightful)

      by redtail1 ( 603986 ) on Tuesday September 09, 2003 @08:05PM (#6916636)
      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?

      • Re:This is dumb (Score:5, Informative)

        by MacroRex ( 548024 ) on Wednesday September 10, 2003 @01:00AM (#6918729)
        Yes, options are always good.

        Echo seems interesting, and there is also Millstone [millstone.org], 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 [nextapp.com], HelloWorld with Millstone [millstone.org].

        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 [millstone.org] that showcases the basic components. The feature demo itself runs on Millstone.
    • the web browser has set back application development 20 years.

      • Re:I'm with you (Score:1, Funny)

        by Anonymous Coward
        But it increased Programmer income for 7 years, so it's worth it.

    • Re:This is dumb (Score:2, Insightful)

      by mcdrewski42 ( 623680 )
      +1 Troll to the parent :)

      As you said, "marketroids"...

      Add a pinch of "anyone can use a web browser",
      Stir in a dash of "we need lots of training for a 'proper' GUI",
      Season with "GUI application support costs us money"
      Then Bake until golden brown.

      My problem is that I have yet to come across a browser-based interface for anything more complex than 'One-click shopping' that doesn't make me want to beat the designer over the head with a bat.

      Anyone used Domino.doc - IBM's pre-eminent document management syste
      • Love it.

        That's a pet peeve of mine too (you know you're anal when you have a pet peeve about language usage ;). I've been thinking about siggifying it, but haven't gotten around to being witty.

        Kudos to you, sir!
        • Actually, you know you're anal when
          1) you have a pet peeve about lanuage usage
          2) you turn it into a sig
          3) you get frustrated at the 160ch limit because it means you can't put in the other valid use of 'effect' as a verb... :)
    • Troll troll troll. But I still agree with you 100%. Does everything have to be a web application?
    • If you want a front-end, write a front-end, possibly in Java. When you need to communicate with the server, open a friggin socket.

      Java is a fat-client solution. Java applets from a modem are hair-raising. And, sockets often cannot get past firewalls without bothering the network admins with justification forms. HTTP is the way to go.

      Or use XWT

      My pet HTTP-GUI solution is SCGUI (Server-Controlled GUI). It attemps to be more thin-client so that you don't need the "emacs-sized browser" you speak of.

  • Gain, less pain (Score:3, Interesting)

    by redtail1 ( 603986 ) on Tuesday September 09, 2003 @08:12PM (#6916683)
    Good article. Richer GUIs for web apps without the pain of applets seems like a good idea to this neophyte.

    I'll probably give it a shot if I can ever talk myself into playing with compilers again. Scripting languages like PHP are hard to give up...

  • swing, eh? (Score:5, Funny)

    by BortQ ( 468164 ) on Tuesday September 09, 2003 @08:30PM (#6916807) Homepage Journal
    The API is similar to that of Swing

    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!!!

    That is all.

  • I've already made such a system (Score:4, Funny)

    by mithras the prophet ( 579978 ) on Tuesday September 09, 2003 @08:48PM (#6916919) Homepage Journal
    echo <<<EOQ
    <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
  • The term "Echo" is an unfortunate choice of name -- it conflicts with another, new project [intertwingly.net] that aims to "develop a common syntax for syndication & archiving, and an editing API." And, of these two projects, the one to which I have linked is by far the more important and likely to be far more seminal (once they have finished their work). Some of the people behind the "syndication Echo" (as distinguished from the "web app Echo" mentioned above) are very smart, e.g., Sam Ruby, Dare Obasanjo (aka "Carnage4L [slashdot.org]

  • Inefficient and Slow (Score:4, Interesting)

    by slashkitty ( 21637 ) * on Tuesday September 09, 2003 @09:31PM (#6917270) Homepage
    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!!
    • "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 act of using JavaScript in place of a link should not have a noticeable impact on performance. Please take a look at the Echo high-level technical overview [nextapp.com] documentation for more information about why we're doing things like t
    • yeah, i'm using mozilla firebird and none of the demos function. what the hell. thats why web-apps should be as simple as possible.

      you put this stuff in the 'critical path' between a user login and customer checkout and you're gonna lose money, period.

  • web apps that 'look and act like rich clients'?! (Score:4, Insightful)

    by uradu ( 10768 ) on Tuesday September 09, 2003 @09:42PM (#6917400)
    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.... (Score:5, Insightful)

    by jp_fielding ( 564550 ) on Tuesday September 09, 2003 @10:04PM (#6917570)
    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.


    • 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.
      There are otehr web wndowing toolksits, like wingS from www.mercator.de.
      They mimic Swing as well, and generate HTML with a similar API like Swing does.
      angel'o'sphere

  • Millstone (Score:2, Informative)

    by Anonymous Coward
    Another similar framework you might want to take a look is Millstone [millstone.org]. 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 [millstone.org]).

  • The code is not valid! (Score:4, Informative)

    by bertilow ( 218923 ) on Wednesday September 10, 2003 @06:13AM (#6919612) Homepage
    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.
    • "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-use

      • Re:The code is not valid! (Score:1, Insightful)

        by Anonymous Coward

        W3C's for example doesn't care for the following img "src" attribute:
        src="/EchoWebMail/webmail?E_id=E_ls&E_z=107a6_ 0"

        That would be because some characters (<> and &) are only ever supposed to be entered in encoded format (&code;) in an XML or HTML document. Most browsers are pretty loose with those, but it's not technically valid to have an ampersand that's not part of a character reference, (as < or > cannot be valid if not part of a tag)
        src="/EchoWebMail/webmail?E_id=E_

      • 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=107a 6_ 0"

        That's because the address is not correct. When the validator complains, it's most probably right, and your code is most probably wrong. Learn the rules!

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

        All Echo rendered HTML docu

  • Take a look at the Sierra Intranet demo and you can see which shows the developer watches:

    Kramerica Industries
    J. Peterman
    Cromulent Technologies
    Strickland Propane
    Binford Industries

    There's also Fishy Joe's, Interslice and CompuGlobalHyperMegaNet but I don't recognize which shows they come from. Anyone know?

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

    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.
    • 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
  • I'll be waiting for a mod_perl/Mason version. :)
  • That webmail demo was super lame.
    If I wanted to build rich interfaces I would use
    Flash and Cold Fusion or PHP on the backend.

    I don't really consider JavaScript to be "rich".
    Calling a web interface that utilizes JavaScript and
    HTML "rich" is about 3 years out of date.
  • Mozilla Firebird, at least. Javascript seems incompatible. And I was so excited :(
  • netwindows, domapi, bindows are alike but without java implementation. Do you know any others that can be included in this list ?
  • There seem to be more and more client technologies that we're supposed to be able to use to make our web application lifestyle better -
    • Flash
    • Java
    • DHTML

    And there are a ton of languages which are supposed to make our lives better, too -

    • Java
    • Perl
    • PHP
    • Whatever.NET

    And of course we're supposed to run these wonderful things -

    • On our own, secure, happy, well-administered server, behind our firewall
    • On a service providers managed, well-maintained, backed-up server, in some co-lo facility somewhere

    And whe

  • As a Java developer I am always on the look out for a client side GUI framework that is lighter weight than Swing. It is even better if it doesn't require a plugin or explicit download. So, I went to the Echopoint demo site, and I was not impressed. I have seen faster Swing downloads - and I have certainly seen much better JavaScript interfaces. I don't know if the Echopoint site is just slow for some reason (I think it is), but even if that is the case the interface was very clunky. For instance, the Tree

Slashdot Top Deals

The sooner all the animals are extinct, the sooner we'll find their money. - Ed Bluestone

Close