Some Atlas feedback

Karl wrote some feedback about the eWeek article:

"What's the perception from the ASP.NET team on how interested the developer community is in Atlas? Personally, I’m extremely apathetic about the technology and the hype around it. Since the day Atlas was announced, it’s always seemed like an un-innovative attempt to catch-up. Of course, there’s still plenty of confusion about what Atlas is and why you’d want to use it versus client callback (man, is that still around?) and other 3rd party AJAX providers (Ajax.NET, MagicAjax, …). I played with the PDC bits, and was thoroughly put off by the declarative programming samples – it burdens the development process and seems like an “oh isn’t this cool” when it really doesn’t have anything to do with the problem space being solved.

You and I talked at TechEd. I was writing the AJAX.NET documentation and wanted to bounce some ideas off you about client-callback and ajax.. At that point, Atlas wasn’t publicly known (not sure if it was internally known, since client-callback was still the in-thing). Frankly, the ASP.NET team seemed totally disconnected about the topic, and to this day continues to go down an unclear path.

On July 14th you had a wonderful post titled “Some thoughts about server callbacks and Ajax.NET”, in which you identified a possible alignment issue between the ASP.NET team and average developers. To me that should have sent a red flag to Scott and crew, but I’ve never really seen the topic followed up. If you guys think of things one way, but “most users” think differently, then there’s a problem. What checks have been introduced since callbacks to make sure Atlas is better aligned?

To be fair, my exposure to Atlas hasn’t been great. The problem is, I’m not really sure why I need to bother with it. I just don’t see what added-value Atlas will bring to my already-rich XmlHttp toolset. I realize that part of Atlas is another prototype (prototype.conio.net), and that’s great (assuming I don’t want to use prototype for some reason).

About the article, parts of it deserve to get slashdotted and ridiculed. JavaScript isn’t OO? No exception handling? No inheritance? Googling any of these terms “javascript object oriented”, “javascript exception handling” and “javascript inheritance” results in a number of useful hits. There are other quote-worthy things in that article."

Karl, what interesting feedback that is. I'll forward it to the team.
First, I think you're mistaking me for somebody else as I've never been to TechEd. Maybe we can meet at the Mix conference in Las Vegas if you're going? Otherwise I'm sure we'll have the occasion.
Enable me to disagree forcefully on Atlas being uninnovative. I think it's well ahead of any other existing AJAX toolkit on almost all accounts and it's not even beta.
First, let's talk about the declarative syntax (although it seems like I've had this conversation a million times already but that's fine). Some people don't like declarative languages. We know. It's the same with ASP.NET, and it's the same with XAML. Most people love it, some just hate it. Four things need to be pointed out:

  • xml script is not mandatory. It's just a way to instantiate classes and set properties. If you prefer to do that programmatically, sure, go ahead (same goes for ASP.NET and XAML).
  • Despite critics arguing that declarative syntax is more verbose, just try writing the same code programmatically and count the chars...
  • Declarative code is way easier to handle for a designer. Today you author xml-script by hand, tomorrow designer integration will help you do it in a way no programmatic approach can enable.
  • You may have noticed that client-side Atlas components are significantly smaller pieces of logic than the typical server control. That's because we're currently creating the building blocks for larger logical units like server controls or composite client controls. That explains why for the moment it feels like Atlas forces you to assemble a lot of different little pieces to get a simple thing done. That will definitely change.

But it certainly isn't something that we're forcing down the throat of our users because we think it's "cool". We're doing this because we think it's the right approach and one that's already worked in the past. Better, we've learned from mistakes of ASP.NET and try to improve on that.

Now about this other post on callbacks. The problem I was talking about was that ASP.NET callbacks were aimed at control developers whereas the main demand for Ajax technology was from page developers. These are two very different parts of our audience (even though some people may belong to both). Control developers are usually more willing to delve into technical details, whereas page developers are more results-oriented. ASP.NET callbacks are clearly wrong for page developers. The reason for that is easy to understand: callbacks were created for the team to develop its own ASP.NET 2.0 controls. As for much of what we're doing, we've exposed this API publicly so that other control developers can leverage it, but it wasn't a very universal feature.

That was the main motivation behind my developing the RefreshPanel, an easy way to leverage callbacks for page developers. This component and sample library has been pretty successful despite being only advertised from my blog, and it's been one of the main sources of inspiration for Atlas' UpdatePanel. This is really an area where I think we have listened to community feedback and have acted on it. The first feedback we've had on UpdatePanel is overwhelmingly positive because it's so easy, works well and is completely unobtrusive.

I think we're also going well beyond prototype (which is a framework we have a lot of respect for). The object-oriented work in Atlas is just the foundation for the component and control infrastructure. What other AJAX client framework has live data, templated controls, true separation of layout and logic, excellent integration with the server and good designability?

Let me get something straight about the eWeek article: you're absolutely right when you point out some inaccuracies and of course I had the same reaction when I read it. It's an interview of a consultant by a journalist. There has to be some distortion if you see what I mean, and I personally don't think it's a big deal. True, JavaScript is a lean and smart language, and it's certainly not the toy most think it is (though my preference in dynamic languages would probably go to Python). It does kind of have OO capabilities (in an non-intuitive and almost hacky way). It does absolutely have exception handling (even though that is limited in many ways). So the article is wrong on a few things. I don't think it makes it worthless. It's certainly not a technical article, it's aimed at a more executive public. It sure is nice to us :)

Finally, to answer your first question, we're getting a lot of positive feedback on Atlas, and the community is actively discovering the technology even though it's still pre-beta. See for yourself the activity in the Atlas forums:
http://forums.asp.net/default.aspx?GroupID=34

But any feedback is useful to us so keep it coming.

Thanks,
Bertrand

3 Comments

  • You know, that's exactly the kind of feedback we need. If a feature is not covering your most common scenario except by having you jump through loops we want to know and we'll make that better.

    I'll definitely follow-up on that and either post an equivalent sample or make sure this is addressed in a future release.

  • I have discovered the problem:



    Master pages.



    When I use regular pages, the clientid's work fine.



    When I use master pages - ie. a cross page post it changes or rather creates it's own id.



    TextBox txtName = PreviousPage.FindControl("txtName") as TextBox;

    TextBox txtName2 = PreviousPage.FindControl("ctl00$ContentPlaceHolder1$txtName") as TextBox;



    The top example fails, the second works with a master page.

  • Maestro, we ARE providing better OO support for JavaScript (namespaces, interfaces, enumerations, etc.) and we ARE using JSON on the wire (there are JSON.serialize and deserialize methods client and server side) so I'm not sure what you're referring to.

    Also, the bug you're talking about seems to be coming from most browsers only allowing for 2 simultaneous connections to the same domain but it could also be the batching code that we have in place that will become optional in future releases. But without more details, it's hard to tell.

Comments have been disabled for this content.