UPDATE: well, it seems like my comment is now online. thanks Scott.
Well, you can say that I do read my blogs during vacations (even though I’ll read it only once a week)…
Yesterday, I was reading through Scott’s posts and I’ve found this post: Atlas July CTP and the Latest ATLAS Control Toolkit. Normally, I wouldn’t comment on this kind of posts, but yesterday I was on a good mood and so I decided to add a comment to Scott’s post. I know that Scott is the owner of the blog, but I really didn’t like to see my comment being discarded just because it doesn’t “praise” the ATLAS toolkit control. So I’ve decided to write this post where I’m going to explain why I completely disagree on the path that is being followed by the ATLAS team (at least here I think that the post is safe).
Before going on, there’s something that I must say: I really enjoy ATLAS and I think that it can be a great framework. Having said this, I really think that the team is not doing a good job with all the feedback that is being given by many people which have been using it and I do also disagree with the way the server controls are presented to programmers.
So, why am I not happy with the new release of the ATLAS? Well, for starters, most of the known bugs haven’t (AGAIN) been fixed. Most of them can be easily solved, but the truth is that they’re still there. In fact, if you look at the bugs description, you’ll see that most of them have code that reproduces the problems and most of them have even suggestions on how to solve them. Since many exist since the March CTP, it really makes us think if we should continue to use CTPS and help the team with the bugs (what’s the purpose if they’re not fixed?).
What I’m saying (and I really think that I’m not alone here) is that we want those bugs to be fixed ASAP! I don’t want more controls on the ATLAS toolkit! What’s the purpose of adding any more controls when the basic ones are still broken (like, for instance, the autocomplete extender control)?
Another thing that bothers me (a lot!) is seeing the way the UpdatePanel is presented to programmers…yeah, at first look, it really looks like it “will save the world”! It’s just a pity that the team doesn’t also warn about the disadvantages related with its usage. Hey, I’m not saying that they’re evil; like everything else, there are advantages and disadvantages related with their usage. However, if when you present it, you only speak about its advantages, you’ll get a lot of guys adding panels to a page so that they can update the content of a label (something which, most of the time, can be done with pure javascript, without even performing a postback or, if you need server info, with the help of a web service call).
I can understand the strategy of the team, which is focused on the server side approach. However, I still believe that this is the wrong approach for most of the cases. I guess that building an AJAX page without knowing anything about Javascript or CSS might be appealing...but not something that will work in the long time or if you’re building a real project (no, I’m not talking about the “hello John” kind of page!).
So, what do I want (and I do believe that there are others out there that think like me): we want a good infrastructure without bugs, and only then we will need the so called “cool atlas toolkit controls”. Until you solve those known bugs, please don’t come telling us that there are new cool controls that will do everything for us. Oh, and while we’re at it, most of us are still wondering why you guys have called these last CTPs as bug-fixes (if you notice, you’ll see that the June CTP introduces a bug fix which really introduce other bugs to previous working code – yep, this is on the unofficial bug list post which has been around for some time on the ATLAS discussion and suggestions forum).