Microsoft's focus with ATLAS seems to be on the XmlScript syntax primarily. Nikhil posted a nice entry that I think sums up some of the good reasons of why Microsoft is going down this somewhat unconventional path of creating a custom XML based markup language to embed into the browser.

For the future too, I guess there's the hope that XmlScript will be more easily generated from a designer so that you can interactively design the script and hook events behaviors and properties together logically. However, we're still a ways off from that.

After playing around with the XmlScript client side ATLAS stuff I can say that I agree with Nikhils assessment that it is a good implementation in that it EXTENDS existing functionality rather than replace it.  The way the extension mechanism works is sweet because it attaches to existing functionality and extends it as opposed to overriding and replacing functionality. The upside to this is that you can add multiple behaviors/extensions to a single control which is difficult to do in a replacement/inheritance type scenario.

ATLAS follows this approach both in the server side and client approach.

One thing that I find lacking in XmlScript is better interaction with raw JavaScript code. It should be easier to delegate out to JavaScript code in addition to the property and event trigger routing that is done by the controls. While I can see that Microsoft is consciously trying to get away from raw JavaScript, it's important to retain some level of control so that low level tasks can still be accomplished. XmlScript is still an abstraction and it can't do everything - providing easier hooks into raw script code would help.

For me personally though I have to say the the XmlScript is hideously complex to write at this point. I think my brain isn't wired for the sort of self referential logic that XmlScript uses. There's tons of pointing back and forth between controls and behaviors that makes this very difficult to get started with. Especially now with documentation that's severely lacking – even though it's a mile above what we had in the previous build <g>. It still needs a lot of work. For one thing the client library needs to be documented not just with what's there but with what the actual parameters and properties actual mean and do.

Right now, writing XmlScript code is very painful at least for me. Even looking at examples of a moderately complex form it's very easy to get lost in all the back and forth between the controls. Control references element on the page, behaviors are attached to a control, with the behavior setting some operational aspects in its definition as well as the control. Often finding where a behavior attaches and what its target is far from logical (a good example are the combinations of HoverBehavior and PopupBehavior). Then there's a binding to a Service or other data, and the binding is then attached to a control. There are A LOT of moving parts even for simple situations!

Take one of the 'simple' examples posted on the ATLAS documentation site for example:

What this method does it calls a Web Service method on the server and displays the results in a text box -  it's the equivalent of a HelloWorld with XmlScript. Now you can look at this and go – Ok I can sort of make out what that markup does, but it's not exactly the type of thing you're going to rush out to and start writing by hand in a hurry especially if you're not all that familiar with the script syntax. For me the only way to do this right now is try to find a sample that's in the general direction and start with that to modify.

And that's a simple scenario. Now imagine you four or five controls interacting with each other in the course of a callback or for regular event binding. For example, I've been fighting with some code earlier that goes out to call a Web Service that graphs stock performance and then wants to display the resulting image in a popup window. There are 4 controls involved and 3 different behaviors. I sort of got it working but in the end the script block was so convoluted that I threw it out and wrote the JavaScript code.

Now if you were writing that same HelloWorld example with pure JavaScript using ATLAS you'd get:

Which one of these do you think is more easily digested? And which do you think you can actually write without getting headache from mental gymnastics? <g>

I think that we shouldn't discount the JavaScript route completely. While what Nikhil says makes sense (designers vs. developers) some of the argument goes by the wayside if you allow for partial updating of data through code. Especially if you still use the ATLAS client side JavaScript library which does much of the heavy lifting anyway. You can still use databinding against a control that you defined but rather than driving the ACTIONS to script it seems still a pretty valid solution to use raw code.

Server Side Support for JavaScript hooks?

BTW, regarding better support for raw JavaScript, the same is true of the ATLAS Server controls. Controls like UpdatePanel and Timer don't have pre and post events that fire that you can use to control client functionality before and after a callback completes which is a common scenario.  For example, I was building a sample the other day that needed to display a label control inside of a scrollable div and automatically scroll the panel to the bottom. This is not easily done with server code but can be easily handled by setting scrollTop on the client. Anthem does have this on most of its server controls and I've found my self using these events quite frequently to quickly disable and re-enable content, to pop up tooltips that indicate action etc. Without this you have to do things on the server that's sometimes more complicated or doesn't hit the mark at all.