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."
Yes, there are other ways to do it. Why do you feel threatened by another one?
+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 system? That'll show you pain. How about webmail on any mailbox with more than about 20 messages (no, I'm not talking about deleting all the spam, I'm talking about finding your expense claim or that document you were sent five weeks ago)?
Except for all but the simplest of tasks, I really can't see the 'browser based' model as a good solution. That said, when you're in marketing, everything is a simple task. "Sell a product", "provision a mobile phone", "roll out a new server". See how easy it is, it's only a few words!
/* affect != effect */ void affect(int *thing,int effect) { *thing += effect; }
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.
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 HTML code isn't even valid!
t eraction.html
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/in
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)_ 0"
is how it should be in the html.
src="/EchoWebMail/webmail?E_id=E_ls&E_z=107a6