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?

[Anonymous Coward]

...unless you want to store something on the server. Or need to load something from the server that's too big to put into the initial page load.

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?

[Anonymous Coward]

More responsiveness & high load abilities == happier clients

More client side stuff == more memory load on the client, often disproportionate.

which can negate the whole "re-use our old PCs, thin client" thing. I implemented an LDAP browser in DHTML for the day-job a few years back. The drawbacks were

1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.
2) Memory consumption, in the order of 30 MB for the application. There was only a few hundred K of javascript.

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]

I agree, gmail is highly using DHTML, their interface rocks compared to other web-based mail clients, only necessary data is transfered form client to server, and way back.

When sending a mail, you only need a reply from the server telling is the sending was successfull or not, you don't require several kilos of html with a beautiful no-cache metadata, it has no sense.

The drawback is the higher load on the client machine, gmail reduced that by optimizing (and obfuscating) their DHTML (javascript) code.
Maybe amiga geeks won't like it, but with any current (3yrs old is still fine) PC, it's fine ...

I'd like to know if there are any framework for DHTML/Javascript development, or an IDE.

It's really light-weight, doesn't require client plug-in install, saves the server of most load, and this is perhaps why google used this technology for gmail ...

The demos of echo are not working, so is the echo website (probably slashdoted)... I'm not saying echo is too heavy for web-server with thousands of concurrent users ... no I'm not ...

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

Re:Where's the DHTML?

[ckaminski]

I'm going to confess to attempting to wget your lemmings sample so I can learn offline. What you've described is exactly what I want to do for a number of applications I'm working on for my local intranet, and from what I've seen so far, your example is a great place for me to start.

I guess my only problem with it at this moment seems to be the necessary interfaces to the server to retrieve data. I've been partial to attempting to do server access (when required, say, on final save) in an iframe that's invisible to the user, and trapping/reading any error output. My eventual goals were the hope that 1. I could transparently talk to the server without the user being aware of server unavailability, and 2. local information storage (in IE, the Scripting.FileSystemObject if necessary, or document.cookies if at all possible).

Mostly, I've noticed your use of the CGI mechanism to effect certain application features. How to do so using DHTML events across pages? Where's the feature document.location.href="blah.html" and queue an event on the page "newdoc.loadMenuOld()"?

Having a completely disconnected client, something I can distribute in a tarfile to end users that only does large-grained transactions to the server when necessary? Attainable?

Re:Where's the DHTML?

[AKAImBatman]

1. It's not my code.
2. Look at the second link I posted. There's a link to download the source, sans the graphics and sound.
3. Pages communicate via a combination of cookies and parsing the URL parameters.
4. To snag the graphics from the site, download the source code and try something like this:

find . -exec grep level_image {} \; > temp.txt
cat temp.txt | grep gfx | cut -d \' -f 6 > levels/gfx/gfx.txt
cd levels/gfx
wget -i gfx.txt -B [http://whateverthebasurlwas]/levels/gfx/ -nd

Re:Where's the DHTML?

[gregmac]

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.

I decided this a few years ago while working at a company doing ecommerce stuff. Basically our policy was for the site to be usable with NS4, but we never went out of our way to get DHTML stuff to work. One example I can remember is selecting options for a product (ie. size/color) wouldn't dynamically update the prices and images etc in NS4, but would in any other browsers.

Now, I don't think I'd even bother doing that at all. NS4 just has so many problems, and its so out of date.

Re:Where's the DHTML?

[TodLiebeck]

Echo does not make use of partial updates to pages using DHTML after a server roundtrip yet (and I must emphasize the word "yet" here, as this feature is one of the big ideas for 2.0).

In the current version, when Echo is notified of a server-side change to the state of the user interface, it will update the client by refreshing whatever HTML frame has changed. The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to /.'ing. (I've actually pulled the demos at this point, this machine barely has the bandwidth to serve the static web site and downloads at the moment).

That said, there are numerous components that make extensive use of DHTML, mostly found in the EchoPoint toolkit. The immediate example that springs to mind being the pulldown menu component.

With regard to making such extensive use of DHTML as to minimize the load on the server, bear in mind that server load is only one factor (though today, for the underpowered nextapp.com box, is was a very notable factor :)). In most cases a more powerful server is far less expensive than having developers write unmaintainable code. I'm all for making as much use of DHTML as possible, but it must be done behind the scenes of a more practical API.

