In week 3, we got a little farther past the basics and started working with frameworks and servers. Our sprints looked a lot more like usable apps! We built a simple chat app and a music player.

What we covered this week:

Sprint 1: Browser Apps, jQuery and AJAX

Setup
When creating an app on the browser, a few additional things come into play, one of which is package management. Unless you build everything yourself, your app will need libraries and its operation will depend on specific versions. To avoid “dependency hell” (where updating a library for your new app breaks an old one etc.) use a package manager. Package managers are used to install, upgrade, configure and remove dependencies (aka the external libraries/modules your code can’t run without). There are a number of these out there and most have a specific purpose. Below are some popular ones:

• Homebrew – the mac package manager, primarily used to install global executables on your mac
• npm: aka “node package manager”, used for server side dependencies
• Bower – a front-end package manager, used for client side dependencies

Note: both npm and Bower will not only install packages in your project, but also create a file in your project if you use the –save flag. This file makes it easy for any collaborator to download all the necessary packages to their machine.

Rendering what the user sees
Rendering is anytime you go from one representation of something to another (generally a string) using a system. Here’s what happens when a webpage is rendered:

• model data from JavaScript files are turned into HTML
• the browser takes the HTML string and turns it into a DOM (data structure of javascript objects )
• then the browser “render” to the screen (paints)

One important note here is that the HTML is different from the DOM. HTML is just the language we use to communicate with the browser. The DOM structure provides a lot of functionality that allows us to manipulate webpages.

Communication with the user
Processing user input typically means either accepting data from the user and logging it in the database or accepting a request from the user and giving them back some new information on the page. This back and forth is typically handled through HTTP requests and AJAX – here is a great beginner introduction to HTTP requests.

Want to know more internet terms while your at it? Read this networking terms cheat sheet.

Sprint 2: MVC Frameworks and Backbone

MV* Basics MVC stands for Model View Controller – this is a common way to structure and organize code when implementing user interfaces. Backbone, however, is actually an MV* framework meaning it doesn’t include the controller. Below is a brief on how the MV* of Backbone works.

Model instances represent an encapsulation of related data and behavior. They…

• have relationships to other model instances, represented in properties, forming a graph structure
• store data in the .attributes property and provide access to these attributes via the get() and set() functions
• provide an eventing interface (explained below)

Collection instances are essentially a subclass of models. They get the same benefits as model instance provide, but with some array-like features (not all MVC frameworks provide collections). Think of a collection as an array of models – for example, in iTunes a model could be a song and a collection could be a playlist.

View instances represent the mapping between a model instance and a DOM node. They…

• almost always correspond with a single DOM node (but not all DOM nodes have an associated view instance)
• can contain subviews (as properties) that form a tree like structure – this modularizes the view, making each piece more reusable
• listen for DOM events from the user then transform user actions into user intent (by calling methods on the model)
• listen for model events and updates the screen view

The model-view relationship
The model represents the data in your system, this should be the source of truth.  A model instance may be the data source for many (or 1 or 0) view instances a view instance may have only 1 or 0 associated model instance. Whenever the view receives user input, it MUST update the model. The view should only change because the model has changed – otherwise your view and model will be out of sync.

Event Systems
Event systems are how events trigger and invoke change in the app. When a user input triggers a model event, other functions in the model should listen for this event if it is relevant to that function. If/when the event occurs, the listener functions will invoke some action.

A side note on AJAX handling MVC: in web1.0 every time something is changed, the browser pings the server to update the model and re-renders the view. In web2.0 the browser caches a copy of the model which controls the view, it will update the server model as needed which greatly improves speed.

Backbone
Here is an example of an event flow in backbone:
(Key: event (these bubble upward), function invocation (these are delegated downward)) User action
→ view accepts action and transforms into intent by calling method on the model (which bubbles up to the collection)
→ the model is updated and calls related functions to update by delegating downwards to related models
→ view is listening for when its corresponding model updates and then updates itself upon hearing a change

A final note on Backbone: Backbone is a very barebones structure, some even argue it is more of a library than a framework. For a full app, using Backbone means you’ll need to stitch in additional plugins – this flexible approach means you can chose your stack but you’ll also be forced to make a lot of decisions that can greatly impact the performance of your app. Read up on the specifics of backbone through this collection of articles and use this backbone cheat sheet as a reference.

Sprint 3: Languages & CoffeeScript

CoffeeScript is a language that compiles into JavaScript. It adds quite a bit of functionality to JavaScript, makes it much easier to read and allows you to do more by writing less code. If you’re interested in learning CoffeeScript, read the entire front page of the docs (it’s pretty succinct and covers all the basics) and check out the CoffeeScript Cookbook as an additional resource.

Why learn a new language? It helps you think conceptually in pseudo-code rather than a specific language. Learning what is possible in various languages will help you see multiple ways to do things in each language you work in. As a person with a non-technical background that worked in tech, I think one of the most important skills is just knowing what is possible. If you know something if possible, you can always implement through Googling or other research. Otherwise, you’re just dreaming up ideas with no ties to reality.

Where should you focus this week? Learning what MVC is and what frameworks are out there. Here is a basic todo app tutorial with instructions in most frameworks available (including Backbone). You can pick a few and compare their pros and cons as a great mental exercise.