Have a look at the Windows design some more? It's pretty extensively studied and documented. A "this is like that" article is a hint that if you wanted to learn more about this, you could also learn more about that.
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.
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...
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?
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
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....
Carbon moved the "giant switch statements" out of the views, inside the library (edit: maybe, even into the kernel. That way, application processes only would be woken up if they really had work to do). Controls had to tell the library what events they were interested in, and what function to call to handle them.
Advantage was that the system didn't need to fire zillions of events to controls that didn't do anything with them (for example, few controls respond to "mouse moved" events, but if the system doesn't know that, it has to send corresponding events to a top-level window, the control below it, the control in the control below it, etc.). That decreased power usage (at least in theory; code and data accessed could be closer to each other, decreasing cache misses, and there were fewer JSR-switch-do nothing-RTS cycles), and allowed for the system to introduce more high-level events (double-click, triple-click, "mouse entered", "mouse moved outside the area of the control", etc) without decreasing performance; disadvantage that registering the exact set of events one was interested in wasn't fun (especially because, in those days, one needed to pass universal procedure pointers to the Carbon library to register handlers)
If you have lambdas and reflection, the latter can be made free for programmers. So, I guess that is an area one could look at. I'm not sure the gains will be real in a system where the windows live in a browser window, though.