But I will say DHTML Lemmings is quite extraordinary, that is one of the most impressive uses of DHTML I have seen.

Re:Where's the DHTML?

[AKAImBatman]

Hi Tod! Thanks for replying!

The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to /.'ing.

Actually, I got to it before it was Slashdotted. The page refreshes were fast enough, but not so fast as to be unnoticeable. Even if you manage to make the "flash" the user sees invisible, they'll still notice when their screen scrolls back up to the top. I used to save the scroll position before refresh on an advanced calendar control that I had written back in ~'00. If I were doing the same thing today, I'd definitely write the control in DHTML. (CSS+Javascript to be exact.)

With regard to making such extensive use of DHTML as to minimize the load on the server, bear in mind that server load is only one factor

It's not really the server load that's the factor. (Although it's always nice to get a better bang for your buck.) It's really about bandwidth and perceived performance. Anything above 10K in size is going to produce a noticeable delay in refresh. This may have nothing to do with the server, and everything with the client. Even with high bandwidth connections, the latency introduced into the system can frustrate the user. Most users are used to it at this point, but it doesn't need to be that way.

In addition, DHTML also improves perceived performance. Even if you still have a ~3 second turnaround before the tree control opens up, the user is always going to say that the DHTML one is faster than the page refresh one. The reason is quite simple: The human brain is very smart. It knows when even the slightest thing has changed. Thus the same factors that led to the development of Double Buffering come into play in web applications.

In most cases a more powerful server is far less expensive than having developers write unmaintainable code.

I agree with the more powerful hardware point, but I don't think that CSS and JavaScript have to be unmaintainable. Over the years I've had a very powerful love/hate relationship with JavaScript. But with modern browsers the scale is beginning to tip toward love.

You see, the JavaScript I write these days is fully OO, with every object separated into its own file. I'm always careful about the scope of my variables, and I use explicit cast functions when I'm uncertain about the type. The result is highly maintainable JavaScript that almost feels like writing Java code. The only problems this has led to is that I keep trying to use "int" instead of "var", and I always forget NOT to use "var" in front of function variables. Other than that, a control can be as simple as instantiating a JavaScript object. :-)

I'm all for making as much use of DHTML as possible, but it must be done behind the scenes of a more practical API.

I'm all for what you guys are doing. Well written server APIs are always the way to go. But that doesn't mean that the server APIs can't push DHTML to the client. Especially when all the DHTML is packed into proper libraries.

But I will say DHTML Lemmings is quite extraordinary, that is one of the most impressive uses of DHTML I have seen.

Isn't it though? Now if Microsoft would fix the damn "position: fixed" attribute, we'd be well on our way to producing entire Desktops based around DHTML interfaces! :-)

Re:Where's the DHTML?

[TodLiebeck]

I'm 100% with you on moving toward using more DHTML. Though we don't do it yet, the basic Echo engine is very much capable of pushing partial page updates, as we use a hidden frame for client-server communication. And we can always automatically fall back based on browser type to refreshing entire pages should a particular environment not support or work well with the partial updates.

On the "maintainable JS issue", I can't tell you how many times I've had to rebut arguments of "Echo uses JavaScript, JavaScript is buggy, therefore Echo is a bad idea." Seems a lot of people assume that because they write bad JavaScript that JavaScript is bad. Good OO JS works fine just about everywhere these days. The big problem with JavaScript is that it's so easy to write horrible JavaScript code, and given the opportunity most developers will.

One question, were you seeing pages scroll back to the top after every page refresh? Echo is using the trick you describe of storing scrollbar positions and resetting them after the pages are refreshed. (The demos are off at the moment, and I'm going to leave them that way for a little bit until server load drops off a bit).

Re:Where's the DHTML?

[AKAImBatman]

One question, were you seeing pages scroll back to the top after every page refresh?

Unfortunately, I don't remember if they do and I can't check (for obvious reasons). Personally, that's not a hack I ever liked much. Especially since you have to set the location at the end of the page. This can cause the page to "jump" a little after reloading, making the flash that much harder to eliminate.

I'm looking forward to you guys using more DHTML. :-)

Re:Where's the DHTML?

[jschottm]

Sounds like a nice design. The page the user sees is primarily made up of iframes? And each iframe contains its own method of submitting a change (be it onclick or whatever) and the automagically refreshes itself to see the new information? I've done stuff like that for creating web based HTML generators, but never though of extending it to database functionality.

Re:Where's the DHTML?

[AKAImBatman]

No, there's only one iframe. The field name is passed in the function so that it can be properly identified. Creating iframes all over the place would stress out the browser, possibly resulting in browser crashes.

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]

