One of the reasons Macromedia Flash is so problematic and on its way “out” is that it was always a plugin. It does not have direct access to the browser’s DOM, nor do scripts on the page have access to the internal DOM within the Flash object. They are two separate entities, running in two separate threads. Flash, being somewhat “dangerous” because of the kind of functions it can potentially expose, is executed in a “sandbox” which is supposed to keep it from doing any damage to the system. If Flash was properly designed, it would simply be an “engine” that offered accelerated rendering, advanced animation functionality, and new DOM object types, and it would have exposed those functions and types to the DOM. Developers could then script using those advanced functions using JavaScript instead of ActionScript, and they would be able to utilize the new Object types. In addition, since all Flash objects are actually within the browser’s DOM, the Flash functions could potentially work on ANY HTML Element, be they tables, div’s, span’s, etc. Imagine the possibilities, the richness of the documents we would get. The “Web” would be so much nicer and more advanced. We could have had Web 3.0 back in 2001. And I argue that the VIDEO element, out of lack of necessity  would probably not have been invented if Flash had just done this one simple thing, of exposing their functionality as functions and object types within a browser’s DOM, instead of keeping them separate in their own proprietary container that nobody can touch.

I see this as parallel to the way current Window Managers function alongside X11. Instead of introducing specific behavior into the core window managers, I would instead just expose raw functionality. In other words, Animation functionality, Effects, Shaders, Object Types, etc. And I would then allow scripting it all via Scripting Engines that would plug into the DOM. You could have packages that define the UI/UX language, that are written in either JavaScript or ChaiScript or really any scripting engine. As long as they have access to the “DOM” (In this case being Desktop Object Model), they can manipulate the objects on the desktop, and use the functions exposed into the DOM by the various plugins and by the WM itself. One could easily produce a Metro UI clone, using a bunch of scripts that manipulate the DOM. Or really any other UI, BeOS, Amiga, anything really. It could be 3D, or 2D, or even 4D! It could even be networked into some additional nodes on the cloud where some of your desktop element could live on. Once you have a DOM which can be serialized into JSON objects, the potential is infinite. Imagine how simple it is then, to share an application across networks? Yours looks the way you like, with your graphics and eye candy, but the substance, the “juice” of what you’re viewing, is transferred to someone else’s desktop, and there, his own UI Scripts apply their own animations and eye candy to the same application/content, and they see it the way they like.

I believe this is where Desktops will eventually go. There will be a DOM (Desktop Object Model), there will be “plugins” that introduce eye candy features, shaders, effects, maybe physical modeling effects, plugins that fetch data from the net and inject them into the DOM, etc. And there will be the underlying engine which just lets those plugins access the hardware via some HAL. This is the kind of desktop I would love to have in the future. A desktop where everything can be scripted. Where I can decide myself how windows are maximized, and where I can decide that if some window is maximized, I want to trigger certain specific actions, like lower the priority of all other applications, if the window I just maximized is a Media Player and I want to watch a movie without other apps bothering me or using the CPU too much (Just one example, I’m sure people will come up with amazing things once they have a DOM and plugins that allow scripting the DOM).