Single Page Apps for the Modern Enterprise: PArt 2

 

OR

Why I picked Ember over Angular, Backbone, React

 

Ryan Hayes

@RyannosaurusRex / ryanhayes.net

TriJS Meetup 2/10/2015

Tri-Cities .NET User Group 3/17/2015

background

framework Requirements

  • Productive
  • Testable
  • Good Tooling
  • Great with Large Code Base and Team
  • Stable
  • Build Automation (specifically TeamCity/Octopus)
  • SEO
  • Performant

Angular

Pros

  • HUGE community
  • Lots of IDE integration
  • Dependency injection
  • Easy(er) to initially pick up
  • Flexible
  • Lots of tooling options

Cons

  • Spaghetti code is really easy in large apps
  • Junior JS devs
  • Refactoring is hard unless everything is a component
  • Router is pretty weak
  • Lots of tooling options
  • 2.0 will be a total rewrite...so...
  • No server side rendering option on roadmap

Backbone

Backbone is for widgets, so it doesn't count

-Ryan Hayes to Lee Trout after seeing its high usage numbers

...but seriously, use it instead of jQuery.

If you have a traditional webapp with a very specific, small area for dynamic content, use Backbone

React

+ Flux!

Hey, that's just the view!

Better now?

React Pros

  • Just the UI
  • Server-side Rendering
  • Virtual Dom (VERY fast!)
  • Flux architecture (?)
  • Excellent composition

React Cons

  • Just the UI
  • No routing
  • No DI (that I've seen so far)
  • No Controllers/logic framework
  • Wait...is Flux a thing I can use? Reactians keep saying it's something I can use...
  • Only version 0.12

 

A lot of people ask if Facebook will release Flux as an open source framework. Really, Flux is just an architecture, not a framework. But perhaps a Flux boilerplate project might make sense, if there is enough interest. Please let us know if you'd like to see us do this.

- Flux Docs

Aurelia

Don't use it in production yet

 

-Rob Eisenberg

Ember

 

But Ember

Isn't

Sexy!

 

Super obvious

nerd glasses!

Almost version 2.0 (Way too old to be a hipster!)

Ember Pros

  • An official CLI
  • A "blessed" tooling pipeline
  • Conventions
  • Ember Data (for REST Svcs)
  • Fastboot (Server Side Rendering) Soon!
  • Generators!
  • ES6-based by default (6to5)
  • Stability without stagnation (whew, very important to large apps with a long dev life)

Ember Cons

  • Extra work to be different/drop on page
  • Relies on jQuery (working to remove this dependency)
  • Much smaller community than Angular
  • Initial learning curve (to learn all the conventions)
  • Too much work for small areas

Why are conventions and tooling Enforcement important?

True/false: you should make it easy for an intern to help

Ember minimizes the code needed for code reviews and ensures even interns can be productive while being confident their code is consistent with the rest of the codebase

 

Otherwise...

6 months in and devs don't follow your examples

(everyone uses someone's conventions, even if their own)

Mostly because *People* don't enforce good practices well

Freedom to do what I want in code doesn't mean

Freedom from consequence

So what are you trying to say?

MV* Frameworks are a dial

Small bits of awesome in a 98%+ traditional webapp

An *actual* single page of awesome in an otherwise traditional app

Really big, multi-page single-page-app where everything is awesome

So, why do you like Ember?

  • Interns writing nonsucky code!

  • High-Level APIs mean I get stuff for free! (HTMLBars, fastboot)

  • Conventions mean tooling can reason about my code

  • Ember-CLI allows:

    • Generators
    • TeamCity/CI integration
    • Tons of "Blessed" automation
Made with Slides.com