Yep. I wrote a script that generates client-side find-a-word puzzles, so you can click on the letters to mark them as picked or not, and click on the words in the list to "cross them off" - once its loaded, there is NO need to go back to the server to use the thing. And that was a hack one weekend "just for the fun of it".

And a table viewer that gets 1000 rows at a time from the server in "data:data:data:data" format, parses them out on the client side and showing 25 rows at a time. Only when you go beyond the 1000 rows does it go back to the server for the previous or next batch of 1000.

Not THAT big a deal.

Re:Quote from the article makes no sense

[popeyethesailor]

He *is* saying it is a Page-based model! He is saying there's a better way to do it than doing a page submit/refresh for a validation.

Re:Quote from the article makes no sense

[tomhudson]

All data still has to be validated on the server. I remember one of my friends making ths mistake almost a decade ago.

He was running a server on a Windows box, so I showed him how, by replacing his page with a dummy page I wrote on his box w. notepad, I was able to get a command prompt...

Then I asked him if he'd like me to change the parameters so that, instead of giving me a command prompt, it would run "deltree c:\*.* /y".

Client-side is for presentation of data and user interaction, and preliminary checks only.

Re:Quote from the article makes no sense

[tomhudson]

I used to have it running on the company's server. Maybe I'll put it up on my server this weekend, just for fun. If I do, do you want me to send you an email alert?

Re:Quote from the article makes no sense

[popeyethesailor]

Well if you look at this page here, they do say validation has to be done in both client & server.

The question is what happens in the client after your request has been validated - they believe that a page submit/refresh should not be done, it should be done as it is in thick-client apps. Pop a messagebox, show your errors in a status bar, whatever. That's not a bad idea, really.

Re:Quote from the article makes no sense

[CountBrass]

Not to mention the maintenance headache if you've got more than one kind of client (say a web service that can also be used to submit stuff).

Re:Quote from the article makes no sense

[tomhudson]

Since each one is a stand-alone app, I've zipped one down and emailed it to you in a few minutes (just had to change the email addy in the script-generated source).

Of course, I welcome feeeeeeedddddbbbbaaaaaccccckkkkkkk :-)

PS: I have 6 gmail invites, so if anyone wants ...

Re:Quote from the article makes no sense

[MartinG]

You are missing something.

He means that from the development perspective it's moving away from a page based model.

In other words, the developer using the echo api codes their app much like any "normal" gui app using swing etc.

The fact that its really page based underneath is nicely hidden away.

We have been using the echo framework for over a year now and I can tell you its the nicest way I've found by a long way to develop web applications.

Re:Quote from the article makes no sense

[tomhudson]

Pop a messagebox, show your errors in a status bar, whatever.

Sure, but this is NOT something new. What's the big deal?

Re:Quote from the article makes no sense

[tomhudson]

In other words, the developer using the echo api codes their app much like any "normal" gui app using swing etc.

gaak!. cough cough barf!! Ptww! Gawd, I hope not!

Sorry about that - I'm not anti-java, just anti-swing :-)

Re:Quote from the article makes no sense

[los furtive]

Rather than having to parse the string on the client side, have you thought of using JavaScript Object Notation when returning values from the server...JS treats them as objects right away. It's sorta like XML for JavaScript, and has been a standard part of ECMAScript long enough that all browsers support it just fine.

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.

Re:Quote from the article makes no sense

[TodLiebeck]

What I intended to convey in this statement was the difference between "page-based" and "non-page-based" frameworks. For a better explanation that isn't cut down to a soundbyte, take a look at this developerWorks article:

http://www-106.ibm.com/developerworks/java/library /j-echo1/

Another item worth checking out to better explain how Echo actually works from a technical perspective is to take a look at the "high-level technical overview" on the nextapp.com site:

http://www.nextapp.com/products/echo/doc/hltov/

Best regards
--Tod Liebeck
NextApp, Inc.

Re:Quote from the article makes no sense

[tomhudson]

Thanks for taking the time to reply. I checked out the second link (the first one times out).

It seems to me you're asking the server to do a lot more work than my approach, which pushes almost all the work onto the client machine. Mind you, that's just my opinion. I want the server to just send the data, and the client to burn its cpu cycles to display it appropriately.

