braindump of Model-View-WebSockets by Garann Means at HTML5.tx

Historically JavaScript is a simple place... we were doing just fine without it for a while... we didn't used to have patterns. We had been doing some single page applications... a system of dependency has a lot in common with single page applications. But how do you scale these apps and how do we modify them. There are some trade offs for this paradigm. Load time can be painful. How do client interactions fit into big picture? Flight is something new for Twitter. airbnb is running backbone on both the client and the server. meteor is Node-based and has both models and messaging. Model-View-Whatever has been around since the 70s and was originally implemented in small talk. MV* in JavaScript follows OOP and stems from a desire to use a good framework. Variations to MVC: MVE ...the e is for event, Event-Driven Architectures. In JavaScript MVE is the nasty code we've all been writing for a long time. EDA views do not correspond directly to models, as you can instead model views on state. MVC is tight triads of models views and controllers and the view bubbles up through the controller. MVP model-view-presenter is another pattern. If you have a really small app, do you need a framework like these? Todo MVC is used as a stereotypical example of a controller. Backbone is more MVP than MVC. WebSockets is its own protocol. It runs on Port 80. It is not Comet. It is bidirectional. Tickers, chat, and creative updates are examples of places to use these. If we wanted to refactor MVC to EDA we need to free events from the triads they are looked into. Chain WebSockets to interface events to include them. Declare a socket to implement it. Hand it a URL. Listen for an open connection. socket.io is a tool for WebSockets. Ad messaging ad hoc to an existing application. One may pipe events to a WebSocket. WebSockets is a tool to use within your pattern not a crutch to replace it.