AJAX, Echo, .NET - What Impact Have They Had? 106
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?"
Surprise (Score:1, Funny)
*cough* vaporware *cough* .NET
- Me circa two years ago, in regards to
Re:Surprise (Score:1)
in house (Score:2)
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)
There are many others.
Keep in mind a couple of things:
You wouldn't necessarily know you are visiting a
Re:in house (Score:5, Interesting)
The real hope of
That said,
Re:in house (Score:2)
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)
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.
Re:in house (Score:1)
I'm currently working on a
Re:in house (Score:1)
I really just meant using non-
Re:in house (Score:2)
when in doubt, google it (Score:3, Interesting)
Most
Re:when in doubt, google it (Score:2)
Because someone noticed that all the Microsoft Studio boxes had ".NET" printed on them.
It's the current buzzword compliance in action.
Re:when in doubt, google it (Score:2)
I know nothing of Echo, though, so I really can't comment on it's acceptance in the enterprise.
Re:when in doubt, google it (Score:1)
So you're a non-participant, huh?
Re:when in doubt, google it (Score:1, Offtopic)
Re:when in doubt, google it (Score:1)
Because they're still platform dependant. (Score:3, Insightful)
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.
Re:Because they're still platform dependant. (Score:2)
I'm currently building a redesign of a traditional asp site using asp.net. All of the advanced client functionality is AJAX.
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:1)
Re:Because they're still platform dependant. (Score:3, Interesting)
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
Re:Because they're still platform dependant. (Score:3, Informative)
Re:Because they're still platform dependant. (Score:2)
However,
2.0 absolutely changes this and is why we are just now beginning to see
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:2)
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.
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:1)
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
Re:Because they're still platform dependant. (Score:3, Informative)
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
Re:Because they're still platform dependant. (Score:2)
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.
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:2)
Re:Because they're still platform dependant. (Score:1)
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
Re:Because they're still platform dependant. (Score:2)
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
Also, it is important to note that ".NET" means quite a few things..
Re:Because they're still platform dependant. (Score:2)
Wish I had known all of that before I started writing
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
Re:Because they're still platform dependant. (Score:2)
Any web design job that will reach the masses is sure as heck going to try and work for
Re:Because they're still platform dependant. (Score:2)
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
Re:Because they're still platform dependant. (Score:2)
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
Re:Because they're still platform dependant. (Score:2)
Quoting your original pedantic, arrogant comment that started this all off. Asshat.
Re:Because they're still platform dependant. (Score:3, Informative)
Don't about you folks out there, but our clients actually require us to be cross-platform-friendly.
Echo *thud* (Score:2)
I guess that's what I get for trying to RTFA.
Re:Echo *thud* (Score:1)
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.
Re:Echo *thud* (Score:2)
Re:Echo *thud* (Score:1)
Maybe try a new profile and/or with no extensions installed?
Re:Echo *thud* (Score:2)
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)
Re:Uses of .NET (Score:2)
.Net (Score:4, Informative)
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
Re:.Net (Score:2)
However, what stopped you from having a consolidated business logic layer before
Helped us get up with porting our systems to
Anyways, great that you've made that happen. Better late than never!
Re:.Net (Score:2)
.net gripes (Score:2, Interesting)
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
Re:.net gripes (Score:2)
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
You want Ruby, Perl or Python in there, write the IL Interpreter for it, or help one of the projects out there doing ju
Re:.net gripes (Score:2)
Re:.net gripes (Score:2)
Thanks for the link!
Re:.net gripes (Score:2)
http://www.dotnetpowered.com/languages.aspx [dotnetpowered.com]
Re:.net gripes (Score:2)
Re:.net gripes (Score:3, Interesting)
He's holding out for JCL.NET and Motorola68000-ASM.NET.
ASP.NET isn't bad either, especially compared to the pile of crap that was ASP before
Re:.net gripes (Score:2)
Re:.net gripes (Score:1)
I don't know about pascal.net, but the latest versions of Delphi can target .net, and cobol.net is right here [adtools.com] (it's Fujitsu cobol.net, not Microsoft's).
Re:.net gripes (Score:2)
Pascal.Net is here [borland.com] and Cobol.net is here [adtools.com]. Too damn easy.
Re:.net gripes (Score:2)
Re:.net gripes (Score:1)
The Windows Forms FAQ: http://www.syncfusion.com/FAQ/WindowsForms/Defaul
Re:.net gripes (Score:5, Informative)
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....
Re:.net gripes (Score:2)
Yeah, and where's my OCaml.net... oh wait [microsoft.com]
Re:.net gripes (Score:5, Interesting)
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.
Re:.net gripes (Score:1)
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
Yes, .NET is used (Score:2)
Re:I Call "BullShit" On Parent... (Score:2)
And even so, there is no such thing as a magic 'port' tool, for ANY language. Porting is not a one-click operation. Porting is usually a lot of work in any scenario.
Doesn't matter anyways, because you most certainly _can_ port asp to asp.net. You just have to know how, and what the limitations are. Apparently your skillset would not qualify you to attempt such a task. VB programmer are we?
But, I'm quite cer
Re:I Call "BullShit" On Parent... (Score:2)
That "instead" sounds amazingly like what I said:
Suggestion: read what you're replying to. Not that I should expect so much from somone who posts AC.
For the record, you do NOT have to re-write the entire appicait
.NET (Score:2)
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
Re:.NET (Score:2)
>>only because MS is dropping support.
and in a few years when MS drops support for
I mean they've already dropped
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)
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.
Re:Desktop threatened by AJAX? (Score:2)
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.
Re:Desktop threatened by AJAX? (Score:2)
This also gives me some hope that we can add AJAX to the UI for our site.
Re:Desktop threatened by AJAX? (Score:2)
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
Fair doesn't matter! (Score:2)
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.
Let me guess what might have happened. (Score:2)
Go on, ask them who they've been kissing up to, so to speak...
As a professional .Net developer... (Score:1)
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
stop ajax (Score:2)
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)
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).
Re:Fundamentally different (Score:2)
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.
Re:Fundamentally different (Score:1)
Re:Fundamentally different (Score:3, Informative)
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
Re:Fundamentally different (Score:2)
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.
We're in the middle of switching to $FOO (Score:1)
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?
Re:We're in the middle of switching to $FOO (Score:2)
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)
Re:Echo sucked. (Score:1)
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
Re:Echo sucked. (Score:2)
Re:Echo sucked. (Score:2)
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!
Re:Echo sucked. (Score:1)
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
Re:Echo sucked. (Score:1)
A casual note (Score:2)
"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
Re:A casual note (Score:2)
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
Ajax in the future (Score:2)
For UI based applications DHTML/JavaScript/... is actually quite a nice platform. One has to spend some though, to f
.NET as my tool for getting crap done.... (Score:1)
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