Rethinking This Whole MVC Thing

As time goes on, I find shifting one's mental model back to "simpler times" can be a handy trick for breaking out of self sustaining ruts. If you look at the current state of the art in web frameworks you'll see:

And that's about it.
What is so telling here is that no thought goes to behavior, the system performs a set of functions and does it well for the limited use case of producing different sets of strings.

If we move to the next level, we see applications written in flash or JavaScript, which procedurally generate content from data on the client side:
This model is slightly better in terms of it's caching characteristics, in that most commonly used resources are mostly static. The data requests using XHR always require additional engineering to scale and make performant. Partitioning, sharding, and replication strategies try to address the concurrency issues.

Beyond that we enter into a new world of actors and message passing. Anyone familiar with building applications in Erlang has this basic model in their head. Rather than treat the application as a client and a server, we have a tree of servers each of which is slaved to its parent in a supervisory tree. Communication between peers occurs through sending messages to a pid reference or proxy. Well named resources often broker communication to child processes who do the dirty work.

My current web framework work is based on this principle. Rather than an application code router which acts as a dynamic dispatch (or switch statement), I have a message router that routes messages to 0 or more recipients. Each component communicates with its parent in a supervisory tree of routers, with transparent proxies bridging the gaps between "client" and "server" code. In this model every button, every backend process, every data store is just an actor who responds to messages. Since the message is the medium of this program, state is the collection of inflight messages and the internal state of every object attached to the messaging system.

The details of implementation are pretty trivial, but the ramifications of the approach aren't. Using websockets and transparent bidirectional proxies like Onomatic, one can route communications between clients. Rather than building a backend infrastructure, the network serves to merely manage communications between peers (like the telephone). And this returns us to a simpler model from a simpler time.

The next trick is even simpler:
If you look at Phos you will see the conceptual basis right there. Keyboard is an object which sends messages to all objects that respond to key events. Mouse and touchpad work the same way. In my new framework, these objects can pass messages to any object anywhere within the network including clients on other machines. These same messages are also sent to models which may or may not alter their state based on the messages. Likewise other behavior monitoring objects synthesize new messages based on the flow of messages which lass them. Beyond the world of MVC is a world of pure objects passing messages across the Ethernet.

It is a happy land.