Mind you, I also subscribe to the theory that any transaction can be made stateless through proper design, such that it (the requested transaction) can be applied to a database repeatedly w/o causing inconsistencies.

But that's another (though related) matter :-)

Again, thanks for replying.

Re:Quote from the article makes no sense

[MartinG]

well me too, but the api is nowhere near as bad as the implementation. It's the api that echo borrowed from.

Re:Quote from the article makes no sense

[ahdeoz]

That's all fine and dandy when you're running the webserver as Administrator and logged in as Administrator and using the browser on the same box. Your remote users won't get command prompts unless they find an exploit in the webserver.

Re:Quote from the article makes no sense

[tomhudson]

Nope - he was running his cgi with parameters from the page - including the name of the cgi command to execute as one of (the first IIRC) the parameters. Anyone could spoof it and run any command.

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?

[Anonymous Coward]

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

True, but I subscribe so I got a peek when it still worked. The first thing it does is put up a splash screen "Echopoint, Loading..." - I really meant "what's it loading on the splash screen?"

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

[Anonymous Coward]

You can set the control to client side and avoid the event on the server. Read a bit the docs before speaking, thank you.
I'm not affiliated with echo or echopoint.
Just used it and liked in a real world enterprise app.

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

[tomhudson]

You can set the control to client side and avoid the event on the server

Seems to me that's sort of akin to saying "You can disable unnecessary services in Windows and plug those holes". Sane defaults, SVP.

It would have perhaps obviated the so-quick meltdown they had this morning, for one.

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.

Framework for PHP?

[Anonymous Coward]

We need such a framework for PHP. How else can we put 6 calendar "controls" on the same webpage? WACT
seems to be something like this, but I think it needs more support...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

echo rocks

[codepunk]

We used it to build a few apps already and it really reduces development time. The best thing is you can build a entire app and never touch a html tag.

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

Re:"Rich" == "Fat"

[Ruphuz]

Have you tried Flex?

http://www.macromedia.com/software/flex/

Re:"Rich" == "Fat"

[Anonymous Coward]

Oh look... Some craphead is a zaelot and bashing MS. How refreshing.
Idiot.

Re:"Rich" == "Fat"

[TodLiebeck]

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

Just for the record, Echo is a thin-client (web client) solution. The only code being run on the client web browser is JavaScript, there are no applets, activeX controls, or plugins at work.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

Re:Competition

[Gluckies]

Fix your demo before posting it to slashdot ... in the section Layout/Ordered Layout/Demo If I click on the information button right next to "caption" field name, it appears under the comboxes on the right ... It's almost the first thing I did to test look, I hope I'm just a lucky guy ;-) Well anyway XSL stylesheets for formatting and themeing are a good idea, I'm using it too ... But your demo site is so slow ... that I won't give it a try ...

Re:Competition

[jole]

What browser you are using?

Re:Competition

[Gluckies]

IE6.0 exact version is 6.0.2800.1106 ... if it helps ...

Re:Competition

[jole]

This is unfortunately a bug in IE with no good workaround (that we are aware of). This should be correct with other browsers (mozilla, firefox, safari, ...).

Re:Competition

[stormcoder]

IE6.0 exact version is 6.0.2800.1106 ... if it helps ...

You like to live on the edge, don't you?

Re:Competition

[Anonymous Coward]

Your demos don't work in either Firefox or IE unless cookies are enabled? No thanks, I'm not gonna tell my app's users to change their browser settings just to accomodate me. Bad practice.

Re:Competition

[jole]

Yes, cookies are currently required for storing the session.

"Rich" != "Fat"

[tezza]

At my work they run Outlook Web Client. DHTML driven.

Features include: cut'n'paste OLE style stuff, full RTF editor, collapsable folders, alerts, the lot.

And all the Web designers running Mac Os X can access it 95%. They give the web client a big thumbs up.

It runs fine over my VPN to home.

So there is "rich" as in functionality. "Thin" vs. "Fat" came from having to do a local install. To access the Outlook web client, all you need is a browser, and not even IE.
Really it's pretty sensational, go check it out for yourself, I'm not quite sure why M$ don't promote it more.

Re:"Rich" != "Fat"

[Anonymous Coward]

1. At my work they run Outlook Web Client. DHTML driven.

OWA (Outlook Web Access) is not very impressive and has some odd bugs.

what's the point?

[Anonymous Coward]

