Application Framework == a Code Playground
The key theme we took away from the talk is captured in the first slide diving into the content of the session, “An application framework is like a playground for your code, provid[ing] structure around otherwise unrelated activities”. This idea was expanded on throughout the content that followed, which included the use of some very entertaining graphics. The playground analogy was elaborated on to introduce the concept of “modules” as each physical part of a given playground. Modules are most accurately defined as an independent piece of functionality, but check out the slides for more details and a very amusing and well fitting description on slide 11. The other common theme across slides, which developers are well familiar with, was loose-coupling and was introduced as part of the necessities for a module.
Any interaction the module needs outside of it’s own isolated world needs to be done in a sandbox (playground analogy), which is a secure and consistent interface for allowing communication across modules or beyond. Zakas then explained the great need for investing proper time in determining the correct interface, as the sandbox is a somewhat permanent connection between your application core layer and the many modules that may arrive in the future. The application core was described as the manager of modules, or as I like to think of it, somewhat like Tom from the movie Office Space who would take specs from customers to engineers; with specs being data that your modules (in the analogy being customer and engineer) need to share with each other. Of course, in a scalable architecture we need a Tom to ensure loose-coupling between modules, as Tom will guarantee that modules do not need to know about each other. The application layer also ensures that getting rid of one module does not affect the overall or other individual module’s functionality.
Loose-coupling was also emphasized as part of the connection between the base library (YUI, Dojo, jQuery, etc.) and the application layer in use, as there may be a need to swap out libraries. The job of the base library is to provide basic functionality and normalize code across browser differences. In reality libraries often do much more, which led to questions at the end of the talk in regards to how one can properly abstract out a complex component such as data table (grid) and ensure proper loose-coupling. Zakas in response suggested that a common interface be created between the complex user-interface pieces and the application core, with the interface providing access to only the desired functionality and not the entire set of available API calls which may or may not be useful.