Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

AJAX, Echo, .NET - What Impact Have They Had? 106

Posted by Cliff from the will-the-browser-ever-trump-the-desktop dept.
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?"
This discussion has been archived. No new comments can be posted.

AJAX, Echo, .NET - What Impact Have They Had? More

AJAX, Echo, .NET - What Impact Have They Had?

Comments Filter:

  • Surprise (Score:1, Funny)

    by biryokumaru ( 822262 ) *
    I guess I coughed too loudly...

    *cough* vaporware *cough*
    - Me circa two years ago, in regards to .NET

  • I hear stories from friends who do in house development of web apps that use .NET. I have never seen one out in the open but apparently they are pretty popular in some industries because they are easy and quick to create and also powerful. Especially medical and insurance industries from what I am told.

    Is that other's experience that these things are currently just used in house where .NET is widely deployed? Can we expect to see them being exported to the unwashed masses in the future?

    • Re:in house (Score:3, Informative)

      by GeckoX ( 259575 )
      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.

    • Re:in house (Score:5, Interesting)

      by Momoru ( 837801 ) on Monday August 08, 2005 @02:35PM (#13271714) Homepage Journal
      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.
      • I would certainly agree with your statement of being technically far superior to old ASP, and even PHP to some degree (though not totally, nor am I well-versed enough to argue the finer points) - However as for being superior to ColdFusion... I think that is certainly more of a gray area.

        As an example, ColdFusion (as of MX7) has some VERY nice integrated reporting, charting and forms support built in that ASP.NET does not. Not that you couldn't go find and add them in - but at what cost, both time and monet

        • Re:in house (Score:3, Insightful)

          by GeckoX ( 259575 )
          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.
      • I'm curious what made you say that using multiple languages together was difficult?

        I'm currently working on a .NET project where most of the middle tier is written in C#, but the asp.net code-behind is written in vb.net, and so far we have had no problems whatsoever.
        • I'm curious what made you say that using multiple languages together was difficult?

          I really just meant using non- .NET languages is not easy, like in theory you can write .NET apps using perl or C++ or whatever, but this isn't well documented or supported. But in terms of what your saying the IDE won't let you make one project both VB.NET and C#...like if you had a web app and wanted the login page to use VB.NET and the shopping cart to use C# or something for some crazy reason, it won't allow that. (B
    • Clearwater foods has a multilingual, multicurrency website that interacts with the warehouse and various shipping companies via XML which was built in .NET, I know because I built it. Why did I use .NET? Because they decided it was a good buzzword. Because it was good? Um... no. .NET web apps are quick and easy to create. So are Frontpage web apps. Nuff said.

  • when in doubt, google it (Score:3, Interesting)

    by I8TheWorm ( 645702 ) * on Monday August 08, 2005 @01:20PM (#13270969) Journal
    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.

  • Because they're still platform dependant. (Score:3, Insightful)

    by GeckoX ( 259575 ) on Monday August 08, 2005 @01:21PM (#13270990)
    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.
    • Actually, I should also add that AJAX and .NET are not mutually exclusive at all.

      I'm currently building a redesign of a traditional asp site using asp.net. All of the advanced client functionality is AJAX.
    • " At least with .NET, it's still dependant on IE being used as the browser." Are you talking about running winforms apps in the browser? As far as ASP.NET goes, very few things work in IE only, and most of those things still work in other browsers but require a round trip whereas they may not in IE.
      • 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, sta
    • .NET works fine without IE. .NET 2.0/VS.NET 2k5 is even producing 100% standards compliant HTML code for controls, etc.
      • Please see the qualifications to my statement, and subsequent comments. I most certainly realize that.

        However, .NET _has_ been used almost exclusively until recently to build rich intranet applications, as up until 2.0 there wasn't a lot available to the developer in terms of rich features unless you were to fall back on traditional asp/ActiveX type functionality.

        2.0 absolutely changes this and is why we are just now beginning to see .NET driven rich web apps online.
        • I'm not sure I see your point so far.... maybe you can enlighten me. In working with the .Net Framework 1.1.4322, everything I'm using that is .Net specific (Datagrid, user controls, etc...) renders just fine in FireFox and in Opera (when not set as defaulting to IE type browser). The reason is .Net apps spit out HTML/JScript instead of intrinsic controls when the browser is not IE. This is pre-2.0 stuff.
          • Yes, but it only really works as advertised in 2.0, when one is talking about rich web applications. (IE: Features in a web app one would expect in a normal app)

            Non-IE output in pre 2.0 is severely lacking, very few advanced controls, and no AJAX features built in.

            Yes, pre 2.0 does work, but it's with 2.0 that it works well enough to be adopted by a lot more developers.
            • I see... very true. Any functionality you want with the 1.1 framework in non IE browsers requires roundtrips certainly.
            • AJAX isn't built in, but it is a perfectly viable tool. Just like data layer abstraction isn't "built in" doesn't mean you can't do it.

              The only thing I know of that requires IE is if you server a windows app over the web IN IE, but I've never seen it done professionally, primarily because .Net by default prevents .Net assemblies from running anywhere's but locally. So unless you want to make your user's accept a certificate and adjust their .Net security (trust can be set for a specific assembly) it's ju
              • 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
          • .NET is "dumbing down" the HTML it sends to FireFox/Opera, though.. do a comparison sometime.

            Unless you've added your own sections to the machine.config, or followed the slingFive browserCaps update [slingfive.com].. you're not getting the full benefit of the other browsers.
          • I found those cool 'validator' client side controls don't work on Firefox...
            • That's strage, as I just tested one this morning in FireFox, and it worked fine. When I check the source code, it's all converted to js.
            • Dino Esposito (author of Programming Microsoft ASP.NET, and all-around smart guy) recommends never using client-side validation, as it's too easy to defeat.

              I kinda agree, although I'm not sure that if, say, ASP.NET detects IE on the other end and sends it client-side validation code if it still checks it server-side. It damn well should check it anyway.

              Either way, the server-side validation is much more robust - there's some things that should only require 1 validation control on a form, but requires 2 on
    • At least with .NET, it's still dependant on IE being used as the browser.

      Huh? What a load of baloney. ASP.NET renders according to the machine.config's browser capability settings. Check out slingFive's BrowserCaps [slingfive.com] for FireFox/Safari/etc., which causes .NET to render compliant code for all major browsers.

      Also, it is important to note that ".NET" means quite a few things.. .NET does not mean web-only. There are console .NET apps, form-based .NET apps, and web based .NET apps. There's also different languag
      • Wow, you really showed me.
        Wish I had known all of that before I started writing .net based web applications.

        Now to counter the one real problem I have with what you said, about browser capability settings. Have we learned _nothing_ yet?

        Code to supported standards, not to browser specific capabilities. Never NEVER switch code based on the user agent info provided. Test for capabilities on the client when you _must_ use possibly unsupported features.

        Even GMail does this. Do you think they're using a server-si
        • The whole reason for the machine.config's browser capabilities section is to have the ability for .NET controls to "downgrade" themselves to lesser capable browsers-- so if you try and use Netscape v3, etc. to view a .NET page, it won't look like absolute garbage and be non-functional. It isn't meant to "lock in" to Internet Explorer; it's totally extendable by yourself or anyone else (hence the slingFive link I posted.)

          Any web design job that will reach the masses is sure as heck going to try and work for
          • Man you're an asshole who just has to be right aren't you? You don't hear what anyone has to say except for what's coming out of your own mouth do you?

            If you really do what you say you do for a living, you of all people should understand why using browser capability switches on the _server_ is a bad idea. You even gave one of the blatant reasons yourself, unreliable user agent strings.

            You also assume that because I don't do so, that I must be providing IE only content. WTF? I completely explained myself her
            • Hey, you attacked me personally first:

              So yeah, thanks again for talking down to me about what I do for a living, and yet proving that you do not know anywhere near enough to be partaking in this discussion in such a demeaning pedantic way.

              Have a nice day,
              -Asshole

              • Also, it is important to note that ".NET" means quite a few things.. .NET does not mean web-only. There are console .NET apps, form-based .NET apps, and web based .NET apps. There's also different languages that encompass .NET, such as C#, VB.Net, and J#.


                Quoting your original pedantic, arrogant comment that started this all off. Asshat.
    • 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.

  • 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.
    • 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.
    • I suggest the Echo2 website:
      http://www.nextapp.com/products/echo2/ [nextapp.com]

      It's sweet, an Open Source framework for developing client-server apps with the display in dynamic html using XMLHttp as a transport.

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Monday August 08, 2005 @01:24PM (#13271019)
    Comment removed based on user account deletion
    • As a matter of fact, that's what's being used now at the Harris County District Clerk's Office. The entire document imaging/indexing system is .Net based.

  • .Net (Score:4, Informative)

    by Fr05t ( 69968 ) on Monday August 08, 2005 @01:30PM (#13271069)
    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.
    • That's great, and from personal experience that is certainly a lot easier to do now with .NET.

      However, what stopped you from having a consolidated business logic layer before .NET? We always did for just the reasons you mention.

      Helped us get up with porting our systems to .NET a lot quicker as it wasn't a total redesign of every last bit of the system.

      Anyways, great that you've made that happen. Better late than never!
      • I'm not sure what took them so long - I was hired on to help move everything over to .Net and to rebuild the management web interface. I fell in love with .Net doing it - I only wish my efforts to ensure mono compatibility, and market it as cross platform yielded better results.

  • .net gripes (Score:2, Interesting)

    by ackdesha ( 572569 )
    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
    • What a load of crap.

      It's a hugely matured platform now.
      There is tonnes of documentation and examples out there. More and more every single day.

      If you can't see the wave coming, then you're not looking in the right direction.

      As for language support, I see you managed to leave JScript .Net off of that list, which is exactly what you request, does exist, and is provided out of the box from MS.

      You want Ruby, Perl or Python in there, write the IL Interpreter for it, or help one of the projects out there doing ju
    • 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).

      .NET is extremely scalable, if you know how to code. If you can't grasp OO concepts, then stick to BASIC, because you're not going to be able to code in any modern progra

    • Re:.net gripes (Score:5, Informative)

      by Rolan ( 20257 ) * on Monday August 08, 2005 @02:11PM (#13271498) Homepage Journal
      ...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 [activestate.com] Perl and (experimental)Python
      http://www.saltypickle.com/rubydotnet/ [saltypickle.com]Ruby/.NET compatability
      http://www.zope.org/Members/Brian/PythonNet [zope.org]Python
      http://www.ironpython.com/ [ironpython.com]Python, again....
    • but where's my perl, python and ruby dot net

      Yeah, and where's my OCaml.net... oh wait [microsoft.com]

    • Re:.net gripes (Score:5, Interesting)

      by anomalous cohort ( 704239 ) on Monday August 08, 2005 @05:39PM (#13273707) Homepage Journal
      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.

    • The following is an EXCELLENT book on writing scaleable .NET apps. The example the book is based on has a Windows Forms end and a Web Forms (ASP.NET) end, but most of the book focuses on writing a very scaleable business logic and data access layer.

      http://www.amazon.com/exec/obidos/tg/detail/-/1590 591453/qid=1123608876/sr=8-1/ref=sr_8_xs_ap_i1_xgl 14/102-2316263-0372969?v=glance&s=books&n=507846 [amazon.com]

      There is also a C# version.

      Also, I wouldn't exactly say C++.NET is well supported, either. It seems to
  • The company I work for develops almost exclusively* in .NET. For years now we've developed a massive web application for managing data across the nation between hundreds of entities. We've been moving this application over to ASP.NET over time (re-implementing exiting features in .NET and coding all new features in .NET). This isn't a "public" website perse, as you have to be working for one of our clients to get to it, but it is used by thousands of users within those clients. We've architected it in s
  • I'm currently in the process of rewriting an internal business management app in C#. The original is written in VB6. This was all my idea, and I'm a big Linux freak. Why? Well, several reasons.

    The original program started simple. Then it started growing. It's got a fairly complex security system, grew quite large, and evolved over many years. Some of the underlying database design is pretty bad, and fixing it will require very large changes to those parts of the application anyway, so I might as well write
    • >>makes it so that VB is very inconvenient, and not
      >>only because MS is dropping support.

      and in a few years when MS drops support for .net for the latest buzzword that they come up with?

      I mean they've already dropped .net as a marketing term because they confused everyone so much that no one even knew what .net meant...

      planning any long-term applications no a microsoft platform is asking for trouble, period. open source, open standards is the only way to guarantee that your company makes the de

  • Desktop threatened by AJAX? (Score:3, Insightful)

    by COBOL/MVS ( 196516 ) <arghernaNO@SPAMhotmail.com> on Monday August 08, 2005 @02:27PM (#13271646) Homepage Journal
    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.
    • That is not true, or at least, very near sighted.

      Why is it that a screen reader works fine with a normal windows application, but falls apart leaving the user 'blind' with most web applications?

      Because there are a huge number of guidelines that are followed in building windows apps. The tools just work that way.

      All of the required guidelines exist to build fully accessible sites online. We just need to use them.

      There is simply NO reason for all sites with accessability requirements to be simply styled text.
      • Then I hope that more responsible web app developers take that as their spec for developing their AJAX sites. Nice to see someone else gets it.

        This also gives me some hope that we can add AJAX to the UI for our site.
        • Just FYI, as it appears you may care if you haven't ran across this yet:

          Here's the most important usability problem occurring in AJAX implementations: XMLHttpRequest breaks the users expected back functionality as calls via XMLHttpRequest are not http requests and as such have no effect on the browser's history. (Also usually makes it impossible for a user to create a valid bookmark to where they want)

          This does not mean that XMLHttpRequest should not be used, it just has to be used carefully. Unfortunately
    • "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."
      No, that's not why you make sites accessible. Sorry to go off, but acting out of pity or a fickle sense of what's 'fair' does not justify the cost of creating fully accessible sites.
      • Sites are accessible so that you, the developer can get in there and fix things when they break horrendously and you're stuck at the datacenter VPN'
  • A bunch of developers caught sick with Mono [mono-project.com], and everything got set back a few months, at least.

    Go on, ask them who they've been kissing up to, so to speak...
  • I can say that it is an amazing tool, with it's own limitations.

    One of the greatest features though is it's combination of rapid application development (ala VB6) and fully Object Oriented design patterns (ala C++). This results in the ability to quickly create modules and reuse them extensively.

    For example, we spent 4-6 months working on a framework, interface and logic for a windows based lease reporting tool. In that framework, we developed our data layer, which completely abstracts the database, a
  • I suppose they ran out of meaningful questions that contain the "Ajax" term, but they still need to maintain constant fire to keep the term fresh in our minds.

    If this technique is successful, and all signs point to "yes", expect to see more development houses coin new terms for existing technology, to be remembered as the "inventors" of said technology.

  • Fundamentally different (Score:3, Informative)

    by brunes69 ( 86786 ) <slashdot.keirstead@org> on Monday August 08, 2005 @03:20PM (#13272279)
    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).
    • Echo2 uses XMLHttpRequest for client-server interactions.

      But really, it's not significantly different from using background form submission in hidden frames. AJAX is not qualitatively different, in terms of user experience.
    • 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 and Stuts do not mix well

      That is simply not true. Struts delivers web contents and employs the MVC concept. There is no reason why an Ajax component cannot update or retrieve Struts generated content.

      Some simple examples can be found here [omnytex.com]
      And here [java.net] is an article about using Ajax with JSF.

      It's funny, I have been using Ajax stuff for quite a while (before the term "Ajax" was coined), but it seems it needed a name to take off.

  • Notice how most of the posts are along the lines of "we're in the middle of upgrading from VB to .Net" or "we're currently porting all our apps from C++ to .Net" or "we're currently upgrading everything to .Net".

    Here's a hint: Microsoft LOVES you guys. People who jump on the upgrade bandwagon even BEFORE they declare your old gear obsolete.

    How about things, instead, like C, or Java, Perl?
    • Yes, but if you actually read most of these posts you are talking about, you would realize that they are almost all doing it because of the benefits they are gaining by doing so. They are doing it to improve their systems, not just because.

      So what are you suggesting? Should I move this old legacy asp site I've got sitting here, implemented with VB6 com components, into a C backed Perl app? Or go full Java? Would that be wiser?

      (Hint: That's a trick question, you don't have enough info to answer it appropriat

  • Echo sucked. (Score:1, Flamebait)

    by sribe ( 304414 )
    I looked at Echo; it sucked horribly on non-Windows platforms, which for a cross-platform technology meant that it sucked horribly.

    • 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 introdu
      • 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. 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.
        • t 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...

          Two years is a long time. To be fair, why not give it a whirl before beating it over old problems? Heck, two years ago Firefox wasn't exactly the kick-ass product it is now!

        • 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 libra
      • that seems odd, i just cant understand what problems you've had. my places of work have generally used echo since about 0.9 on and it's been quite stable, and incredibly easy to use. the only trouble i've ever had/seen with it is getting past trying to develop web pages and get back to developing an application.
  • I always classify my work on the web into two areas:

    "Web Applications" or "Web Sites".

    Web Applications are created for a particular purpose, often may be replacing an intranet program that the company is using. Usually, the best argument for creating an intranet application is because of the ease of deployment. I've tried deploying 'normal applications' across different batches of computers with different specs and operating systems, or even in different cities. Intranet applications is just much more si
    • Stick with strict HTML, limit Javascript, use tables for layout instead of DIV. Don't do too many fancy stuff with style sheets.

      While I agree to some degree using tables for layout (unless you're displaying tabular data) and limiting CSS is *precisely* what you should not do.

      Some browsers are not up to the latest standards, but many are, *because* people are using these features.

      Styling a site with CSS will reduce your work (and hence cost) significantly and allows you to keep markup semantic.
      Using DH

  • I do not think Ajax is vaporware. The IT industry evolves in cycles. We had
    1. Mainframes (powerful server and many dump terminals)
    2. Client/Server (smarter clients)
    3. Dynamic -Server Generated- Web content (which in essence is the Mainframe with a dump display only terminal all over again).
    4. DHTML/JavaScript (Ajax), back to the client/server model, where the Browser becomes a smarter client again.

    For UI based applications DHTML/JavaScript/... is actually quite a nice platform. One has to spend some though, to f

  • I've used .NET in my last 4 jobs...

    Job 1: I wrote an Remote Desktop client in VB.NET to access the work VPN faster over a modem (there's settings for the web/RD component that aren't in the standard client), and a dumb little "evolution meter" as my first C# program.

    Job 2: I wrote a pricing system in VB.NET to manage store pricing and system build configurations; a final version before I left allowed you to choose some of the parts from lists based on the datafile.

    Job 3: I began using C# exclusively a

Slashdot Top Deals

"Take that, you hostile sons-of-bitches!" -- James Coburn, in the finale of _The_President's_Analyst_

Close