Gerald Bauer
2005-04-18 18:12:31 UTC
Hello,
allow me to highlight Ben Darlow's comments on MSXAML. Ben writes:
The interesting thing that I can deduce from the comments above is that people seem to
think that Avalon/XAML is misunderstood. Okay, so it's not XUL, it's far more than that. It
attempts to integrate presentation and functionality all in one layer. But from all this I get
the distinct impression that the architects of XAML have entirely missed the point behind
separation of data, functionality and presentation that technologies like the modern DOM/
CSS/Javascript or XUL/CSS/Javascript provide.
Not only are these three tangibly separate concepts, but if Microsoft is serious about the
technology being the basis for future application development, then it follows that
different team members would be involved in the three different elements. Having all three
in the same place means that developers need to at least understand all three parts in
order to work with XAML. Comparing this to the XUL model, an individual interface
developer can create the structure of the application by creating a raw XUL document, a
designer can create a stylesheet which gives the interface whatever non-native aesthetic is
necessary, and another developer can create application behaviour through javascript.
There's even the other layer of XPCOM being called by the JS.
Now some of the comments above talk about how we wouldn't need to create XAML
manually, since it could be automatically generated by code or developer tools. This
strikes me as undercutting the entire point behind using an XML-based interface language
in the first place. If the language is so unwieldy as to necessitate such tools, then what
does it say about the language? I'm inclined to believe that using XML is merely paying lip
service to openness and interoperability (as Bill Gates himself recently did); Microsoft still
want people to buy their next iteration of Visual Studio, and you can guarantee that the
"tag soup" of XAML will be far easier to edit and create using the in-house IDE.
The biggest thing that concerns me with XAML is the one that several people (Microsoft
groupies or employees, I wonder?) seem to be denying; that it will form a new web-based
technology. Of this I have no doubt. If any MS executive saw a XUL application being
loaded in-browser (i.e. you type a URL in Firefox and it loads a fully native UI application
with all the richness of interface of a native application), you can guarantee they'd see the
value in such a technology. The potential for shopping sites, customer service or database
management applications which can be accessed via any browser without the need for a
client install is a dead cert killer app. To deny that this is one of Avalon/XAML's purposes
is at best ignorant, at worst disingenuous in the extreme.
Source: http://www.mezzoblue.com/archives/2005/04/14/avalonxaml_f/comments
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com
allow me to highlight Ben Darlow's comments on MSXAML. Ben writes:
The interesting thing that I can deduce from the comments above is that people seem to
think that Avalon/XAML is misunderstood. Okay, so it's not XUL, it's far more than that. It
attempts to integrate presentation and functionality all in one layer. But from all this I get
the distinct impression that the architects of XAML have entirely missed the point behind
separation of data, functionality and presentation that technologies like the modern DOM/
CSS/Javascript or XUL/CSS/Javascript provide.
Not only are these three tangibly separate concepts, but if Microsoft is serious about the
technology being the basis for future application development, then it follows that
different team members would be involved in the three different elements. Having all three
in the same place means that developers need to at least understand all three parts in
order to work with XAML. Comparing this to the XUL model, an individual interface
developer can create the structure of the application by creating a raw XUL document, a
designer can create a stylesheet which gives the interface whatever non-native aesthetic is
necessary, and another developer can create application behaviour through javascript.
There's even the other layer of XPCOM being called by the JS.
Now some of the comments above talk about how we wouldn't need to create XAML
manually, since it could be automatically generated by code or developer tools. This
strikes me as undercutting the entire point behind using an XML-based interface language
in the first place. If the language is so unwieldy as to necessitate such tools, then what
does it say about the language? I'm inclined to believe that using XML is merely paying lip
service to openness and interoperability (as Bill Gates himself recently did); Microsoft still
want people to buy their next iteration of Visual Studio, and you can guarantee that the
"tag soup" of XAML will be far easier to edit and create using the in-house IDE.
The biggest thing that concerns me with XAML is the one that several people (Microsoft
groupies or employees, I wonder?) seem to be denying; that it will form a new web-based
technology. Of this I have no doubt. If any MS executive saw a XUL application being
loaded in-browser (i.e. you type a URL in Firefox and it loads a fully native UI application
with all the richness of interface of a native application), you can guarantee they'd see the
value in such a technology. The potential for shopping sites, customer service or database
management applications which can be accessed via any browser without the need for a
client install is a dead cert killer app. To deny that this is one of Avalon/XAML's purposes
is at best ignorant, at worst disingenuous in the extreme.
Source: http://www.mezzoblue.com/archives/2005/04/14/avalonxaml_f/comments
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com