I made the decision to use Atlas on our project, despite some earlier doubts, and I am paying for it now. So far it has been nothing but trouble. We have run into multiple bugs, strange behavior, and conflicts with our existing ComponentArt controls. I think what bothers me most is that unlike some of the simple or open-source solutions I don’t even know where to start with tracking down or fixing these bugs. At the moment we are having to work around these issues by doing things like turning off viewstate validation or turning off debugging in the config file or all kinds of ugly work-arounds.
Another thing that bugs me is that Atlas seems exceedingly fragile. For instance, when creating an autocomplete textbox you have to be sure and name the parameters in your service the exact right thing. What if you need to pass an extra parameter along? Too bad, you have to hack it using something like querystring. It’s stuff like this that re-enforces my belief that the only proper way to build a good framework is by extracting it from an application. If you built a real application you would realize that you will need to pass in additional parameters for an autocomplete textbox.
Right now I am trying to decide if I should cut and run and retrofit our app using Ajax.Net Professional before it’s too late or hope that the next version of Atlas is better.
-James
{ 17 comments }
I LOVE AJAX.NET Professional! I would highly recommend jumping over it to if at all possible.
I have implemented functionality that returns HTML fragments as well as DAOs to the client and both work fantastically. I love being able to return a DAO to the client, update its values from the edit form, and pass it back to the server for saving. But pulling down HTML fragments for re-rendered DataGrids and whatnot has been invaluable as well.
Are you posting questions in the forums or listservs as you run into question or issues?
There are a lot of folks who can help you there if you ask. Feel free to send me mail if you have unanswered questions I can answer for you.
Thanks,
Scott
I think Atlas has been released to the public too much early, while having still too many weirdness to be employed in a real project; I’m pretty sure it will improve considerably in the near future, presumably eliminating those weird bugs that are so hard to debug.
Atlas is still a CTP. I would expect lots of problems.
I think a lot of the problems you may be running into may be due the learning curve. IIRC, people complained a great deal when having to learn the new paradigm of C# versus traditional C, but it was just due to the fear of change.
I’ve been using Atlas since the PDC release last year and it now is in use on every one of my apps with great results, but I had to do some fighting over time to get it to work properly. That being said, it’s coming along greatly, and if you compare it to the other popular AJAX frameworks out there (prototype, et al) it’s progressing very nicely, with great support from the .NET community.
I might recommend the Rough Cuts book on O’Reilly about Atlas. Very good for understanding the inner workings of the Framework (and use Scott as a resource as well.)
We made the decision to steer clear of Atlas and decided to try using the Google Web Toolkit (GWT) for our frontend. We continue to use Asp.net pages in the middle tier and passing JSON back and forth from client to server. Now, I can imagine any other way.
Scott,
I will send you a list of the stuff we have encountered. Most of the bugs and issues have been confirmed through the forums, maybe we are just trying to use Atlas too early in it’s release cycle.
Jason,
I don’t think its a learning curve issue, I just don’t think it’s ready for prime time. I think it’s also very external web focused and not alot of thought went into business application scenarios.
Hey James,
first off, classic reading on this blog…much more interesting than mine in general.
secondly, loved your book “Visual Studio Hacks”..think we still have a copy floating around the office somewhere, if it hasn’t been “borrowed” permanently by somebody.
lastly – well here’s the gripe…i’m slightly surprised that you’ve actually gone and used a CTP release in a production environment/critial application (or if it’s a commercial application)..i mean, you should seriously have realised that a CTP release is not even close to being a stable release, or, rather stable enough for what you’re attempting to use it for.
I think it’s a bit shortsighted to actually blame the framework when it’s not complete yet….the choice was yours…”do you use a CTP release or don’t you”…you made an educated decision and it backfired..
very simple…
Brian,
I thought having a Go-Live license meant that the framework was actually ready to use, I was clearly mistaken and I definitly take responsibility for that.
I completely agree that this is my fault.
I am not blaming the framework for my choice, I am just saying that I think it has some major problems.
James,
Maybe expanding on this post would be beneficial to everybody..
how about posting the problems you encountered and we can learn from it?
I didn’t mean to come across as a whiner, i was just genuinely surprised that you’d actually made the decision, knowing full well it was in CTP only, to implement it into your project..
Well, it isnt the center-piece of our project or anything. We have just been trying it out. It is probably only used on 3-5 pages at the moment in a 200 page application. That’s why I am looking at cutting and running. I am going to work up a post of the issues we have had and expand on some of the basic issues I have found as well.
James, I think you made an excellent point about the business application vs. external client-facing app focus. I think there is no question that it’s external web oriented, especially the tools in the Toolkit.
I’ll echo other comments here, why not post some of the things you’ve run into? We’ve probably already dealt with them and have found workarounds/fixes.
Excellent…i’m all ears
Crap, I hit the button too quickly.
I was going to add that I think MOST AJAX apps tend to be more for external web use. I don’t think AJAX is really that necessary for most business projects. For example, my main app is one that is business oriented, but client-facing, and as such, the improved UI and speed that comes from using Atlas is very welcome. For one that is a mainly intranet app, it’s probably of much less value. It’s that whole tradeoff of taking time to work through imperfect code in the CTP (which I might add has come a LOOOOOOOOOONGG way from the PDC release nearly a year ago) in order to get what are really niceties, moreso than necessities.
Hey Jason,
I don’t want to steal the picture from James here – but to a larger extent i’m of a different opinion here.
Now, with nearly any application, i would say that the visuals are what appeals to 90% of the users. Having a rich interface which is non-intrusive, anything but clunky, responsive and intuitive is of a major importance to an application. Whether it is an internally facing application or not – it still matters.
100% of the work i do is internally faced these days – don’t deal with clients as we’re busy enough as it is with internal projects – and even if they are only internally faced applications, such as intranets, the user experience is just as important as if it was client facing (commercial, corporate website, e-commerce, banking etc). a user is more liable to be productive if his/her tools are pleasing – aestetically or functional..but the aestetics are becoming more and more important.
at least, IMHO, that’s the case…
I agree with Brian, I think AJAX can be even more important in an internal application. Most internal apps are replacing windows forms or green screen applications so they need the responsiveness of AJAX to give their users a similiar experience.
The AJAX screens I’ve done to date are for internal applications (mind you we have several thousand users), but it’s a business app. The AJAX benefits for the screens were just like what you’re saying James… pull off a rich, responsive UX within the browser.
The screens we implemented AJAX.NET Pro for have heavy use of both HTML fragments and JSON. Being able to add a new record and have it immediately show up in the list, or edit an existing record and see the row get highlighted as updated right away is fantastic for the users.
And we actually took functionality that had been previously split into 2-4 screens and combined it into one, because we’re able to more easily replace sections of the screen quickly… combining tasks and reducing the steps needed to perform common business processes was a true win.
I think AJAX has more of a place in internal business apps than public-facing. You have more control of your environment so you know your users can take advantage of the technology, and you can save your users time by using it.
My consideration of Atlas was very brief as the project is still based on .NET 1.1 and will be for some time to come. (It’s roughly 700 screens, so a conversion would be quite costly, even with the Web Application Project available). But from the demos I had seen of the Betas of Atlas, it seemed somewhat limiting, like the other server-centric frameworks in my opinion. I really liked the client-centric frameworks for their flexibility.
Comments on this entry are closed.