I just don't get it... all of this talk about DHTML makes no sense. I can write a series of static html files filled with all kinds of nasty JavaScript that allows my "application" to execute without a server and with what comes close to being a "rich client" experience... but what is the point? All I have is a nasty mess of tangled script code that is nearly impossible to maintain. None of these approaches (DHTML, hidden IFrames, Echo, etc.) will ever match the rich client program paradigm in user experience or maintainability. They will all always simply be scripting workarounds.

Re:what's the point?

[Gluckies]

Do you really think google would use DHTML for gmail if it was a "scripting workaround", or a "a nasty mess of tangled script code that is nearly impossible to maintain". Even perl code can be made so that you can maintain it (slashdot pages are perl), so if perl can, everything can ... even some javascript code...

Re:what's the point?

[Anonymous Coward]

Javascript can be quite maintainable if you code with that goal in mind. You can write nice capsulated object oriented programs if you want. MVC and other recipes apply just fine. It does take a little more discipline because the language is very forgiving in the type department, but if you know what you're doing, you get perfectly maintainable access to a very powerful layout engine.

Re:what's the point?

[stormcoder]

You can turn anything into a mess of spagetti code, even Python. DHTML doesn't have to be a mess. You just keep a seperation of concerns and you should be good to go. If you think that maintaining a heavy client is easier than a thin client, you haven't had to deal with rollouts to thousands of desktops before. If you want something easy to maintain you go with a thin client. You only use a heavy client if some functionality is not available in a thin client and this is becoming more true as time goes on.

Re:what's the point?

[ahdeoz]

Two things: 1) Server side communication is here to stay. You can't take the internet away. 2) HTML is the best format for design and display. It really is. You get a better design most of the time. It's alot more flexible than forms, and alot quicker, and alot easier to customize. 99% of this is due to , , and tags. If you ask an HTML designer, he'll cry about css and absolute or relative positioning but he's wrong. What widgets HTML lacks should be added, not bastardized in 10 of 299 XUL/XAML languages. DHTML can simulate trees, pickers, etc. passably, but leaving them out is a much better option most of the time in favor of a free networked client with HTML table positioning, images, and links.

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/

Re:Take a look at Zope

[Anonymous Coward]

Before committing serious resources into Zope development, please do a smaller test project which touches some of the critical points of your actual application, especially integration and speed requirements - my current project almost failed (which would have resulted in more than one termination) because we started out with Zope and Plone.

since its last slashdotting

[InsomniaCity]

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^W^W^WSlashdotting

Gone already... and this was only a slashback!

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?

Re:Agnostic Widgets

[LetterJ]

I didn't follow up on my original intent on that post. The project in the article is specific to Java, etc. Richer client widgets with simple declaritive syntax like HTC provides would make generating those interfaces easy in ANY language. The client and server can be agnostic to how the other is implemented.

After all, for as much as people try to dress it up, building stuff on the web is basically text requests (http get and post) and data response (html and other files). If you funnel everything through HTTP and HTML, it shouldn't matter what's on each end.

Re:I'm sure someone will post

[Anonymous Coward]

Yeah, unemployment is great!

Hooray for the SPD!
Hooray for Hartz IV!

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?

Re:Echo looks cool, but...

[ahdeoz]

which XUL? That's the rub. And the whole point of webapps is the standard client with the HTML layout. I've written XUL apps and shipped mozilla with them, but I end up using just a couple widgets on top of HTML. Expand the HTML widget set!

Re:Echo looks cool, but...

[mewphobia]

It's comparing apples to oranges in that Echo is a API built on top of the base language (html) where as XUL is just the base language. XUL really needs a set of librarys on top of it to add calendar/date functionality for example.

My advice (as someone who has only briefly looked at Echo but developed 2 fully fledged XUL apps) is that if you want to develop a rich web app now, use echo or something similar. It has more browser support, and the clear APIs will stop endless frustration/banding your head against the wall. If you want to support opensource or learn a bit more about the future of the internet, XUL is a good way to go. XUL will get heaps better when it hits version 2, but at the moment everyone is focusing on core firefox development.

It would actually be really interesting if someone made and xlt script to convert XUL to Echo. It would kind of be like MS's embrace and extend but the other way around.
Sure you can use internet explorer to access my side (it will come through as echo) but if you use mozilla it looks and feels HEAPS better (as XUL).

It's a packet network

[mengel]

...so the interaction you describe (event -> server, update->client) requires at least two network packets. So sending the tree updates versus sending the whole tree is a really nominal savings -- maybe 30 bytes of a 1k frame.

