Slashback: Echo, Lunchbox, Questions

TodLiebeck writes "The Echo framework, which is used for creating web applications that approach the functionality of rich clients, has received some significant updates since its last showing on Slashdot. The community-developed EchoPoint component library has hit v1.0 and now provides more than 50 components such as a chart container and a rich text editor. The recently released version 1.1 of Echo is now available under the Mozilla Public License (in addition to the LGPL). More information can be found in these two announcements on TheServerSide, and this recent article in the SDTimes." shimmerkid writes "After seeing almost nothing about audiolunchbox.com in your recent story about the perfect online music store, I felt a little vindicated when I received an email newsletter from them claiming they have become the "largest independent digital music store in the world." They have added Beggars/Matador and Kill Rock Stars among others, promising a total of 500,000 tracks (at 99 cents a track for unrestricted 192 kbps MP3 and Ogg) by December, and over a million tracks in 2005. The best part is that they pay the artists 65 cents a track."

Noksagt writes "The 50 questions for Bush and Kerry that were moderated and commented on in a previous /. story have been pared down to 20.

Vote for 10 of them at The New Voters Project Presidential Youth Debate. You don't even need /. mod points--just a valid email address!"

Comments

Where's the DHTML?

[AKAImBatman]

Is it just me or do all the pages refresh every time you do anything? I've been doing some internal applications in DHTML lately and have learned the amount of stuff DHTML can do (even if you avoid some of the more browser specific stuff). There's little reason to refresh the page for every event.

If you want to see what DHTML can *really* do. Look no further than DHTML Lemmings. It's an entirely self-contained application that can run on your local hard drive without the support of a server. The current level is cookied so that you don't have to start over when you close your browser. All parameter handling is done by parsing the URL with Javascript. In other words, there is ZERO need for a server.

Less need for a server translates to less strain on the server. Less strain on the server means that your applications will perform faster for both the client and your company.

Re:Where's the DHTML?

[AKAImBatman]

Less need for a server != you must give up the server. In the DHTML I'm working on, I'm able to send individual field to the database without refreshing the page or doing a form submit. You see, there's a hidden iFrame that's designed to communicate one field at a time. If an error occurs upon submit, the returned version of the communications page embeds an alert popup to tell the user what the error was. After the user clicks on "ok". the field is reverted back to its previous form.

Other implementations could mark the field in red and force focus until the user fixes it or hits escape. You could even embed some text in red all by changing the document via DHTML. The total amount of data that travels between the client and server? Less than a kilobyte!

Less data == less bandwidth & processing
Less bandwith & processing == more responsiveness & high load abilities
More responsiveness & high load abilities == happier clients

Re:Where's the DHTML?

[AKAImBatman]

More client side stuff == more memory load on the client, often disproportionate. [...] in the order of 30 MB for the application. There was only a few hundred K of javascript.

True. But I'm doing DHTML on a 256MB machine. It's plenty fast enough. You always have to pay attention to whether DHTML will help your application or hurt it. If you need a very high level of interaction, and/or find yourself having to pump large amounts of uneeded data to the client (e.g. a combo box with ~10,000 rows), then DHTML makes sense. Otherwise, plain old HTML may actually be faster and more client friendly.

1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.

Time to give that up. I don't know about anyone else, but none of the sites I run support Netscape 4 anymore. It's not only 10 years old, but it's been replaced by several newer versions of Netscape, all of which function just fine with DHTML.

Anyone who's still using Netscape 4 either has a VERY old computer, or needs their head checked.

Re:Where's the DHTML?

[tezza]

Check out Pushlets. It's along the hidden iFrame idea that you mentioned.

It allows the server to communicate back to the remote app.

Nice lemmings post BTW.

Re:Where's the DHTML?

[John Betonschaar]

I don't think this is possible, because the ECHO framework is heavily dependent on server-side state information. You really have to look at it as a more or less 'normal' Java application that happens to use HTML to display its user interface. You even write Echo applications much like normal Java applications.

What you propose would be the equivalent of a Java application that woul maintain all of its state information in UI elements, with everything running client-side.

