Tim Doesn't Like Live.com -- And I'm Not Sure About Atlas

Tim says he doesn't like Live.com -- its slow and its ugly -- and there's just no point in it.  I have to say that I agree, but I also think there's an even bigger problem -- Atlas !  Now I'll be the first to admit that I still haven't spent much time with Atlas, so maybe I'm missing something, but it just feels all wrong to me.  Don't get me wrong, I like Ajax, when its used correctly and within reason -- of course I also liked it back in 1999 before it was called Ajax.  I also like some of the Ajax implementations from what I've seen of them, but that's where Atlas goes wrong.  What do I mean?  Quite simply it doesn't try to be an Ajax implementation -- instead it tries to be a client-side framework.  And just why do we need a client-side framework?  Oh yea, to build sites like Live.com -- it all makes perfect sense now.


  • Paul,

    It is strange that you feel that way. I think any complete web development framework should have some libraries on the client side. ASP.NET has been lacking this till now. Any kind of Ajax application requires significant amount of JavaScript code. Google Calendar and other Google apps do have lot of JavaScript code. There is no Ajax without JavaScript.

    I don't think you can call something an Ajax framework without client side libraries and tools.

    I think Atlas is a step in the right direction. It provides a cross browser compatible layer, which is its great strength in my opinion and ability to access web services from JavaScript.

    I have not been that crazy about the Data classes and XML-Script in Atlas but you can easily run Atlas in without Script Components.

    As for live.com, it is slow but remember that Atlas is still in beta (or probably alpha). I am sure that problems will get sorted out by the time it is released.

  • Hi,

    for www.live.com I'm agree with you it's horribly to slow.

    But for Atlas I'm not agree at all. Ajax can just make some request to the server, how do you do to display the response ? you have to use JavaScript and a veritable framework to make what you want is cool :-)

    ClientSide != Ajax, we can do a lot of thing with JS without use Ajax and we need a framework : Atlas.

    for Rama, live.com don't exactly use Atlas. This is a part of an old build of Atlas.

  • I would have to agree...

    I think there is alot of 'bloat' that comes with it. It has to be pushed down for every new site that you visit, creating a slow experience.

    I really like what FF offers with XUL for client side work.

  • Nobody's making you use it, there are other libraries available.

  • In Holland Scott did the keynote of the Dutch Developer Days on Atlas. At the end of the day all that everybody was talking about, was his Atlas demo and the amazing ease of developing rich client applications. And with the release of the new Altas control set this has become even better.

    Atlas may or may be not a perfect Atlas implementation, I actually really don't care. With Atlas I can increase my productivity because I don't have to worry about javascripts and cross browser compatibility. And the Atlase framework is still expanding with cool new stuff.

    But most of all, I think the best thing about Atlas is the way it's developement team has interacted with and listened to the community. A lot of people are really happy with this stuff, so why call it "a bigger problem" when you haven't even really tried it yourself?

  • I think PageFlakes.com does what live doesn't, and that's use the atlas library to make the client actually feature rich. I really believe they do it right from a user perspective, and Live.com tries to do it just from a theory standpoint. What I mean by that is an extension of what Paul said, there's more to using Atlas in the right context. Both sites essentially try to do the same thing, one succeeds and one fails, because pageflakes ensures to take it from the user perspective.

    That said, my homepage is still google.com/ig

  • The simplest way I can explain what I mean is to simply ask anyone interested to compare what other Ajax for ASP.NET libraries do compared to Atlas. And by that I don't mean to imply that Atlas cannot do something more or different, but I get the impression that Atlas forces you too much down this other path. I do like having some JavaScript libraries already written for me, but if the result is slower than a simple postback, or other Ajax libraries, then what's the point.

  • I personally have found Atlas to be extremely easy to use and don't think it takes me down a different path. I've been doing Ajax-like functionality for at least 6 years now and it's never been simpler. I thank the ASP.NET team for removing the cross-browser compatability layer from me. This alone has saved me a tremendous amount of time. I think those who complain about Atlas are missing the spirit of it. I've used AJAX.NET fairly extensively (which I also like), but ATLAS seems more natural to me.

    As an enterprise application developer, I take comfort in knowing that I'm creating a more responsive application (at least perceived responsiveness) and my users have definitely noticed the improvement in the user interface. We will all just have to whether the abuse of making everything Ajaxified. There's a time and a place for it and most developers are not equipped to make this decision correctly. Find yourselves a good UI person and make him your pal! It's been a long time coming for something like this. I'm glad I didn't have to switch to Ruby on Rails - Thanks Scott and Nikhil!

  • Paul, I can echo some of your feelings even though I've spent a fair amount of time with ATLAS. Microsoft always has grand plans and instead of gradually rolling out tools that are easy to grasp and integrate, they push out new frameworks that require complete re-architecting. And that's what bugs me about ATLAS.

    There's lot to ATLAS, though, and to give Microsoft credit they are providing a lot of different options for approaching AJAX development that ultimately put you in control and let you choose what level you want to work at. If you want to go low level and do your coding at the JavaScript level and use ATLAS as a service level interface you can. Or if you want to go full bore, using server side controls that generate client script markup - you can do that too. There are a lot of choices there. Then there are the server controls that allow you to use existing page layout and controls and AJAX enable them which is very heavy on wire traffic but can still be an excellent solution in a number of scenarios.

    I see two problems here - there's a lot to this, and while it all demos real nice, right now at least if you do real work you hit the limitations of abstraction very quickly and a lot of these dead ends seem to simply have not been thought all the way through. A lot of folks are going to start down that path and code themselves into a dead end because it looks so easy nobody'll bother to research what works and what doesn't.

    The client side architecture is hideously complex and difficult to wrap your head around too. If you think control building with ASP.NET in general is not exactly trivial, wait til you start building ATLAS enabled controls - lots of fun especially with the current state of documentation.

    It's a mixed bag, but it's early. And maybe that's part of the problem. As usual many people see ATLAS as the only solution even though it's not even in beta just because it comes from Microsoft. There are other viable choices out there that are easier to work and in full release today...

  • "There are other viable choices out there that are easier to work and in full release today..."


    I find it interesting that people have these reactions.

    1. javascript is ugly and painful. Powerful, no doubt, but problematic
    2. asp.net 'postbacks' - this constant server side trip which reloads an entire page, regardless if all you need is one section updated...

    ...that is the key, Atlas gives you a way to do partial rendering. Smooth transitions - ie. you sort a gridview - the entire page reloads! Instead, with the Atlas updatepanel, only the grid reloads.

    Tell me what is bad about that???

    I think it's just a different world - users want a better client side user experience.

  • (dead conversation, i know)

    i got the same feeling too, though i still can't articulate it well enough.

    what do you think of anthem.net? so far that's the implementation that's matched my intuition best...

  • To some extent, I think that the issue revolves around a couple of different points:
    (1) How comfortable are you with HTML and Javascript?
    (2) Do you trust Microsoft to do the right thing for cross-browser use and to not write bloated code?

    Admittedly, Visual studio 2 is a LOT better than 1.1

    My answers to this are (1) Very and (2) NOT!

    In general, I feel the same way about Visual Studio and the Web controls. Do I NEED someone or something else to write HTML and Javascript for me? The answer is, again, NO.

    But I date back to before Netscape 1, write Javascript and HTML in my sleep and do not trust Microsoft not to try to trap developers into doing things in a way that precludes using other browsers or tools. Don't get me wrong, I like and use Visual Studio 2 and data grids and lists can be really time saving. However, once you try to do something unusual with these timesavers, you may find that it is (a) difficult and (b) result in a really slow process.

    I have heard that Atlas integrates really well into Visual Studio and makes Ajax development very easy. If you love web controls, don't like to write Javascript, or even HTML, then Atlas is likely for you. If you like more control, then maybe one of the other libraries is better. Personally, I have been using AjaxPro.NET and do not see an overriding reason to change.

    These are 'comfort zone' decisions, though, so if you love Atlas, do not be surprised that others may not.

Comments have been disabled for this content.