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?"
Or monster it. Monster.com hit count on .Net is "more than 1000," Echo yields 328. I'd say that means both are being used.
.Net gigs I see are for corporate intranet sites, though quite a few are for web based applications.
Most
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
At least with .NET, it's still dependant on IE being used as the browser. (When we're talking easy porting of a windows .NET app to a web app)
Ajax is completely different. It is a loose framework of standards available in the most widely used browsers.
That is why we're actually seeing complex web applications now, because it is viable to deploy to your customer base without pissing off a good chunk of them.
Get off the net though and there have been rich web applications built for IE on intranets for a long long time now. They just aren't viable for a publicly accessible website.
No Comment.
Comment removed based on user account deletion
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
Ever been to dell.com?
.NET is a large platform. There are tonnes of ways to use it. You can build compiled binaries, rich ActiveX enhanced web applications for intranets, traditional websites, or AJAX enhanced web applications, to name a few.
.NET web application.
There are many others.
Keep in mind a couple of things:
You wouldn't necessarily know you are visiting a
No Comment.
After a handfull of .Net projects...
ASP.NET may be great for the smallest of projects or usable for large corporate enterprise apps, but there really isn't much middle ground to scale your designs. So I think you'll end up with a lot of poorly designed apps on this platform IMHO, because you have to be an expert OO wiz or wrestle with the VS designer (a total dead-ender). This isn't helped by the horrible docs (LosFormatter anyone). The docs give only the most trivial examples and they obviously weren't written by anyone who ever had to actually use the platform. Also, where do dynamically typed languages fit in the picture. Sure I can use C#, C++, VB.NET, but where's my perl, python and ruby dot net (and I don't mean editor support)?
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.
AJAX (or whatever other name you want to give to this remoting method) is not like this. It uses the XMLHttpRequest object to submit and fetch data to/from the server without requiring a new page load, and manipulates the page using the DOM to render the results.
This results in a much smoother experience for the end user, but it usually requires quite a large shift away from the old paradigm - for example, AJAX and Stuts do not mix well. So if you have a large web app already written in Struts, and want to AJAX-ify a few parts of it to give a better UI, it can be more trouble than it is worth (it requires totally re-thinking how you do input validation, for example).
Cold fusion is only viable for closed systems.
If you're talking a web front end to any sort of distributed or enterprise system, it's simply the wrong tool for the job.
It is wonderful for web 'designers' to put out nice content with cool features, but for building true applications, no, most certainly not.
No Comment.