Slashdot Mirror
Microsoft Releases Atlas
Jason Lind writes "Much earlier than anticipated, Microsoft announced the release of Atlas this afternoon at MIX 06. For those who don't know, Atlas is Microsoft's AJAX API for ASP.NET 2, which they claim will greatly reduce the effort in developing AJAX style applications on their platform."
In mythology, Atlas and the Titans revolted against the Olympians, lost, had his brothers betray him, and was punished to carry the world. Is this some sort of metaphor for the IE development cycle?
Guy asked me for a quarter for a cup of coffee. So I bit him.
don't mistake your incompetence for bad software
Last time I used it .NET gave 2 output options: Netscape 4.0 compatible HTML or IE-specific HTML. There was no full support for XHTML or HTML 4. That counts as working in all browsers. But the ASP.NET output I've investigated is far from the best.
Developers: We can use your help.
The official website, just like Microsoft's regular website, is full of meaningless rhetoric. I can write complete crap HTML that works in every browser. That definitely doesn't make it good. And less code than "classic" ASP, PHP, or JSP? Not once when I worked with ASP.NET for 2 years did I find reduction of code compared to other options. Maybe there are some cases I didn't see, but a blanket statement like that is just wrong.
The only people who back up this rhetoric are Microsoft employees on their blogs and those who haven't tried any alternatives.
Developers: We can use your help.
All of those problems can be addressed by creating a good AJAX toolkit; a toolkit can fall back to plain HTML when Javascript isn't available, it can do the right per-browser customizations, etc.
...), but, again, with a good toolkit, you don't have to ever think about that.
However, from an interaction point of view, AJAX is enormously useful and a big advance over plain HTML pages. It's unfortunate that the underlying technologies are so ugly (Javascript, XML,
See my point is that I doubt they'd ever fully support all other browsers as well as IE, because they don't want to miss a chance to give IE another boost.
1. You shouldn't be testing for a UA, but for object support.
2. You can build accessibility into an AJAXified application, but it will take more work. I find that the people who care enough about accessibility on normal websites are the people who are also willing to put in the extra work making applications accessible.
3. Another attack vector? Sure, but introducing any technology introduces new risks. That doesn't mean you should dismiss it entirely. Bad code is bad code - no matter whether it's AJAX or PHP or Ruby.
4. This goes back to accessibility. If a client doesn't have Javascript at all, you need to account for that. If you're writing an app that absolutely requires Javascript, then you need to accept that some users won't be able to use the site.
5. This is the crux of your argument, I think. Some applications are dependent upon Javascript for a good reason - they aren't normal websites. The example I use is of a university that has thirty or so platform and browser combinations to support. Deploying an internal desktop app is expensive, difficult to support, etc. But a web app can be brought up on all of the supported environments - which means you can build for those and ignore anything that's unsupported (like Lynx). We're talking about interfaces which replace a desktop app - but still need comparable functionality, speed, and interfaces.
The web has always been a quickly changing landscape. AJAX is a feature on that landscape, not the future of it. Like anything else it has its valid uses and invalid uses, can be abused, and can be done poorly. But so far, none of this is a reason to dismiss it entirely.
What is it with Microsoft and its penchant for product names that are virtually useless for doing searches?
Access
Word
Windows
Excel
Publisher
Sequel
Contrast that with:
linux
mozilla
firefox
mysql
php
At least with these, you have a reasonable chance of finding what you're looking for without a ton of other non-related crap.
Ajax requires all communication be serialized using a Javascript callback scheme that requires extensible but ultimately limiting xml communication between client and server.
False. The web server can return text, plan old xml (POX), or JSON or anything that can be encoded over HTTP.
To get good performance, Ajax forces you to code a front-end application using JAVASCRIPT. Now I've coded some pretty complicated Javascript stuff, but it's just not the right language for writing full-featured applications. It's barely even object oriented, weak typed, etc. And debugging it is a disaster.
False. You're mixing concepts here (performance and client scripting language). Further, EMCAScript isn't OO and shouldn't be: it's a prototype based language. And any developer tackling this problem in today's world should use one of the many freely available JS libs (Dojo, MochiKit, Prototype, etc). Hell, MochiKit has a built in debugger.
If instead you decide to have the server make all the UI decisions for you ("put this text here, that box there"), that's fine except you'll see lag anytime you do anything. Imagine trying to update an entire column of data in Ajax Spreadsheet. The server has to send down exactly what to put in each cell and do all the computations for you before you see anything.
Knock, knock, web server calling. HTML UI decisions start on the server and get modified locally by the client. This is the nature of HTML and always has been.
Google Maps has this problem - I often see white boxes, unrefreshed boxes, etc. and I'm using the latest Firefox!
Oh, lordie. You realize that Google maps doesn't use Ajax, but instead makes heavy use of IFRAMES? (last i checked, this was true). And you realize, of course, that your connection speed might be to blame?
You've painted AJAX with a pretty broad and off-base brush. Better luck explaining it to the ignorant.
Considering I wrote a book entitled Ajax Patterns and Best Practices the mistake made by many is the fact that Ajax is not about extending the current Web paradigm. Ajax when done properly includes REST, Web Services and a decoupled architectured. This means the client is not dependent on the server and vice versa. Granted the client makes Web Service calls, but the client does not know the technology used to implement the Web Service.
What makes me laugh about many vendors in contrast to the community is that they simply don't get it. Microsoft and co think Ajax is a "style" of programming by extending and locking the client to the server. This is plain simply wrong, wrong, wrong!
Now to address to your questions:
1) First Ajax does not require XML, but relies on the Permutations pattern. The Permutations pattern is a REST style web service that says the content sent and received by the client and server depends on the needs of the client. That might be JavaScript, XML, bitmap images or even HTML.
2) Coding a front end in JavaScript is not a problem. Coding everything with JavaScript is a problem. Just like coding everything with Java is a problem. Writing a good Ajax applications means creating a client that calls a server using Web Services.
3) To address your problem you use the Infinite Data pattern that uses callbacks that sends data to the client as it received.
Again, part of the problem is that many are considering Ajax as an extension of the current Web Paradigm. Ajax is not that. Ajax is a SOA client that makes Web Service calls. Granted I will give you that companies like Microsoft confuse the issue by creating stuff that completely breaks REST, and Ajax design concepts.
If you want more information feel free to check out my site http://www.devspace.com/ as I have some prototype implementations of the Ajax and REST patterns that I was talking about (inc source), and look at the Ajax QA. And if you have any further questions just send me an email and I will be more than happy to answer your questions.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Are you completely retarded?
How this got moderated up is beyond me. It's obvious that you haven't used Atlas, much less even LOOKED at it.
The whole point of the library is to hide away the details, so XMLHttpRequest and it's ilk are tucked away neatly in the variety of external scripts that ship with Atlas.
There are only 4 or 5 controls that come with Atlas, and they're mostly non-visual anyways. The UpdatePanel is a "panel" like control that can automatically reload it's contents on a postback sent via xmlhttprequest. You don't need to do a thing.
Whomever moderated this all the way to +5 is just as retarded as the original poster.
It is Slashdot though ...
Do you know how ASP/ASP.Net work? the server-side code spits out a bunch of JavaScript code to the client page. This client-side JavaScript is what talks back to the server. Hmm... AJAX.
MS got bitch-slappedn in the ASP days because its server-side objects (even though you're invoking them from VBScript, you're invoking COM objects) were emitting browser-detecting code and not playing nice with Not-IE, or emit Not-IE hostile JavaScript (i.e., MS' DOM model). With work, it is possible to get around this.
The really hard part is getting an ASP/ASP.Net page to POST to a 3rd-party server, say, like if you're trying to send an XmlSignature to a 3rd-party...
GMail using ASP.NET? I don't think so. I'd guess they're using Python or Java. They couldn't use something that runs only on windows, anyway.
My new blog
But isn't one of the coolest things about AJAX the fact that it's pretty much platform independent? Why would anyone want to tie it to a particular platform? Didn't Java already try that?
Cheers.
I code Javascript, no two web browsers seem to be able to use the same Javascript and you have to rewrite them for each browser. Then there are those who use web browsers without Javascript like Lynx, or people who disabled their Javascript for fear of Spyware/Adware infecting their system via their browser. Ajax uses Javascript. ASP.NET is supposed to have been designed to be able to run scripts at the web server without running scipts on the client, yet it fails to do this. My old employer tried to switch to ASP.NET when 1.0 was beta back in late 2001. They are still having problems getting ASP.NET working with different browsers that various clients of theirs use, that are not under their control.
My solution was to use Java, instead of client-side scripting in Javascript and VBScript. Then any browser that supports Java can run a Java servlet and it can be programmed to be easy to use. Just make sure that their JRE version matches the one we use to develop the web applications for and everything should work out. I even worked out XML transfers to be used between the corporate web server and the client web server. We only need write one version of the Java application, instead of several versions of the Javascript support for each web page. The time we would have saved on production would have allowed us to do other things. But, nooooooooooooooooo, they went with ASP.NET because Microsoft promised them the moon, and now they are making posts to Microsoft's Newsgroups asking why ASP.NET is not working as Microsoft said it would. I am just sitting back and enjoying the fireworks and relaxing and being glad I am no longer one of those programmers being lead by Managers who have no idea how technology really works.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Actually, EMCA Script is perhaps one of the most object-oriented languages in use today. Absolutely everything is an object and there are no primatives. And as for debugging, Venkma is probably one of the most powerful debugging environments I have ever used for any language or platform?
As for your comment regarding Java Applets, it is really a matter of ubiquity. Every browser (for our intents and purposes) has ECMA Script support. However, not all of them have the Java Runtime Environment plug-in.
Join Tor today!
Well .NET controls are made to be extended. If you're just ignoring that functionality, though (dealing with custom forms and parsing out the post and get values perhaps) then you're not really buying into .NET - you're just writing normal apps in C# instead of some other language. The form and component stuff is what allows you to design web pages the same way you would design an event-based windows GUI.
.NET style programming, is freakin awesome. All you have to do is drag an ATLAS panel on to your existing page, put the controls you want inside that panel, and that part of your page now refreshes via ajax. It's so simple, it almost seems like cheating.
The ATLAS framework, for people who do get into
I would assume, but have not tested it, if the browser doesn't support ajax, ATLAS will dumb it down to regular form posts. Coding that by hand would be a huge amount of effort.
TODO: come up with a clever sig
Well, he was talking about getting around it, so I don't think he'd be that surprised.
.NET is a deliberate departure from, for monopolistic purposes. If you want cross-platform, stick with the standards that built the cross-platform internet to begin with.
As for them making it cross-platform, that would involve standards, which
If this sort of post bothers you, I can't imagine how you can deal with any of the comment forums on this site. The Apple Topics in particular are choked with "appleturf", as are any "free software" or EFF topics. The moderation system in general encourages and rewards "Party Line" posts so that's what you get.
Whenever I hear the word 'Innovation', I reach for my pistol.