So making the + sign in the tree listing an html link which yeilds a new page with the tree unfolded really doesn't cost you much different in performance, and it requires much less smarts and compatability on the browser side.

Now on the other hand, if you're text-editing a 10k document, and resending it on every edit action, that would suck...

Anyhow, my point is that the example you give doesn't show the savings well.

Re:It's a packet network

[AKAImBatman]

All you need to do is scale it a bit. What if the tree had 500 items at the top level? Then the savings would be extreme.

In the real world, however, the savings would be immediate even with the exact example I gave. The reason is that most pages contain sidebars, titles, helpful text, and other controls. All of that data adds up, and can often be 10K or larger. In the DHTML web application I'm working on, pages are regularly 70K+. Yet since only minor parts of the page change, the savings are significant.

Another rich web app development tool

[Richard W.M. Jones]

Monolith, which has been around for considerably longer than Echo, is looking for a new maintainer.

It allows you to create object-oriented web apps in C which compile into tiny servers (and I mean tiny - the web server fits into the L1 cache on most computers). But they come with all the usual features like a templating system, database access and so on.

Rich.

Audiolunchbox selection

[Anonymous Coward]

Maybe they have 500,000 tracks to download - unfortunately when I looked up their "Death Metal" category they had a whopping two albums in there.

rich web app frameworks tools...

[Anonymous Coward]

But nerds are my mortal enemies.

-Homer J. Simpson

Get rid of roundtrips... FLA** me!

[Seraphnote]

You got to love the people in the IT industry... Let's see... Linux friendly... Web based... No roundtrips to the server for EVERY refresh of a control... Can make "rich applications" and "rich user interfaces" and "rich whatever"... Is object-oriented... Not dependant upon M$ or .NET... Try Flash! And Flash Remoting! (...OH, but its NOT open-source... go ahead change the SH to an ME and FLA** me!)

They lost the browser war - not quite

[Rob Y.]

...they killed Netscape, but the goal was to prevent applications from moving from Windows to the Web.

Well, sort of. Actually IE-specific Web applications are just fine as far as Microsoft is concerned. Especially ones that use .Net features that are unlikely to be replicated in portable browsers.

Microsoft doesn't care which Windows-only technology people use as long as it's Windows-only.

And by the way, it is possible to build new technologies that are as thin as the Web model, but that provide a much 'richer' experience. HTML wasn't designed for that purpose, but that doesn't mean other thin-client technologies can't be. I've built one myself - it wasn't that hard. Let's hope we get there before Microsoft does.

MODERATORS ARE IDIOTS - RTFS

[Anonymous Coward]

The idiot moderators should notice this is a multi-topic "slashback" article.

If you RTFS you'd see:

TodLiebeck writes "The Echo framework,...."

shimmerkid writes "After seeing almost nothing about audiolunchbox.com...."

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

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.

-

Re:Drug Policy

[Anonymous Coward]

I'm not a right-winger by any means, but I still have to laugh at pot-heads.

The same people who would (rightly) want to prosecute tobacco companies for selling a product that causes cancer willingly buy illegal smoke-age. The fear of cancer is medicated by a relaxing sense of stupidness and general hunger for potato chips.

Re:Drug Policy

[Anonymous Coward]

So you'd go with what, the 5th option? Outlaw alcohol?

Mod Parent Up

[PCM2]

Despite his trollish past, he seems to be serious. I've never heard of Bindows.

Re: Borders, family values.

[aggiefalcon01]

And I like how no question about securing the national borders (which neither major candidate has talked about) made it through the /. filter.

And, of course, the question relating to traditional family values went down in flames. Apparently, ya just can't have that shit here on /.

Echo is quite poor (read slow)

[tahpot]

If you really want to see the power of DHTML have a look at a demo framework I have created http://tahpot.homeip.net/wp_blog/index.php?p=6

In reality there is nothing stopping the development of web applications that replicate the usability of traditional desktop applications, but have the power of large connected databases.

If you want to look at some good resources checkout:
www.bindows.com
www.netwindows.org

The power of web applications was hinted at in the first dot com era, but it is actually a viable reality now. Using Javascript to load data directly from the server (XmlHttpRequest()) there is no need for page refreshes to provide the functionality of a web application. Data can be loaded from the server and sent to the client, maintaining state.

For those interested in the capabilities of these new DHTML application please contact me, I am in the process of instigating some projects to assist the development of these applications.