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

18 of 106 comments (clear)

  1. when in doubt, google it by I8TheWorm · · Score: 2, Interesting

    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.

    Most .Net gigs I see are for corporate intranet sites, though quite a few are for web based applications.

    --
    Saying Android is a family of phones is akin to saying Linux is a family of PCs.
  2. Because they're still platform dependant. by GeckoX · · Score: 2, Insightful

    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.
    1. Re:Because they're still platform dependant. by Rolan · · Score: 2, Informative

      .NET works fine without IE. .NET 2.0/VS.NET 2k5 is even producing 100% standards compliant HTML code for controls, etc.

      --
      - AMW
    2. Re:Because they're still platform dependant. by GeckoX · · Score: 2, Interesting

      No, I realize that. I'm generalizing on how asp, and recently, asp.net has been mostly used to produce rich intranet applications with ease.

      Asp.net, and especially 2.0 have made huge advances in removing the ActiveX dependancies to allow for easier development of rich applications for the public internet.

      Asp.net 2.0 is the first from MS to really provide the tools and controls to design richly featured websites from within their IDE (VS2005) using the provided toolset.

      I've been doing the same for years, starting with traditional asp. However, it required doing all the complicated stuff by hand and from scratch. As such, it wasn't/isn't done a lot. It's a joke using VS2005. We will begin seeing more and more of these applications every day now.

      --
      No Comment.
    3. Re:Because they're still platform dependant. by GeckoX · · Score: 2, Informative

      I think I've been fairly clear that the big difference now isn't what is _possible_, it is what is now within the grasp of your average developer/given resources.

      I was writing AJAX functionality 6 years ago. A _lot_ of work, not reliable, NO tools available.

      In asp.net 1.x, the foundation was laid, but it was still too time consuming/difficult to roll rich web apps with it.

      With 2.0, it's in the box, available to point and click developers.

      AJAX has been a viable _set_of_technologies_ (it is not a tool) for a long time now. There are just now viable tools that can easily make use of AJAX.

      --
      No Comment.
    4. Re:Because they're still platform dependant. by The+Cydonian · · Score: 2, Informative
      I'm not sure why you think .net apps require MSIE to function. Out here in my company, most of our deployments are in ASP.net, but we make sure all our UI is 100% W3C compliant.

      Don't about you folks out there, but our clients actually require us to be cross-platform-friendly.

  3. Comment removed by account_deleted · · Score: 2, Informative

    Comment removed based on user account deletion

  4. .Net by Fr05t · · Score: 3, Informative

    My old employer makes a software product which has 4 parts:

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

    The .Net code meta tags, and application assembly also helped greatly in creating an easy to use AJAX framework.

  5. Re:in house by GeckoX · · Score: 2, Informative

    Ever been to dell.com?

    There are many others.

    Keep in mind a couple of things: .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.

    You wouldn't necessarily know you are visiting a .NET web application.

    --
    No Comment.
  6. .net gripes by ackdesha · · Score: 2, Interesting

    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)?

    1. Re:.net gripes by Rolan · · Score: 4, Informative

      ...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
    2. Re:.net gripes by blincoln · · Score: 2, Interesting

      Where's pascal.net and cobol.net?

      He's holding out for JCL.NET and Motorola68000-ASM.NET. .NET is pretty neat. It has its shortcomings, but it's awesome that I can add things like MD5 hash and PNG export functions with five lines of code and one line of code respectively.

      ASP.NET isn't bad either, especially compared to the pile of crap that was ASP before .NET.

      --
      "...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
    3. Re:.net gripes by anomalous+cohort · · Score: 4, Interesting
      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)

      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.

      .NET is a MSFT property. MSFT is a tool vendor and, like all tool vendors, promotes the message that a better tool is the answer to all life's problems and that their tool is that better tool.

      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.

  7. Desktop threatened by AJAX? by COBOL/MVS · · Score: 3, Insightful

    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.
  8. Re:in house by Momoru · · Score: 4, Interesting

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

    The real hope of .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#.

    That said, .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.

  9. Fundamentally different by brunes69 · · Score: 2, Informative

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

    1. Re:Fundamentally different by TodLiebeck · · Score: 3, Informative

      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.

  10. Re:in house by GeckoX · · Score: 2, Insightful

    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.