Modular Architectures in JS

JS (programming in general) has a fanaticism problem.

• We invest in one framework/tool and use it for everything
• Alternatives become adversaries rather than learning experiences.

"When you have a hammer..."

• Not only do we shun alternatives, we use our favorite tool for everything.
• When you have a hammer, everything's a nail

Fanaticism prevents us from building the best software by artifically limiting our available solutions.

• By limiting ourselves to singular frameworks or tools, we're missing out.
• We don't just miss new tools by holding on to 'what works.' We commonly leave perfectly good stable solutions for the new and shiny.
• Segueway: but what can we do to prevent this?

Need an example? Check Twitter. Any day. Really.

• There was a blog post this morning generally denouncing modular architectures.
• I happen to really like this response.

Modular Architecture

• We can avoid these by building our apps one piece at a time, without or with a limited overarching framework.

Stop only asking "How is [X] like [my favorite]."

• "How is X like Y" shouldn't be your first qustion.
• It's a valid question, but by no means should it be the basis for selecting/trying a tool.

Start asking "How will [X] make my code/process/life better?"

• We need to think about tools and modules objectively

Be passionate, but not fanatic, about the tools you use.

• There's nothing wrong with being excited about a tool
  • Docs/blog posts, tests, PRs- all great ways to show you care.
• Just keep an open mind :).

Avoid common developer assumptions

• Using a tool just because 'that's what you use'
• Jquery, for instance
  • Not supporting older browsers?
  • CSS animations instead, perhaps?

I'm not saying don't use a framework, ever.

• There's no reason to abandon frameworks entirely
• We need to be way more critical about when to use them.

Consider the following:

• Is it bringing in functionality I don't need?
• Can I bring in outside code easily?
• What's the investment-to-reward ratio?

Proof of Concepts

Building a POC allows you to relatively quickly determine the cost-to-benefit ratio of a particular tool.

• Write more than 'Hello World'
• Consider the tasks you need the tool to accomplish
• Keep your team's eccentricities in mind / don't build in a vacuum.

• a proof of concept can save you a lot of time in the long run
• Just make sure you're actually testing the tool at hand
• Make sure you keep the weird requirements for your team in mind, and enforce them in your POC.

This is usually where I'm barraged with arguments

• I've had this conversation, and this is usually where people stop me.
• I'm going to present the most common arguments I get, and my counter-points.

Modular systems cause spaghetti code!

• This is by far the most common response I get
• But I feel it's a bit of a knee-jerk reaction

• Tying together all the modules becomes an unmantainable mess.
• My favorite framework solves this by including everything OR having a plugin system

• The main point here is that using a ton of different pieces of code makes an unstandardized mess
• By using an all-in-one framework, you get the consistency.

separate module choices from your code

• Abstraction Layers
• Functional Mixins
• Architecture Assistance

• By separating our code from our modules choices, we can make changes when necessary and move quickly.

Abstraction Layers

Abstraction layers mean you can swap out modules without editing every reference to that module

They also mean you can create a consistent style and language for your code

Example: Primus

• Primus gives you one API for all sorts of different socket implementations
• It even makes some of those impls work better.
• Need to swap socket providers? One line change.

Functional Mixins

Augment your code without creating a direct dependency

• I can't go into too much detail here, but if you haven't tried them, check out "A fresh look at javascript mixins", by Angus Croll.

"Architecture Assistance"

Definition of 'Framework':

"the basic structure of something : a set of ideas or facts that provide support for something" - http://www.merriam-webster.com/

• When we consider the definition of the word, it makes a little more sense
• When considering a framework, heavily consider what it's actually giving you: structure? Or a gilded cage?

Good Examples:

• Flight
• Backbone
• Restify

• These frameworks provide structure without fluff
• They do their job well and don't get in your way

What you get

• Swap out modules with minimal work
• Modify abstraction layer, run the tests on your code, done.

• Change you abstraction layer to match your new module
• Test your code, run them when you change modules.

My Framework has everything my team needs.

• I get this a lot from people who already have a favorite all-in-one tool/framework

• Why would I spend tons of time picking each and every module?
• Everything moves much quicker when I use a framework
• My team all speaks the same language this way

• The main argument is time-saving
• The secondary benefit is everyone writes the same style with a framework

This is one argument where fanticism really shows.

I see it often, myself.

• The story of the Ember fanatics
• I gave a talk about Flight
• An Ember fan comes over not 5 minutes after it
• They had re-written an example in Ember, and bragged about how short it took.
• THIS HAS HAPPENED THREE SEPARATE TIMES.

• My reaction: That's great...but you missed my point.

• All-in-one Frameworks tend to have a steep learning curve
• This can mean long ramp-ups to productivity

• Devs can become mired- learning the whole framework to understand any part of the application
• How many files do you have to walk through til your app makes sense?
• Time to first Hello World! metric

Don't hold your application hostage

• Pick the right tool for each task
• Don't settle for one huge library that does some things you need well at the expense of other tasks.

• Considering pros and cons of a framework reads like hostage negotiation
• Instead, find the best tool for each task to build great applications

Third-Party module management is a nightmare.

• This used to the be the most viable argument.
• But we're well on our way to having this handled

We have the technology...

• Node, client-side, we have tools that can help us.

Package Management

• Put how you may feel about Bower aside
• Both of these tools manage your JS packages
• Easy updating, version management, module installation

(Client-side) Module Loading

(Also, ES6 is coming!)

• For Node, just use require/npm, of course.

Package management + module loading + CI =significant reduction in nightmares

• We have some work to do still
• Client-side especially
• But we've got a lot of the larger problems managable.

To re-iterate

• Be passionate, not fanatic
• Be skeptical of large buy-in
• Pick the right tool for each task
• If you use a framework, be judicious

• To reiterate...

Why bother?

• Abstractions create a common language/way of doing things
• Everything you need, nothing you don't
• Self-contained modules === easier, less brittle testing.

Because developer hapiness is contagious

a brief word of thanks

• Conference Organizers
• RetailMeNot/UI Team
• Special thanks

Thanks for Listening!

Questions? Comments? Come find me!

@kassandra_perch

kassandra@kassandraperch.com

Engineering Evangelist, RetailMeNot