Architectural Drivers

My apologies to the reader if this sounds obvious.

Application software is now delivered over the Internet.  An extreme type of software delivery is the web-application. One points a browser at a web-site, Javascript is downloaded as it is needed and the application runs.  This type of delivery is quite popular for the following reasons:

• The software supplier is dealing with a single version of the code.  Bug fixes and enhancements are immediately available to all customers.  Support is greatly simplified.
• The software is not stored on the user's computer. You have to access the server each time you use it.  This is basically what enables the entire SaaS business model.
• There aren't that many client machine architectures, i.e. browsers.  It may be a bit ugly but it is not as bad as needing to compile a new binary for each machine.  Technology is not getting in the way of addressable market.

Application delivery times are pretty much a function of the application size and bandwidth.  Somewhat interesting, mobile applications operate in world where repeated downloads of large applications are both slow and expensive.  One installs a client application on a mobile device to minimize both application start time as well as the cost of bandwidth.

The ramification is that what is valued in a web-application is different from what is valued in a mobile application.  This results in fundamentally different technical approaches.  Someday they may be harmonized but that day isn't today.

Since a web-application is download-when-needed, the part that is downloaded to the client is mostly concerned with the user interface.  Server response times (latency) aren't fast enough to run highly interactive UI's over a network.  That work gets done in the client.

Some consequences:

• People try to minimize the amount of code downloaded.  You'll see people publish stats on the size of their Javascript library as the size impacts page-load times.
• One minimizes the amount code downloaded by not putting things there you don't immediately need
• Focus on UI, leave business and domain logic on the server
• Within the UI, focus on interactive UI and leave static presentation on the server.
• Javascript libraries become page-specific.  Yes, the wheel of reincarnation has spun and we are managing our own overlays.
• The server has multiple roles and functions.  It not only has to deal with business and domain logic, it is also implementing portions of the presentation layer.  The server portion of the presentation layer is typically implemented using a templating system.

Most of the development frameworks out there miss this fundamental truth.  Languages like PHP are great at templating but don't help at all with Javascript.  It seems that other frameworks (e.g. Rails, Microsoft's Razor) try too hard to use "just one programming language" and neglect highly-interactive UI's as those UI"s need Javascript.