JavaScript Showdown

JavaScript Smackdown!

Brian Holt

@holtbt

Why?

  • You're choosing an MVC for your next project.
  • You understand 1 or 2 of these frameworks and want to know about the other(s).
  • You just really wanted some reddit stickers.

You have come to the right workshop!

This workshop depends on audience participation.

  • I've done some work in all these. However, these are all large, robust, and mature frameworks. If you know a better pattern to share, let's stop and talk about it.
  • That said, let's not get semantic. This workshop is really to communicate the look and feel of working in these frameworks, not every nut and bolt.

Why an MVC in thie first place?

Good question!

  • Some companies, like Facebook, have chosen to eschew MVC in favor of other paradigms (or no recognizeable paradigms.)
  • Totally a good call to not use an MVC in a lot of cases. A lot of time everything looks like a nail when you're holding the hammer.

Okay, you convinced me not to use MVC. Good job.

  • But, wait. Some things are nails. Sometimes these paradigms can make sense (I say can because you can never use MVC and still be okay.)
  • The bottom line comes down to if it makes you more productive. If it makes you more productive in your project, do it! That's what they're designed for: optimizing your development.

Okay, which one should I use?

It's a secret to everyone.

Just kidding.

But I'm not going to tell which one to like. Pick the one that makes sense for your project. And what makes to sense to you.

Okay, but what are the differences then?

Let's examine the internal mechanics a little bit.

Angular

  • Achieves two-way data binding via dirty checking.
  • The code behind some these Angular features is bananas. Seriously.
  • Crazy snippet of Angular code.

Angular continued...

  • Essentially, a certain set of actions in Angular cause it enter a digest cycle which is where it checks to see if any of the objects in your scope have changed. If they have, they're updated to reflect that in all of its references.
  • Sounds inefficient, right? Well, it sort of is, but it doesn't matter 99% of the time. However, two assumptions are being made: your dirty-checking comparisons aren't taking more than 25 ┬Ásec and you're tracking less than 2,000 objects. Usually pretty safe assumptions.

Ember

  • Ember achieves two-way data binding via accessor methods on objects.
  • This allows for effecient data checking and some other cool stuff like computed properties.
  • However, this makes for less appealing syntax (personal opinion) because you have to do things like obj.set('key', 'val') instead of obj.key = val like in Angular.

Backbone

  • Backbone achieves the two-way data binding like Ember but it's not free. You have to do all the wiring yourself.
  • This is great because no assumptions are made and you are free to shape how you please.
  • Backbone is also easily extensible. For example, it's pretty easy to rip out Backbone's views and put in ReactJS views. Pretty fun.

React

  • Like Backbone, two-way data binding isn't free. However, it's easy, especially with the provided helpers.
  • React updates the page by constructing a virtual DOM and diffing it with the actual DOM. This allows React to update the bare minimum possible which makes it the most performant of the four in re-paints.
  • React is self-described as the V in MVC. It is agnostic to your data layer. Thus it pairs nicely with Backbone or other frameworks.

Unsolicited Opinions

Why Backbone?

  • Dead simple to interact with with RESTful APIs on a model level.
  • Offers great way to organize JavaScript code. Gets out of your way after that.
  • Barebones. Piece together your own client-side tech stack.
  • Works great for large applications.

Why React?

  • Designed for optimal efficeny. The bottle-neck on the browser is the DOM and React minimizes and optimizes its interaction with actual DOM.
  • Forces a one-way flow of data through its components which means that what operates on data always lives next to the data. Makes for very easy to read code.
  • Very web component-esque. Easy to compose components of other components.
  • Easy to introduce. Easy to throw one or two React components on a page.
  • React can easily do server-side rendering: something the other frameworks don't even on their radar.

Why Angular / Ember?

  • These largely scratch the same itch.
  • Perfect use case for these is rapid prototyping.
  • Some interesting idiosyncrasies become evident at large scales.
  • Both are pretty damn fast. They both have areas of churn in different places.

Angular

  • The power of the directive. Directives are an extremely powerful way to influence the DOM in a declarative fashion.
  • The ease of the POJO (plain ol' JavaScript object.) This makes Angular both easier to pick up and easier to apply your already awesome JS skills to it.
  • While monolithic at present, Angular is being decomposed into a more modular fashion, making it easier to piece together and improve on. Like how awesome the Angular-UI router is.

Ember

  • Computed properties are awesome. Binding together models in your code makes some really cool possibilities.
  • Opinion: Ember has fewer weird gotchas than Angular. I think this comes from having control over their objects. Angular has some weird DSL.
  • Though I believe Ember's barrier to entry to is higher, I think the router is much easier to get used to. The Ember router is awesome.
  • Ember's docs are awesome (Angular's are still pretty bad.)
But wait! There's more!

There's tons of great things about these frameworks that we didn't talk about. Core features even.

Cool things not addressed here.

Backbone

  • Mentioned a bit, but interacting with APIs once you have your models up and going is really easy.
  • We did this workshop with pretty vanilla Backbone. There are a ton of awesome libraries to go along with Backbone. Marionette is a personal favorite of mine as it makes a lot of these common design patterns in Backbone dead simple and takes away a lot of the boilerplate.
  • Backbone seems like a lot of code, but once you get your core models and views together, it becomes a very productive framework to work in.

Ember

  • Computed. Properties. You can set up properties that become are dependent on other properties. Like if you have a rectangle and you have an area property. You can make that a computed property that depends on the length and height.
  • Ember is a framework as opposed to the toolset that Angular confesses to be. The difference is subtle but is evident in their design patterns. You use Angular to build a framework for your app. Ember is the framework.
  • Everyone says Angular directives are amazing (they are) but most things can largely accomplished in Ember's views/components.

Angular

  • Okay. Directives are really, really cool. Think of them as decorators for HTML elements that you can mix and match. A directive can be as simple as adding two-way data-binding for a CSS property all the way to being a fully-functional web component(-esque) element.
  • Filters! Filters allow you filter input before you display it. If you wanted to not show some of your todos based on if it didn't have any letter 'V' in the title, it'd be simple to write a filter for that. Or automatically take display format currency or time.
  • Custom services. You saw scope, but you can write your own dependency injected services. Things that you find yourself doing a lot can easily be abstracted into a service, tested, and reused.

React

  • We glanced over mixins but that community is only starting to take off. The ability to write functionality once and have it span mulitple unrelated components open cool possiblites.
  • React is made with functional programming in mind. If you're a functional programmer, this will all feel second nature to you.
  • Facebook made React with Flux in mind. Flux is a new paradigm (as opposed to MVC) that allows data to only ever flow one way in an app. The framework fluxxor helps you adhere to it.
  • Server-side rendering. You can render your page server-side, send it down and then React will take over the already-rendered HTML. Cache those pages and you get crazy fast page loads.

Brian Holt

@holtbt

JavaScript Showdown

JavaScript Smackdown!