The way Echo works it is not possible to do any processing client-side using Javascript/DHTML, since that would require transferring state information to and from the server on every action or event, ie: reloading all frames. This actually happens to be the way this all works, as you already figured out, but without DHTML (since there's no need for or advantage to it).

Your sig is mine

Re:Where's the DHTML?

[Anonymous Coward]

(Actually, I apologise - the DHTML app only took 15-20 MB. 30 MB was a Perl misadventure specced by someone else.)

True. But I'm doing DHTML on a 256MB machine.

Glad to hear it. Every once in a while we still get asked to do projects for sub-standard kit, though, e.g. we did one last year Win 95 with 32 MB (!) - I think it had end users across Africa or something.

I don't know about anyone else, but none of the sites I run support Netscape 4 anymore.

Yeah, it was a few years ago. Even then, Netscape 4 was basically dead but it was the customer calling the requirements :-( Even today we frequently get asked to test our stuff with IE 5, and every once in a while with IE 4. *sigh*

Re:Where's the DHTML?

[AKAImBatman]

I don't think this is possible, because the ECHO framework is heavily dependent on server-side state information [...] but without DHTML (since there's no need for or advantage to it).

Believe it or not, DHTML can still improve this situation. Let's take the tree control as an example. Right now the current state of the tree is pushed to the client. When the client modifies the tree, it gets refreshed. But why?

Let's say we have a tree that looks like this:

+ ABC
+ 123
+ This is a test

Using DHTML, the server only needs to push three rows to the client. Now let's say the client has a hidden iframe with the following HTML:

<input type="hidden" name="command">
<input type="hidden" name="field">

So what happens with DHTML if I click on "ABC"? Simple! The Javascript sets "command" to "expand" and "field" to "tree_abc" (or whatever the element is called), then submits the form. The server reads in the request and passes back Javascript that modifies the innerHTML of the ABC element along with the same input fields as above.

once the innerHTML is modified, the tree now looks like this:

-ABC
* Ardvark
+ Animal
* Aligator
* Algae
+ 123
+ This is a test

The end result is that the server knows that the tree was expanded, and only the data absolutely necessary was transmitted. The savings are anywhere from tens to hundreds of K per action, and the user notices that the application is much faster. The screen doesn't even flash when he clicks!

So yes, DHTML could greatly improve this framework.

Re:Where's the DHTML?

[los furtive]

While DHTML Lemmings is a great example of the powers of DHTML, it is a poor example to contrast against a web application since it never needs to read/write from a db, nor communicate with a server.

I do agree with your point though, although I haven't tried out Echo yet, the use of RPC via iframe, xml or whatever should help avoid reloading the page, and also decrease the effort required to maintain the state of the page (when done properly).

Personally I've been using for this very purpose (and their excellent listgrid component) and have been very satisfied with it.

Re:Where's the DHTML?

[los furtive]

Crap, should have previewed ... that last paragraph should read:

Personally I've been using domapi for this very purpose (and their excellent listgrid component) and have been very satisfied with it.

Re:Where's the DHTML?

[AKAImBatman]

While DHTML Lemmings is a great example of the powers of DHTML, it is a poor example to contrast against a web application since it never needs to read/write from a db, nor communicate with a server.

While this is true, there are (unfortunately) very few public applications that make good use of DHTML. The only one that comes to mind is the example of GMail. DHTML greatly improves the user experience in that case and decreases their server load.

Also, I gave a real-world example of DHTML here.

That DOMAPI you mentioned looks very interesting. I'll have to check it out sometime. :-)

Quote from the article makes no sense

[tomhudson]

"We're moving away from the page-based perspective of Web app development, which is great for viewing documents," Liebeck said. "When you start getting into apps, with forms and validation, the page-based model breaks down." He cited as an example an application that, if the user's entries into a form are correct, will take you to the next screen, but must return a new window and highlight the incorrect fields if the entries are in error

Maybe I'm missing something, but the example Liebeck gives contradicts his statement - it IS a page-based model, and one of the oldest ones, at that.

If he wants a REAL example of something that acts more like a program, he should get a gmail account and see how interactive THAT is.

Re:Quote from the article makes no sense

[tomhudson]

I return them as an array, with each array element set up in "data:data:data:data" format.

Quickly served by the server (1000 records actually as quick as serving 25 records formatted by the server).

Then it's just a matter of doing a split betwen the colons, and some javascript to manipulate the page to change the values based on whether the user clicks next or previous..

I chose this as opposed to, for example, name=value, because that's more verbose, hence more time to send. I want speed and ease of coding above all else.

So what is sent from the server resembles this:

the page header
the javascript include file
the css include file
data[0]="Last Name:First Name:Area Code:Phone Number";
data[1]="Flintstone:Fred:555:234-1286";
data[2]="Rubble:Barney:555:234-1299";
...
data[ 1000]="Munster:Herman:555:666-6666";
...
a body tag containing the appropriate onload method to fill in the page.
buttons with "first", "back", "next", and "last", and references to the appropriate onclick handlers.

data[0] contains the table row headers, which I repeat every 5-10 items, to make the table more readable, in addition to only showing 25 rows at a time. It only takes a fraction of a second to show the next/previous set of 25 rows.

This is much more compact than xml, so it's handled quicker all around. It's also VERY human-readable, even as raw data, and very easy to manipulate via php and perl, as well as c.

Echo: what's with all the server round trips?

[Anonymous Coward]

I picked a couple of controls from the Echopoint demo to look at:

1. It takes ages to load. So what's it doing? Caching JavaScript?
2. The DatePicker and DateFinder controls require a server round-trip to change the month you're looking at! That's way behind the times. So what happened to whatever it was loading for 1?
3. The tree control seems to default to 'not client side'. That's wrong - it should autodetect.

Now maybe this is all some protest against me because I'm using IE and it all works client-side by default in Mozilla - but that wouldn't be very professional.

Re:Echo: what's with all the server round trips?

[tomhudson]

I picked a couple of controls from the Echopoint demo to look at:

It takes ages to load. So what's it doing? Caching JavaScript?

It's currently doing a live demo of a server melting under the /. effect.

"The operation timed out while attempting to contact my-server-is-SO-hosed-and-so-is-my-demo.nextapp.co m"

Re:Echo: what's with all the server round trips?

[TodLiebeck]

I picked a couple of controls from the Echopoint demo to look at:

1. It takes ages to load. So what's it doing? Caching JavaScript?

The Slashdot effect has killed our server. Demos have since been temporarily pulled.

2. The DatePicker and DateFinder controls require a server round-trip to change the month you're looking at! That's way behind the times. So what happened to whatever it was loading for 1?

The DatePicker/DateFinder are very old controls. They've since been replaced by the ClientDatePicker in EchoPoint (and there's also a similar component in the commercial Sierra tool).

