Slashdot Mirror
AJAX, Echo, .NET - What Impact Have They Had?
BjB asks: "We've talked about platform neutral frameworks for years, but with the recent story about AJAX threatening the desktop, it made me think about the hype around two frameworks that were supposed to bring applications to the browser: Microsoft .NET and the Java competitor Echo framework. Both technologies boast that you can write a desktop application that can also easily be exported as an identical web-based application. I know a lot of developers hailed the .NET framework as a major innovation and jumped on board. The Echo framework was the counter-attack that leveled the field. Now, over two years later, I don't think I've ever seen anything that leverages either one? Was this a short lived battle with nobody reaping the rewards, or has it actually made some in-roads?"
My old employer makes a software product which has 4 parts:
.Net so the business logic code could be shared between all 4-5 of their applications. Before that any time there was a change in how the software worked it had to be changed across all products, which greatly increased the chances of adding bugs, took more time, etc.
.Net code meta tags, and application assembly also helped greatly in creating an easy to use AJAX framework.
Management Software running on Windows
Web version of the management software
End user/client software on Windows, and PDAs
End user/client software in a web browser, and WAP
They moved to
The
...but where's my perl, python and ruby dot net (and I don't mean editor support)?
Right under your nose, if you bother to look:
http://aspn.activestate.com/ASPN/NET Perl and (experimental)Python
http://www.saltypickle.com/rubydotnet/Ruby/.NET compatability
http://www.zope.org/Members/Brian/PythonNetPython
http://www.ironpython.com/Python, again....
- AMW
AJAX is by far the closest thing to making a browser behave like a desktop app. But, I don't think that it will threaten the desktop itself any more than applets were supposed to back in the late 1990s.
I don't think a full AJAX app wouldn't meet all the guidelines of an accessible website. A small population needs to have web accessible apps (there are three people in my department of 200 that use braille browsers) in order to be able to do their work. I have a hard time believing that an AJAX site would fully meet their needs.
Now, that's not to say it can't be done. An accessible site can be built on top of an AJAX site and conversely. But it depends on the developer who takes the time to plan that part of his/her site.
Furthermore, I expect that there will be more AJAX sites out there. I don't expect that the SCTs and PeopleSofts of the world will be rushing to implement that functionality in their web packages (ever heard the story of the visually impared guy who tried to use his browser to do what is otherwise a 5 minute task in PeopleSoft? it took him 35 minutes or so--PeopleSoft since has allegedly addressed their html to make it more accessible).
Bottom line: sites should be planned to be accessible. It's a hinderance to me (I'd like to do our site in AJAX entirely but I can't) but it's the most fair for everyone.
GOBACK.
I see quite a few .NET web sites (look for anything with .aspx). Although it is definitely bloated, the speed at which one can develop a web app on .NET is awesome. Things that used to take hours can literally take minutes. Thats the positives...
.NET, being able to deploy to other platforms is somewhat of a lost cause, although Mono is doing pretty well. The promise of being able to write in any programming language is also technically possible, but really not as straightforward or easy as just pounding something out in VB.NET or C#.
.NET really is a good thing, and it blows old ASP, cold fusion and PHP out of the water in terms of server side pages. The next version looks even more promising, as long as it doesn't try to generate more of its own shitty javascript.
The real hope of
That said,
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.
I think that this comes to the crux of the matter, though not in the way that the original poster intended. As an application technology platform, I find .NET to be pretty sound. The problems come in the gap between expectation and reality that results from how .NET is marketed.
Many companies that embrace MSFT tools like the message. Why bother learning all that complicated computer science stuff when with a little drag-n-drop, some wizards, and some designers and you're done?
If wizards and designers could do the job, then they would have a long time ago and computer science would be relegated to the same intellectual dust bin as alchemy or astrology. Not that there isn't a place for wizards and designers, it's just that you still have to know and understand what's going on under the covers. When used as a code generator, wizards and designers are fine. When used as a surrogate architect or as a crutch by developers who lack the understanding of the underlying technology, the outcome will not nearly be as wonderful as what is promised by the tool vendor's marketing department.
In short, wizards and designers will do no better than those who use them.