"The survey said most motorists who used either resource while driving would take their eyes off the road for 10 seconds, which at 60 miles an hour would equate to traveling twice the length of a football field."
This pretty much makes me not believe what these people have to say. I cannot believe that it is possible to repeatedly drive blind for 10 seconds at 60mph without incident.
Personally don't like all the try/catching in that example code and think this is a heck of a lot cleaner. This is not cut-and-paste code to create an XHR, but rather just a snippet of code from Echo2 (which absolutely requires an AJAX capable browser of one form or another). Works in FF, Moz, Safari, IE6+, KHTML, Opera, etc. YMMV.
var usingActiveXObject = false; if (window.XMLHttpRequest) {
this.xmlHttpRequest = new XMLHttpRequest(); } else if (window.ActiveXObject) {
usingActiveXObject = true;
this.xmlHttpRequest = new ActiveXObject("Microsoft.XMLHTTP"); } else {
throw "Connect failed: Cannot create XMLHttpRequest."; }
Actually, Firefox seems a lot worse in this regard. Throw something fun at it like a 10MB table, and it will take 10x longer than IE to load, and afterward you can barely pull down a menu.
The "worst bug ever" tended to appear not as a result of large DOMs, but of complex DOMS, i.e., a combination of lots of nested elements, CSS positiong, and interactivity. My primary complaint with IE here is that this was not really all that extreme of a case, and all other browsers were not even "breaking a sweat" to render it.
IMO, document.addEventListener() is more important than any of those. Many of your issues can be worked around, and some of them can be worked around rather trivially. However, there is no way in IE to match the functionality of addEventListener, with any amount of hacking.
Definitely agree that all my listed issues can be worked around, but I wouldn't go as far as to say it's trivial to do so. Here are the current workarounds I use in IE for these problems:
Implement document.importNode() Workaround: Create your own importNode implementation.
Support setting of opposite side CSS positioning properties at the same time, i.e., setting "left" and "right or "top" and "bottom" properties on same element. Workaround: Use IE's proprietary "CSS expressions feature" to dynamically calculate width/height of elements (just make sure you account for padding).
Fix this problem: http://support.microsoft.com/default.aspx?scid=kb; en-us;177378 Documenting a design flaw does not make it any less of a design flaw. Workaround: render IFRAMEs behind z-indexed DIVs that must obscure select field elements. Unfortunately this does not work in combination with PNG transparency (using DXImageTransform.Microsoft.AlphaImageLoader hack of course).
Fix other problems with SELECT element, e.g., the fact that it is not possible to add a ListBox-style select to a document using DOM manipulation. Workaround: Create your own DHTML listbox implementation.
Fix bug where the presence of a vertical scrollbar adjacent to a 100% wide table inside of a CSS positioned element results in a horizontal scrollbar due to incorrect width calculations. Workaround: Limit tables to 95% wide when rendering IE (dirty hack IMHO).
Fix issue where 100% wide textareas expand to be a bit wider (creating a horizontal scrollbar) once text is entered. This also only occurs if the text area resides in a CSS positioned DIV. Workaround: Don't use percent widths on textareas.
Correctly monitor the DOM for updates and repaint appropriately. Currently there are cases where IE will not repaint the screen even though the DOM has changed, requiring the developer to perform additional DOM manipulations just to trigger a repaint. Workaround: "Tickle" properties of other elements in DOM that are known to cause update, i.e., set value to something different, then set it back. This problem shows up very rarely but can be very annoying when it does. This solution is even uglier than the problem.
Fix this completely insane bug (scroll down to a few paragraphs or search for the text "worst bug ever in Internet Explorer 6." Workaround: Fix described in blog entry.
And last but definitely not least, simply bring the performance up to a level relative to Firefox/Opera/Konqueror/Safari, especially when dealing with reasonably complex and interactive DOMs. Workaround: Keep your DOM as simple as possible (which is obviously a good idea anyway, but nevertheless can sometimes prevent the development of certain AJAX components from being practical.
Just curious if you happen to know of better/simpler workarounds for any of the above? (Please note, this is not a rhetorical question/argumentative response, I'm genuinely curious if you've come across something better, as I'd be extremely happy to find better solutions for any of the above!)
And I do agree on the signifance of not supporting the proper W3C events, at this point I'm simply resolved that event capturing is only a figment of my imagination.
What IE really needs right now, if it wants to be taken seriously as a platform for AJAX web applications, is proper DOM/CSS support. The following would be a good start (my current peeve list with IE6):
Implement document.importNode()
Support setting of opposite side CSS positioning properties at the same time, i.e., setting "left" and "right or "top" and "bottom" properties on same element.
Fix other problems with SELECT element, e.g., the fact that it is not possible to add a ListBox-style select to a document using DOM manipulation.
Fix bug where the presence of a vertical scrollbar adjacent to a 100% wide table inside of a CSS positioned element results in a horizontal scrollbar due to incorrect width calculations.
Fix issue where 100% wide textareas expand to be a bit wider (creating a horizontal scrollbar) once text is entered. This also only occurs if the text area resides in a CSS positioned DIV.
Correctly monitor the DOM for updates and repaint appropriately. Currently there are cases where IE will not repaint the screen even though the DOM has changed, requiring the developer to perform additional DOM manipulations just to trigger a repaint.
Fix this completely insane bug (scroll down to a few paragraphs or search for the text "worst bug ever in Internet Explorer 6."
And last but definitely not least, simply bring the performance up to a level relative to Firefox/Opera/Konqueror/Safari, especially when dealing with reasonably complex and interactive DOMs.
I've posted this on ieblog before. I sincerely hope that somehow someone on the IE team sees one my numerous implementations of the above list of rants and implements solutions for them. It'll make the professional lives of many AJAX developers quite a bit more pleasant.
So? When 90% of your "customers" are being told that they either turn off Javascript or get a virus, it doesn't matter whether the problem is with Javascript or IE - either way, there is no return for adding AJAX features to a web site. I'd rather spend my precious development resources on non-AJAX features that benefit everybody.
Disclaimer: I'm a bit biased on this one (e.g., see my homepage URL).
JavaScript isn't going to go away over security flaws in the IE implementation. People continue to use Internet Explorer, Outlook, and other programs with sordid security track records. I can certainly see the current AJAX frenzy causing a good deal of attention toward JS security, but the industry's answer won't be to simply give up.
GM and Ford are not in a position at present to offer additional incentives to their employees unless they will have a direct impact on their bottom lines. This is likely to remain the case for the next several years.
Onstar is easy to disable (pull a fuse) and doing so has no ill effects as far as I can tell from first-hand experience. Once the fuse was reinstalled the system continued to function as before. A description of which fuse must be pulled can be found here:
The one thing that has always bothered me about such "forensic analysis" in computer crime investigation is the fact that it is fairly trivial for a competent developer-type person to artificially create this information and tell any story s/he wants. If someone wanted to frame a person for a computer crime they could even develop a trivial piece of malware that would actually visit target sites from a person's computer over time, such that even the ISP's and target host's logs would confirm the user's activity. Such a program could be configured to activate only when a user was at a computer. The only technical challenge to creating such a piece of software would be finding a means to install it, but it's common knowledge that there are a great variety of means (both social and technical) to accomplish this step.
It would be my guess that it would be fairly difficult to convince a jury that the real criminal was an "evil program" running behind the scenes. The only real hope for a defendant in such a scenario would be to find some flaw in the malware program to suggest its existence (for example, if it activated when the defendant was out of town and his/her spouse was using the machine).
It concerns me that somewhere, someday, someone might go to prison as a result of the forensic analysis of his/her computer when in fact the criminal act was committed by a third party solely for the purpose of landing his/her victim in prison.
It was a while back. I think it was about 2 years ago, but it could have been a bit more. Anyway, I ran into UI glitches and bugs all over the place, just trying to deal with the demos. I recognize that you have a difficult job dealing with browser stupidity, but the end result is what I care about.
Were you using components other than those included in the stock Echo distribution, and was the stock distribution a final version? Were any add-on components you were using from beta versions of component libraries? Did you seek any help from the developer forums?
Of course I can't even try to take another look at your demos today, because your server is refusing connections, and that doesn't exactly project a solid professional image either.
The Echo 1.x demos had to be taken offline due to server-related issues that will be rendered irrelevant when nextapp.com moves to its new server shortly. The notice on the demo page indicating such appears to have been accidentally removed in the latest update to the site a few days ago. I was not aware of this until reading your comment; the correct page is now online once again.
Though the 1.x demos have been offline for several weeks, the Echo2 demos are presently available and server logs indicate there have been no recent interruptions in service. If you want to see a demo of Echo2, please visit: http://www.nextapp.com/products/echo2/demo My apologies for the inconvenience with regard to the Echo 1.x demos.
I looked at Echo; it sucked horribly on non-Windows platforms, which for a cross-platform technology meant that it sucked horribly.
I am the lead developer of the Echo project. To the best of my knowledge, I have not previously heard of any significant performance disparity between Windows and other platforms on either the client or server ends.
Your statement comes as a bit of shock, given the environment in which Echo is developed. I have been using Linux as my primary operating system since being introduced to it in 1996. Most of the Echo code was developed on Linux in an environment where it would first be tested in Mozilla (on Linux) and then immediately checked with MSIE. MSIE has always been the limiting factor in the development of Echo.
I would very much appreciate if you could post more details as to the problem you encountered with Echo on non-Windows platforms. It would also help to know the version you were using and / or any additional component libraries which were used (including anything written in-house).
Echo and.Net are From-based web apps. Every click / button push results in a form being submitted to the server, and the whole page being re-drawn. This is no different than any other form of web development done for the past 15 years, the only benefit is ease of development or deployment on the server side.
You're correct with regard to the Echo 1.x platform (originally released in early 2002), but the upcoming 2.0 version of Echo, "Echo2", is built entirely around the technologies now being referred to as "Ajax". Every single update to the state of an Echo2 application is performed by partial updates to a DOM (there is no case in which an entire document is reloaded or swapped out). All client-server synchronization is performed over XMLHttpRequests, with the client sending an XML message describing a user's input and the server reciprocating with an XML message containing directives to update the state of the user interface.
You can see all the XMLHttpRequest stuff in action by appending "?debug" to an application's URL, e.g., click the following link to run the interactive test app in debug mode:
You'll need to allow a pop-up through as the "Debug Pane" runs in a separate top-level browser window.
Note that running in debug mode will reduce the speed of an application to a crawl, especially in Internet Explorer. Normal operation can be restored by simply closing the debug window.
Currently Echo2 is on its second release candidate, with the final version being released imminently. More info on Echo2 can be found here:
The main impact of Echo seems to be that when I try to go to the web site, it crashes Firefox on Linux. Nice.
I guess that's what I get for trying to RTFA.
I'm not sure what's going on here, is there a particular page of the web site that's causing FF to crash for you or are you actually trying to hit one of the demo apps?
I too use FF on Linux and work on and navigate the site quite frequently but have not seen this before.
"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.
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).
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.
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.
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:
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:
"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 documentation for more information about why we're doing things like this. Specifically, look at chapter 2, "Client/Server Interaction".
"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."
With regard to the "multiple submits/redirects": I think you are seeing the client-browser download the small JavaScript resource files that are required to make the application work. These are downloaded on an as-required basis, and are cached for future use. After two or three clicks, this issue goes away.
With regard to using JavaScript to highlight a single row of the e-mail message list in order to avoid reloading its frame, you are very much correct in that this would be more efficient. It is possible to do exactly that, but it would have required the creation of an Echo component that rendered a few bits of HTML and JavaScript to do it. This was out of the scope of the tutorial, so instead the stock Echo components were used. For more info on creating Echo components that render their own HTML and script, see the Component Authoring Tutorial.
"Not only that, but the app doesn't even work in Mozilla for me!!"
I take it you're using Firebird 0.6.1? Another slashdot user reported this issue and I've looked into it. Echo works with 0.6 and the latest nightlies, but not with 0.6.1 (possibly due to a bug in 0.6.1). It also works quite well with the Mozilla 1.0-1.4 series. Please take a look at this post for more details on the problem.
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 browser of choice.
Echo does not work with Mozilla Firebird 0.6.1. It works with 0.6, and with the latest nightlies. To the best of my knowledge, this appears to be due to a bug in Firebird. (Please understand that it's possible I'm wrong on that, I'm still looking into the matter). Keep in mind though that the stable Mozilla series (1.0-1.4) is very much a first-tier supported platform for Echo. Firebird support *is* important, as even though its not an officially stable release yet, it is a very cool product, and is tremendously popular among developers. See this post for more information on this problem:
Echo doesn't render in XHTML yet (it presently renders HTML 4.01 transitional, and does use CSS as much as possible). We will go to XHTML when it makes sense to do so (Which I personally hope is sooner rather than later). Please also take a look at this recent post of mine if you'd like more info on how we deal with specification compliance:
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:
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.
I didn't write EchoPoint Casino, and worse, I'm not even familiar with the source code. I am all too familiar with the app from an end-user standpoint though.
I do know a bit of the history on the application though. It was built some time ago to demonstrate one of the features of EchoPoint (which is a collection of free as in LGPLed Echo components). Specifically, it shows off the capabilities of HtmlTemplatePane, which allows the embedding of Echo components within an HTML template. To the best of my knowledge, this app was written as a just-for-the-fun-of-it demo by the lead developer of EchoPoint, Brad Baker.
The most significant performance issue I see with the poker game is that clicking on a card results in a refresh of the screen. Each card is its own button, distinct from the checkbox below it. Clicking on a card results in a server-roundtrip, where an ActionEvent is fired and is picked up by a listener that toggles the checkbox below it. Once this has finished, the response causes the whole screen to be re-rendered by the client. That's not very efficient, and wrecks the interactivity of the game in this case, where the server is not on your Intranet, but instead is in San Antonio, Texas, in the US.
One solution that springs to mind to solve this problem would be to create a reusable rendered component that renders the card, the checkbox and the "Hold" label and sets the state of the checkbox without a server roundtrip. Such a component would require a little bit of HTML and JavaScript programming, albeit not much. Echo is very much designed to be extended in this fashion. The betting interface could also use a similar overhaul.
A "workaround" of sorts exists if you click the "hold" labels or their checkboxes to hold the cards instead of clicking on the cards themselves. It makes the game quite a bit more playable, and is representative of the performance on would see if the previously mentioned card/checkbox component were created.
Slashdot Mirror
"The survey said most motorists who used either resource while driving would take their eyes off the road for 10 seconds, which at 60 miles an hour would equate to traveling twice the length of a football field."
This pretty much makes me not believe what these people have to say. I cannot believe that it is possible to repeatedly drive blind for 10 seconds at 60mph without incident.
Congrats to the developers, I'm really looking forward to trying it out when it goes stable!
Just curious if anyone might know if Gnome 2.14 is making the cut for Fedora Core 5 or the next Ubuntu?
Actually, Firefox seems a lot worse in this regard. Throw something fun at it like a 10MB table, and it will take 10x longer than IE to load, and afterward you can barely pull down a menu.
The "worst bug ever" tended to appear not as a result of large DOMs, but of complex DOMS, i.e., a combination of lots of nested elements, CSS positiong, and interactivity. My primary complaint with IE here is that this was not really all that extreme of a case, and all other browsers were not even "breaking a sweat" to render it.
Definitely agree that all my listed issues can be worked around, but I wouldn't go as far as to say it's trivial to do so. Here are the current workarounds I use in IE for these problems:
Just curious if you happen to know of better/simpler workarounds for any of the above? (Please note, this is not a rhetorical question/argumentative response, I'm genuinely curious if you've come across something better, as I'd be extremely happy to find better solutions for any of the above!)
And I do agree on the signifance of not supporting the proper W3C events, at this point I'm simply resolved that event capturing is only a figment of my imagination.
What IE really needs right now, if it wants to be taken seriously as a platform for AJAX web applications, is proper DOM/CSS support. The following would be a good start (my current peeve list with IE6):
I've posted this on ieblog before. I sincerely hope that somehow someone on the IE team sees one my numerous implementations of the above list of rants and implements solutions for them. It'll make the professional lives of many AJAX developers quite a bit more pleasant.
Doesn't matter what it is, just build something around AJAX.
Mod parent up--this advice worked for me!
So? When 90% of your "customers" are being told that they either turn off Javascript or get a virus, it doesn't matter whether the problem is with Javascript or IE - either way, there is no return for adding AJAX features to a web site. I'd rather spend my precious development resources on non-AJAX features that benefit everybody.
Disclaimer: I'm a bit biased on this one (e.g., see my homepage URL).
JavaScript isn't going to go away over security flaws in the IE implementation. People continue to use Internet Explorer, Outlook, and other programs with sordid security track records. I can certainly see the current AJAX frenzy causing a good deal of attention toward JS security, but the industry's answer won't be to simply give up.
GM and Ford are not in a position at present to offer additional incentives to their employees unless they will have a direct impact on their bottom lines. This is likely to remain the case for the next several years.
Here's another example of an AJaX e-mail client written using the Echo2 Web Framework. This one is very much no frills (it's an example app for Echo2) but it does include complete MPL/LGPL/GPL source.
Onstar is easy to disable (pull a fuse) and doing so has no ill effects as far as I can tell from first-hand experience. Once the fuse was reinstalled the system continued to function as before. A description of which fuse must be pulled can be found here:
/ pp4/pp4pg2.html
http://www.hypertech-inc.com/install_instructions
The one thing that has always bothered me about such "forensic analysis" in computer crime investigation is the fact that it is fairly trivial for a competent developer-type person to artificially create this information and tell any story s/he wants. If someone wanted to frame a person for a computer crime they could even develop a trivial piece of malware that would actually visit target sites from a person's computer over time, such that even the ISP's and target host's logs would confirm the user's activity. Such a program could be configured to activate only when a user was at a computer. The only technical challenge to creating such a piece of software would be finding a means to install it, but it's common knowledge that there are a great variety of means (both social and technical) to accomplish this step.
It would be my guess that it would be fairly difficult to convince a jury that the real criminal was an "evil program" running behind the scenes. The only real hope for a defendant in such a scenario would be to find some flaw in the malware program to suggest its existence (for example, if it activated when the defendant was out of town and his/her spouse was using the machine).
It concerns me that somewhere, someday, someone might go to prison as a result of the forensic analysis of his/her computer when in fact the criminal act was committed by a third party solely for the purpose of landing his/her victim in prison.
It was a while back. I think it was about 2 years ago, but it could have been a bit more. Anyway, I ran into UI glitches and bugs all over the place, just trying to deal with the demos. I recognize that you have a difficult job dealing with browser stupidity, but the end result is what I care about.
Were you using components other than those included in the stock Echo distribution, and was the stock distribution a final version? Were any add-on components you were using from beta versions of component libraries? Did you seek any help from the developer forums?
Of course I can't even try to take another look at your demos today, because your server is refusing connections, and that doesn't exactly project a solid professional image either.
The Echo 1.x demos had to be taken offline due to server-related issues that will be rendered irrelevant when nextapp.com moves to its new server shortly. The notice on the demo page indicating such appears to have been accidentally removed in the latest update to the site a few days ago. I was not aware of this until reading your comment; the correct page is now online once again.
Though the 1.x demos have been offline for several weeks, the Echo2 demos are presently available and server logs indicate there have been no recent interruptions in service. If you want to see a demo of Echo2, please visit: http://www.nextapp.com/products/echo2/demo My apologies for the inconvenience with regard to the Echo 1.x demos.
Best regards
--Tod Liebeck
NextApp, Inc.
I looked at Echo; it sucked horribly on non-Windows platforms, which for a cross-platform technology meant that it sucked horribly.
I am the lead developer of the Echo project. To the best of my knowledge, I have not previously heard of any significant performance disparity between Windows and other platforms on either the client or server ends.
Your statement comes as a bit of shock, given the environment in which Echo is developed. I have been using Linux as my primary operating system since being introduced to it in 1996. Most of the Echo code was developed on Linux in an environment where it would first be tested in Mozilla (on Linux) and then immediately checked with MSIE. MSIE has always been the limiting factor in the development of Echo.
I would very much appreciate if you could post more details as to the problem you encountered with Echo on non-Windows platforms. It would also help to know the version you were using and / or any additional component libraries which were used (including anything written in-house).
Best regards
--Tod Liebeck
NextApp, Inc.
Echo and .Net are From-based web apps. Every click / button push results in a form being submitted to the server, and the whole page being re-drawn. This is no different than any other form of web development done for the past 15 years, the only benefit is ease of development or deployment on the server side.
You're correct with regard to the Echo 1.x platform (originally released in early 2002), but the upcoming 2.0 version of Echo, "Echo2", is built entirely around the technologies now being referred to as "Ajax". Every single update to the state of an Echo2 application is performed by partial updates to a DOM (there is no case in which an entire document is reloaded or swapped out). All client-server synchronization is performed over XMLHttpRequests, with the client sending an XML message describing a user's input and the server reciprocating with an XML message containing directives to update the state of the user interface.
You can see all the XMLHttpRequest stuff in action by appending "?debug" to an application's URL, e.g., click the following link to run the interactive test app in debug mode:
http://demo.nextapp.com/InteractiveTest/ia?debug
You'll need to allow a pop-up through as the "Debug Pane" runs in a separate top-level browser window.
Note that running in debug mode will reduce the speed of an application to a crawl, especially in Internet Explorer. Normal operation can be restored by simply closing the debug window.
Currently Echo2 is on its second release candidate, with the final version being released imminently. More info on Echo2 can be found here:
http://www.nextapp.com/products/echo2
The Echo2 demo apps may be found here:
http://www.nextapp.com/products/echo2/demo (Both of these can be operated in debug mode.)
Best regards
--Tod Liebeck
NextApp, Inc.
The main impact of Echo seems to be that when I try to go to the web site, it crashes Firefox on Linux. Nice.
I guess that's what I get for trying to RTFA.
I'm not sure what's going on here, is there a particular page of the web site that's causing FF to crash for you or are you actually trying to hit one of the demo apps?
I too use FF on Linux and work on and navigate the site quite frequently but have not seen this before.
Best regards
--Tod Liebeck
NextApp, Inc.
"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.
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).
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.
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).
/.'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).
:)). 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.
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
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
But I will say DHTML Lemmings is quite extraordinary, that is one of the most impressive uses of DHTML I have seen.
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:
y /j-echo1/
http://www-106.ibm.com/developerworks/java/librar
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.
"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 documentation for more information about why we're doing things like this. Specifically, look at chapter 2, "Client/Server Interaction".
"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."
With regard to the "multiple submits/redirects": I think you are seeing the client-browser download the small JavaScript resource files that are required to make the application work. These are downloaded on an as-required basis, and are cached for future use. After two or three clicks, this issue goes away.
With regard to using JavaScript to highlight a single row of the e-mail message list in order to avoid reloading its frame, you are very much correct in that this would be more efficient. It is possible to do exactly that, but it would have required the creation of an Echo component that rendered a few bits of HTML and JavaScript to do it. This was out of the scope of the tutorial, so instead the stock Echo components were used. For more info on creating Echo components that render their own HTML and script, see the Component Authoring Tutorial.
"Not only that, but the app doesn't even work in Mozilla for me!!"
I take it you're using Firebird 0.6.1? Another slashdot user reported this issue and I've looked into it. Echo works with 0.6 and the latest nightlies, but not with 0.6.1 (possibly due to a bug in 0.6.1). It also works quite well with the Mozilla 1.0-1.4 series. Please take a look at this post for more details on the problem.
This framework is appalling. I'd expect better from IBM, and I don't even have that high an opinion of them!
8 63&cid=6917761
8 63&cid=6924701
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 browser of choice.
Echo does not work with Mozilla Firebird 0.6.1. It works with 0.6, and with the latest nightlies. To the best of my knowledge, this appears to be due to a bug in Firebird. (Please understand that it's possible I'm wrong on that, I'm still looking into the matter). Keep in mind though that the stable Mozilla series (1.0-1.4) is very much a first-tier supported platform for Echo. Firebird support *is* important, as even though its not an officially stable release yet, it is a very cool product, and is tremendously popular among developers. See this post for more information on this problem:
http://developers.slashdot.org/comments.pl?sid=77
Echo doesn't render in XHTML yet (it presently renders HTML 4.01 transitional, and does use CSS as much as possible). We will go to XHTML when it makes sense to do so (Which I personally hope is sooner rather than later). Please also take a look at this recent post of mine if you'd like more info on how we deal with specification compliance:
http://developers.slashdot.org/comments.pl?sid=77
"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
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.
I didn't write EchoPoint Casino, and worse, I'm not even familiar with the source code. I am all too familiar with the app from an end-user standpoint though.
I do know a bit of the history on the application though. It was built some time ago to demonstrate one of the features of EchoPoint (which is a collection of free as in LGPLed Echo components). Specifically, it shows off the capabilities of HtmlTemplatePane, which allows the embedding of Echo components within an HTML template. To the best of my knowledge, this app was written as a just-for-the-fun-of-it demo by the lead developer of EchoPoint, Brad Baker.
The most significant performance issue I see with the poker game is that clicking on a card results in a refresh of the screen. Each card is its own button, distinct from the checkbox below it. Clicking on a card results in a server-roundtrip, where an ActionEvent is fired and is picked up by a listener that toggles the checkbox below it. Once this has finished, the response causes the whole screen to be re-rendered by the client. That's not very efficient, and wrecks the interactivity of the game in this case, where the server is not on your Intranet, but instead is in San Antonio, Texas, in the US.
One solution that springs to mind to solve this problem would be to create a reusable rendered component that renders the card, the checkbox and the "Hold" label and sets the state of the checkbox without a server roundtrip. Such a component would require a little bit of HTML and JavaScript programming, albeit not much. Echo is very much designed to be extended in this fashion. The betting interface could also use a similar overhaul.
A "workaround" of sorts exists if you click the "hold" labels or their checkboxes to hold the cards instead of clicking on the cards themselves. It makes the game quite a bit more playable, and is representative of the performance on would see if the previously mentioned card/checkbox component were created.