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."
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.
Great Atrocit
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 or some other XML-RPC-based solution.
Oooh! But it's web-based! Fscking marketroids.
It's always a long day... 86400 doesn't fit into a short.
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...
Now all web applications can replicate the ease of use, visual appeal and speed of Mozilla's browser-rendered UI!
the web browser has set back application development 20 years.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!!!
That is all.
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
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
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Love it.
;). I've been thinking about siggifying it, but haven't gotten around to being witty.
That's a pet peeve of mine too (you know you're anal when you have a pet peeve about language usage
Kudos to you, sir!
JAVASCRIPT: Error: Client model not available.
All back to the mine.
The term "Echo" is an unfortunate choice of name -- it conflicts with another, new project 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 "Carnage4Life" here on Slashdot) and Evan Williams, IIRC. The syndication Echo apparently grew out of the blogging API's (see bottom of page).
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
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!!
-- these are only opinions and they might not be mine.
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.
_that_ would be cool!
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 echo project contains the base functionality of widgets. this provides a very clean base from which customization is made trivial.
echopoint, a derivative project, does provide things like wizardpanes, tabbedpanes, trees (just like swing).
it's worth a look, and echopoint poker is good enough to kill a few hours...
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: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!
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).
I would certainly like to find a workable solution such as this. However, the video poker is so slow as to be useless. People don't like waiting for a computer to respond. They want the computer to serve them, and wait for them.
Is there any way to speed the response? I'm using Mozilla 1.4.
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.
Tod,
Thanks for the reply. I will check into this.
Thought: I think it is unfortunate that this issue was not addressed before the story appeared on Slashdot. All the slow Java programs are destructive to the acceptance of Java, for example.
Customers have experience with their computers responding instantaneously when they work with a program on their hard drives. They want no less service from other technology. I find that it would be politically impossible to deliver an application that took any time to respond. Customers do not expect that the function finish immediately, just that the menu respond immediately. Perhaps this demonstration of poker should have been on my intranet, rather than from Texas.
Even when software is free, there is a marketing component. We want as much support as possible for good technology, and that support can only be gained through skilled communication. The skills required are identical to the skills required to design marketing.
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?
> you haven't seen all the demos if you haven't seen trees and such
I've seen enough to not be impressed.
> echopoint poker is good enough to kill a few hours
I DID specifically see that one. Refreshing the entire page when dealing? Ugh! That's NOT a rich GUI client.
If you want to see a rich GUI, look at XUL and Mozilla. Now there you can have serious rich GUI distributed apps. For a lot of people an HTML page simply doesn't qualify as a rich interface, regardless of how fancy the backend is. You're still dealing with HTML tables that keep jerking around while the page loads.
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.
I'll be waiting for a mod_perl/Mason version. :)
Renders my browser's Back button useless....
Thanks.
That is all.
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 ?
- 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 -And when we do manage to get all of these crazy things to try to talk to eachother, somehow, we can choose among 5,000,000 different XML languages/schemas/whatevers to use.
Web-based computing is still in the stone age - if I can ever manage to get my own stupid project off the ground, perhaps I'll have a solution for this, soon enough...
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 View widgets update by refreshing the page, as do the rest of the widgets I tried (a limited set). Compare the "expanding" widgets to something I threw together: http://mywebpages.comcast.net/developer.dude/urls. html
Developers should look at UI frameworks from the user's perspective; users want a smooth fast UI that works on the browser they are using, without having to download a plugin.
I haven't looked at the Echo framework from the developer's POV because I can see within just a few minutes of trying out the demo that the user isn't going to like it.
Maybe I am just being lazy, or maybe the Echopoint demos are just poor ones.
Please, have a modicum of consideration for people who would read your post; otherwise, you are saying that you don't care enough about what you've said to make it legible. If you don't care enough about the writing of the post, I don't see why I should care enough to read it.
And yes, I know that this post is better than some that end up here - "one" in place of "won" is the worst reading speedbump I've seen lately - but it's still painful on the reader.
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 to any other kind. It's easy to make one look like a native app with creative use of stylesheets (served according to client platform); those who ask "what's the point of that?" are too hung up on the "web" bit, and not taking sufficient notice of the "application".
Somebody once said, "There is no website so simple that a graphic designer can't completely f*ck it up for you". That goes triple for web applications.
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
(Remote) XUL has similar capabilities. Check out http://www.xulplanet.com/ and http://robin.sourceforge.net/