3. The tree control seems to default to 'not client side'. That's wrong - it should autodetect.

The EchoPoint demo in question is just a demonstration of various components of EchoPoint. The developer would decide whether s/he wanted to use a client- or server-side tree; this feature would never be configurable by the user of an application.

Comment removed

[account_deleted]

Comment removed based on user account deletion

"Rich" == "Fat"

[IGnatius T Foobar]

"Rich client" is Microsoft-speak for "fat client." Don't let them define the rules of the game. They lost the browser war (yes, really, they did: they killed Netscape, but the goal was to prevent applications from moving from Windows to the Web, and at that they failed miserably) and now they're trying to take it back by relabeling the bloatedness of the conventional desktop as "rich."

Sorry, I'm not buying it. There is no "rich." There is only "fat" (runs locally) and "thin" (runs remotely).

Competition

[jole]

Echo has a wonderful model of writing web user interfaces. My company IT Mill Ltd is the author of an Open Source lisenced (LGPL) Millstone User Interface Library that is very similar (in model) to Echo. In my (biased of course) opinion Millstone provides developers with better UI components and more flexibility.

Main difference is that Millstone UI components are not dependant on Web, but has been (as prototypes) shown to work also in Swing. When doing Web-development, Millstone provides flexibility of using XSL stylesheets (in addition to CSS) for themeing, which makes customization of Millstone UI easy and flexible.

See the the online demo. If you have any questions, please join our just opened discussion forum.

BTW: In addition of being an Open Source project, commercial support is provided (by us) and currently Millstone is used (has been for 3 years) in very large commercial applications.

Take a look at Zope

[Colin Smith]

If you're looking at Echo, you should also have a look at Zope as well. It's a lovely development environment, I can throw business stuff together in hours which would take days/weeks in VB and Java. Brilliant for RSI sufferers. All that forgotten stuff which used to end up as a VB app accessing an Access database installed on every desktop machine now doesn't.

http://www.zope.org/

Agnostic Widgets

[LetterJ]

There are already several comments about how many round trips this uses even for changes in widgets, something I don't think should take a form post to do.

I've been working with HTML Components/Behaviors to build elaborate interface widgets for my current project. By rolling up a bunch of code, complete widgets like drop down menu's can be put into place with a single tag.

I'd avoided them in the past because they were IE only, but http://dean.edwards.name/my/behaviors/ (the same guy who did the IE7 compatibility stuff) has made it so the same component can work on Mozilla as well. As such, I've been looking for widget sets that can be used to build richer components.

For example, I've got an HTML behavior for text boxes that adds an attribute of "validationrule". That behavior invokes the appropriate rule when the text box's onchange event is fired and warns the user (by invoking my "message" component's display_message() method) if the contents don't validate according to the rule.

Does anyone know of a resource for things like this? Richer client side widgets, possibly implemented as HTC/RBL components?

Echo looks cool, but...

[WhiskerTheMad]

What about XUL? I took a brief look at it a few months back, and it looked pretty good-- but I decided to wait until they had a developer GUI ('cause I'm a lazy bastard :) How does echo stack up to XUL, or would that be comparing apples to oranges?

Drug Policy

[Alsee]

Damnit!
There were three questions on drug policy, and for some reason they cut the best one and left the other two. Specifically it was the one pointing out the indisputable fact that alcohol is vastly more harmful and deadly than marijuana, so why the hell is alchol legal while marijuana is illegal?

It's a real bitch of a question for a polititian to directly confront, and I really wanted to see how they each handled it. The only options are to come out for legalization, to blatantly lie, to blatantly weasle out of the question, or blatant hypocrisy.

Well, I guess there's one other option, to come out for prohibition of alcohol. Chuckle.

-