title: What is the Interface-Compute pattern?
body: <p>I've been seeing recently lots of "speculation" and small talk on this particular pattern (since I started to learn <em>Dojo toolkit</em>) but can't find any clear info on that matter. Some say, it's a solution to the frequently and "harmful" (<em>they, not me</em>) MVC pattern. I list some MVC "common" big picture problems solved by Interface-Compute. I found <a href="http://bdframework.org/docs.html" rel="nofollow">this site</a> and read about it, but just can't get the big picture about the pros/cons.</p>
  
  <p><em><strong>Input/Output</em></strong></p>
  
  <p><em>The view component is defined as a static component, never directly accepting input from the user. This is to say that reacting to user input is handled by a different component than presents user stimuli. But GUI programming environments do not draw a bright line between input and output components in this way: well-designed GUI programming environments are componentized into nested containers of user interface functionality.</em></p>
  
  <p><em><strong>Ignore Browser</em></strong></p>
  
  <p><em>If we consider web application frameworks that purport to support constructing so-called "rich internet applications", the entire framework resides at the server, so, apparently both the view and controller are implemented at the server. This leaves the browser completely absent from the design model. If this is our mental picture of the design, then the browser is left to function as little more than a terminal with nice output capabilities.</em></p>
  
  <p><em><strong>etc...</em></strong></p>
  
  <p>I'm just wondering with all the JavaScript development like Dojo Toolkit, Node.js and some others for slick server side code (I think we might be going into this kind of era and rethink our ways of doing with server-side code with PHP, Java, Ruby on rails, etc.). Plus, it's cool being able to debug both your server and client side code in your browser!</p>