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
Enterprise SPAs and Ember JS
By Ryan Hayes
Enterprise SPAs and Ember JS
- 14,370