So what do they have to do with my MVWTF apps?
![img/brain.jpg](img/brain.jpg)
Your need for modules is directly related to how much of your app you can hold in your head at once.
The *MVWTF* pattern is appealing for large applications and encourages code reuse & separation of concerns.
# In other words
### Modules and MVWTF Apps
### *were made for each other*
# App Structure
## All too common

In the end, you're left with
*easily traversable*
files that describe their contents, and most importantly, each maintain their own dependencies.
## Templates are treated as dependencies
## I'm so tired of this

Better ways than this to come.
## Styles can be dependencies of templates as well
## Same goes for template helpers and UI Messages
# An *AMD* Tangent
## I prefer *AMD*
and I specifically use RequireJS
I think it's the best solution for modules on the web that we currently have.
The web is *async*.
The plugin system is killer.
*Seriously.*
I'll show you in a bit.
I think it's fine as a
*compilation target*
if you hate the syntax.
But I think a unified target is ideal.
Ember does a good job of AMD as a
compilation target with
*Ember.amd.js*
# FUD | Collisions
There are well established ways to support AMD in every comination of systems.
Check out [github.com/amdjs](https://github.com/amdjs)
# FUD | Boilerplate
AMD actually requires less characters/lines than the popular alternatives.

Not to mention, browser-side code needs minimally an IIFE to not leak.
Use.js helps with unmodified source
of modules that do not use AMD.
I prefer to just add it.
*It's easy™.*
Build.sh has to go away.
We need a complex dependency management solution.
I'm glad it's here now, though, because script-tag soup is awful
I think our dependency management tools shouldn't require load time preprocessing.
but if you want to enhance it at load time, that's fine
I think our dependency management shouldn't *require* us to need to run other languages.
I think our dependency management shouldn't force us to manage dependencies outside of our code.
you'll forget/get it wrong.
ES *Harmony Modules* look cool.
But aren't currently viable/stable. Use those when they are.
I have a lengthy blog post on [my thoughts on AMD](http://alexsexton.com/blog/2012/03/my-thoughts-on-amd/).
So from now on, I'm gonna use *AMD* in these examples.
Nearly everything is possible via other module systems via load time precompilation, but my examples are already implementable in require.js, etc.
## My new puppy: *batman*
## My new puppy: *batman*
## My new puppy: *batman*
## My new puppy: *batman*
## My new puppy: *batman*
# AMD Plugins
## *Transparent Middleware*
Think Connect for node, but for your modules
## How plugins work

We can signficantly *reduce boilerplate* by using this simple feature.
# Getting Rid of MVWTF *Boilerplate*
One of the goals of ES Harmony is to reduce
*setup boilerplate*.
We should have the same goals in our modules.
## A simple example
What can we get rid of?

With handlebars, I can just introspect a template's AST to figure out it's dependencies.
## A simple example
*Ultimately*
you could create a convention to always
have a template with the same name as a view

define({
initialize : function () {}
});

This one is a bit extreme, as most apps can't follow that convention rigidly.
And because a real world example would have other dependencies anyways. But it has a nice effect.
## A simple example
*And since I'm being contrived*

define({});

Backbone doesn't require you to define an *initialize* function.
# Builds and performance
## Plugins as a vehicle for build time
## *static compilation*
There's so much that your app *doesn't* need to do at runtime in production.
## Consider Templates

This includes the parser and the compiler for Handlebars, and must re-run those (slowest) parts on each render.
How many of you are
*precompiling*
templates at all?
## Auto precompilation
We can make our modules do _all_ the work here.

At runtime before build, the plugin is *eval'd*.
At build-time, it is written directly as the module.
## We now have a *transparent* way of
##
* Pulling in a template
* Compiling it
* Resolving all of its dependencies
* Precompiling it at build time
* Adding in introspection and buildtime
optimizations (dead code removal)
## we can go *deeper*
## Templates can declare *style* dependencies
and we can build up only the styles that are _used_.
## We can introspect CSS
and *inline images* as data-uris at build time.
## We can inline the entire CSS block
(including data-uris) and inject it with a *<style>* tag.
## We can bring our entire app down to a
## *single request*
## Static precompiliation is *so cool*
## Dead Code Removal
Use in tandem with *has.js* to enable dead code removal.

This can be *hugely* helpful when doing
specialized builds for *IE* or *Mobile Devices*.
Consider simply a jQuery/zepto profile.
See [jensarps/AMD-feature](https://github.com/jensarps/AMD-feature)
The goal is to have a nice dev experience, but at build time, send absolutely *only* the code that is *necessary* and *precompute everything* possible.