This is off-topic, but I have a question about the Windows 10 shell. You previously said that the new XAML-based part of the shell is written in C++/CX. Why not C#? Is the performance and/or memory footprint of the .NET Framework still not good enough, even with .NET Native?
Yah, sure its got a few new tricks, but in that regards its just another all that is old is new again. In that it basically serializes the CLR where as the old resource fork serialized the windows API.
For another example see the delphi DFM....
Quote (http://www.w3.org/TR/xhtml1/#why)
Document developers and user agent designers are constantly discovering new ways to express their ideas through new markup. In XML, it is relatively easy to introduce new elements or additional element attributes. The XHTML family is designed to accommodate these extensions through XHTML modules and techniques for developing new XHTML-conforming modules (described in the XHTML Modularization specification). These modules will permit the combination of existing and new feature sets when developing content and when designing new user agents.
Quote (http://www.w3.org/MarkUp/2004/xhtml-faq):
If your document is just pure XHTML 1.0 (not including other markup languages) then you will not yet notice much difference. However as more and more XML tools become available, such as XSLT for tranforming documents, you will start noticing the advantages of using XHTML. XForms for instance will allow you to edit XHTML documents (or any other sort of XML document) in simple controllable ways. Semantic Web applications will be able to take advantage of XHTML documents.
The old HTML behaviors would be achieved by XML stylesheets, rendering into HTML4 or XML events.
There were then a plethora of standards planned to augment XHTML with application level.
http://www.w3.org/standards/xml/components
Bindings in XForms for example, http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-ex...
I'm not sure what single catchy word you want here, but that's not it.
Or maybe the poster is just being self-deprecating :p
Nowadays, the event loop is still there under the hood, but it's abstracted away by the UI framework. You are left with independent views that can render themselves, but the raw event loop is exposed as higher level events raised by individual views (e.g., a single "Tapped" event instead of having to handle separate mouse/touch/pen/controller down+up events).
Apps often use some sort of message bus for communicating between non-UI components in a decoupled way, which may or may not re-use the UI thread's event loop. In general, you try to minimize what happens on the main loop, since it can lead to UI unresponsiveness. However, in XAML the main event loop is actually a priority queue, so you can put stuff into it at lower priority than regular input events[2].
1. https://msdn.microsoft.com/en-us/library/windows/apps/dn8946...
2. https://msdn.microsoft.com/en-us/library/windows/apps/window...
Disclaimer: I work at Microsoft, where we're using XAML to build the Windows Shell.