During the Scandanavian saga of Nokia announcing plans to kill Hamlet, Robert Scoble tweeted a link to a blog post purporting to explain why Nokia developers were so aghast at the death of Hamlet. Basically it said that devs worked hard to be the big man on the app store and that a switch of the development platform would produce an unacceptable loss of prestige among their development community. (In this case I actually see it as a problem where the new platform has no chance of producing a greater market than the existing platform and therefore is a massive step backwards in terms of possible audience for the apps produced.)
The real place to look for developers, whose income from lectures, books, and freelancing is dependent on being big man on the app store, is the web development community. Web dev tech is the one most likely to stagnate in the familiarity trap.
I'm sure the naysayers will exclaim that HTML5 and the WhatWG have re-energized the web and web dev tech is moving faster than it has in a decade. As Lee Corso would say, "Not so fast." A classic example of the familiarity trap at work in web dev tech is SASS 3 introducing the SCSS syntax as the new default. And if web browsers *cough*IE and WebKit*cough* properly supported the HTML 4.01 object tag by rendering natively supported objects, then there wouldn't be much of a need for a video or audio tag, since all of the major browsers have introduced native support for audio and video codecs that would have been unthinkable outside of plug-ins in 1999. (The WhatWG's HTML5 spec actually muddies the water considerably on what browsers should support natively with the object tag. I'm guessing this is due to making sure Google's WebKit browser is classified as supporting the WhatWG HTML5 object tag, while not actually supporting the W3C's HTML 4.01 object tag.)
The familiarity trap is the raison d'etre for the WhatWG. The HTML gurus would be back on the bottom of the heap having to learn a new tech (XForms) and that was unacceptable. This rejection of XForms led directly to the pre-cursor of the WhatWG. Strangely, some of the most widely supported HTML5 tags, like the section and address tags, actually were derived from the XHTML2 spec.
XML is one of the web pundit's "conventional wisdom whipping boys". Kind of like Nokia's Symbian operating system, all of "the right people" know it's a dead tech to be avoided at all costs. "It's slow, bloated and hard to work with, " actually translates , "I'm not familiar with the tech, the libraries to work with it are poorly documented/designed, and type checking/santising data is somebody else's problem." Go check the xml library function pages at php.net for documentation, examples and user comments/code fragments. Is there an XML equivalent of PHP's htmlentities to properly encode ampersands and the like? Yes, but only by using the tidy library. *bangs head on desk* Check out this exchange between Eric Cestari and Jack Moffit on the strophe mailing list on xml vs json in the XMPP->Web interface BOSH. Even extremely smart people are capable of falling in to big holes due to the familiarity trap.
I assume that perhaps the parse time for XML is really bad or something, or else this is the classic XML parsing problem that you are building a new parser for every packet?
I hear the naysayers, "But the cowpaths are just there and the WhatWG are just paving them." Once again, as Lee Corso would say, "Not so fast." One of the major features touted for HTML5 are the new "semantic" tags like nav, section, article, footer, header, aside, etc. These came about due to a parsing of Google's web database for the most commonly used terms for divs and then a desire to encode these as new tags. This is being done in the name of providing web pages better semantics, but given that it's nearly impossible to accurately define what an article or footer should be. Of course if the WhatWG had really been interested in paving cowpaths, they would have looked to existing web specs for inspiration. For example, the WAI-ARIA spec provides the role attribute to define functionality for parts of a web page. If the HTML5 spec wanted to pave the cowpath properly, it should have built on the WAI-ARIA spec's use of the role attribute rather than inventing new tags. Encourage uniform use of <div role="nav"> across the web and you have a fully accessible/backwards-compatible solution. Another spec much maligned by the WhatWG is the RDFa spec. RDFa provides embeddable semantics that allow extensible shared vocabularies. One of the oldest of shared vocabularies on the web is Dublin Core. You love librarians providing you an easy way to search for books and magazines. Librarians love to have an orderly way to exchange data about books and magazines in order to ensure that your search can not only find the books in their library but also provide the possibility for inter-library loans. Dublin Core provides a shared vocabulary to describe basics like Title, Author, Contributor, Publisher, Date Created, Date Modified, Table of Contents, etc. Another shared vocabulary with growing interest and that would have made a great cowpath for the WhatWG to pave and extend is the SIOC (Semantically-linked Online Communities). Why? SIOC provides a shared vocabulary to describe parts of Online Communities. Instead of the semantically-dubious article tag, the web should have been pushed to modify their templates to use SIOC's vocabulary. Is what you're reading now an "article"? Maybe. But I definitely know it's a "blog post" on a "blog". Is a tweet an "article"? I don't know. But I do know it's a "microblog post". And the context view of microblog posts and replies is a "thread". Go crazy like Sheldon from The Big Bang Theory and tag everything. Image Gallery? Got ya covered. Wiki Article? You betcha. Best Answer? Shall we just tag Robert Scoble with that and save the rest of the net a lot of kvetching? And the best part of this is by tagging your blog post as a "blog post" and tagging your name as the "author" and the created date as the "created date" and your copyright license as "license" and post content as "content", search engines like Hakia (and every other web user armed with extensions for Firefox and Chrome or a library like librdfa for Python) can easily parse out all the important data without fancy Google algorithms hunting and pecking around inside some semantically ambiguous header or footer tag. Oh wait... maybe there's a reason Google didn't want the WhatWG to follow this cowpath.
Go check the books and articles on HTML5 multiplying like rabbits. WAI-ARIA and RDFa aren't part of the hard boiled web devs toolkit. That's unfamiliar territory and often the object of outright hostility from the Kool Kidz in the WhatWG Wonderland. (cf Issue 120 of the W3C HTML WG). Instead I get the sense that the WhatWG and the HTML5 fanbois are rapidly painting the web into a corner via the familiarity trap, rather than re-evaluating whether the tools and syntax they've chosen are the best or simply the tech that's in the comfort zone of the kool kidz and what keeps them on top of the web dev heap.