Nikhil has recently published a couple of interesting posts about the December build of Atlas. I’ve already commented on their resolution to keep page life cycle intact. This time I’d like to offer my opinion on the client-centric approach, as Nikhil dubs it.
I think it’s a bad idea to embed relatively large chunks of XML into web pages for the purpose of “orchestrating” interactions among page elements. Atlas Quickstarts have plenty of examples of this approach. Nikhil gives an example too and says:
As you can see, no messy event-handling code or initialization/hookup logic in the page itself. The idea is this XML Script will eventually be designable and tool-able, so you won’t have to author it by hand, like I just did. I love the ability to encapsulate code so the page is fully declarative, and Atlas enables me to do that on the client as well.
I see a couple of issues with this.
Bloated Pages
XML is verbose. Embedding so much XML Script markup into a web page makes it much heavier. The reason we keep JavaScript code and CSS in external files is because they get cached by browsers on the client. Hypothetically, you can move XML Script into its own file, but it’ll work only for static pages. Dynamic pages would have to embed it.
It is my firm belief end-users should not be punished for large pages. In an earlier entry on view state I said the question of whose responsibility it was to pay for view state was an important one. We tend to inflict view state on end-users. The same thing goes for XML Script.
XML Script is not something expected of you to read and understand. It’s a markup intended for tools, not developers. As such, it has no place in web pages.
Overrliance on Tools
Overriance on tools is what bothers me. I see more and more of it coming out of Microsoft these days. Although it’s great to have tools that take routine work off your plate, these tools are valuable only if you understand the underlying syntax.
Tools have their own agenda, and if you need to deviate a little, you’re stuck: the tool won’t let you do it, and you don’t understand the syntax, which is why you used the tool in the first place.
For example, I could write .NET code in Notepad2, but Visual Studio—which I both love and hate—makes it easier to maintain mountains of written code. I do understand what it does, and I can do the same tasks by hand if necessary.
On the other hand, the shear size of ASP.NET 2.0 sends a clear message: you’d better posess a good tool to cope with it. You can see the writing on the wall when Visual Studio, a product that’s supposed to make money, gets commoditized. The Express edition is free, and there are a thousand and one opportunities to get a free copy.
Having great tools is essential, but building tools upon tools upon tools is crazy.
Debugging
Debugging JavaScript is a hassle, but it’s doable. You’ve got several tools at your disposal: Mozilla’s JavaScript Console, DOM Inspector, and a full-blown debugger Venkman. I don’t quite see how you can debug real-time interactions among controls when it’s being handled behind the scenes according to XML Script declarations. Time will tell.
Conclusion
So far Microsoft has been taking a heavy-handed approach with Atlas. I don’t understand why bloat is preferred to simplicity in this case. Atlas is still in its infant stage, but I hope, in the end, we’ll get something lean and elegant, not a bulky framework with proprietary scripting and markup.
