EMBER.JS
JAK ZATOPIT A NESHOŘET!
Viliam Elischer
@vire
AGENDA
Introduction
Concepts
Usage
Experience
Pros/Cons
Future
“Ember.js - A framework for creating
ambitious web applications.”
WHAT IS A FRAMEWORK?
“A software framework, in computer
programming, is an abstraction in which
common code providing generic
functionality can be selectively overridden
or specialized by user code providing
specific functionality.”
ref
makes doing the right thing feel good
is built on top of maximally flexible primitives
evolves with the best practices of the community
nurtures a feedback loop that helps features iterate as
shared understanding develops
Current version: 1.11.1 (I really love ones!)
In December 2011 Sproutcore 2.0 was renamed to Ember.js
CORE CONCEPTS
NAMING CONVENTIONS
default main entry point:
app/app.js
app/routes/application.js
app/controllers/application.js
app/templates/application.hbs
example: yourdomain.com/favorites
app/routes/favorites.js
app/controllers/favorites.js
app/templates/favorites.hbs
BUILDING BLOCKS
| Router | Routes | Templates | Models | Components |
| Controllers | Views | Helpers |
ROUTER
Simple definitions
Router.map(function() {
  this.route('about');
  this.route('favorites', { path: '/favs' });
});
or nested
Router.map(function() {
  this.route('posts', { path: '/posts' }, function() {
    this.route('new');
  });
});
ROUTES
You define a router.js
Router.map(function() {
  this.route('posts');
  this.route('post', { path: '/post/:post_id' });
});
and a route app/routes/post.js
export default Ember.Route.extend({
  model: function(params) {
    return $.getJSON("/api/posts/" + params.post_id + ".json");
  }
});
MODELS
Supermarine Spitfire LF Mk. IXE - No. 312 (Czechoslovak) Squadron RAF
TEMPLATES
Designed to describe the UI in a meaningful way:
Expressions {{age}}
Outlets {{outlet}}
Components {{my-component}}
Helper {{t "user.edit.title"}}
given a controller has a people property:
export default Ember.Controller.extend({
  people: [{name:'Yehuda'}, {name:'Tom'}, {name:'Trek'}]
});
then the following template
<ul>
  {{#each person in people}}
    <li>Hello, {{person.name}}!</li>
  {{/each}}
</ul>
results into:
<ul>
  <li>Hello, Yehuda!</li>
  <li>Hello, Tom!</li>
  <li>Hello, Trek!</li>
</ul>
COMPONENTS
CONTROLLERS, VIEWS, HELPERS
WHEN EMBER?
“When you realize that $elector-driven
development is too painful”
REASON
like:
the complexity of the project is causing chaos
your company is starting a new project (!)
you're planning to extend an existing project
a start-up occurred
it will help to eliminate technical debt
USE CASE
complex data-model / data-structure
big-data app view layer (multiple data sources)
conversion operations (e-commerce)
media processing (audio, image, video)
dashboard, monitoring / aggregation capability
B2B or B2C app for daily usage (ERP, CRM, etc.)
WHEN EMBER NOT?
overkill - scope, time, productivity, learning
time pressure
unclear added value (why?)
more dynamic than required = productivity loss
customer/stakeholder requests a framework
not required, like
static presentation e.g. opening hours, menu, contacts
EXPERIENCE
EMBER-CLI
  $ npm install ­g ember­cli
Swiss-army command-line interface & ember's killer feature
out-of-the-box project scaffold via:
blueprint generator:
transpile (ES6, sass, less, coffee)
minify, concat
managed dependencies | package.json, bower.json
$ ember new my­project­name
$ ember generate component my­component
broccoli: fast, reliable asset pipeline, constant-time
rebuilds
auto-rebuild when file changes & live-reload
single point of configuration: Brocfile.js
configurable build profiles:
dev , test , production , ci , ...
easy import of 3rd party libraries
export and import project via to addons
$ bower install ­­save moment
app.import('bower_components/moment/moment.js');
FINDINGS & HANDY ADVICE
default project layout is not ideal (solution: pods)
adjusting to ember-cli wasn't trivial before version 0.1.0
different DI mechanism than Java
ember plays great with viz technologies svg (d3), canvas
we gave suggestions for improvements, still in progress :(
result of build can't be split into desired artifacts
this is a good requirement for server side rendering, to
avoid adding business logic in client code
I've tried to replace QUnit with Jasmine...
sketch idea first (whiteboard/draw.io), code later
make POCs before you invest a lot of effort...
try to spent few days, or a week developing some small
functionality with a framework and check if you're are
comfortable
DON'T FORGET TO WRITE UNIT TESTS
There is no excuse to not write unit tests,
just your laziness.
PRO ET CONTRA
PROS
community, contributions, ecosystem - github, irc, forum
conventions - speeds up development, minimize faults
multiplatform support (browser, iOS/android, phone)
PROS
ES6, ES7 syntax support via babel.js
TDD support for unit & acceptance tests, testem, CI
Mature API (2.0 soon)
Batteries included - a lot functionality is ready for use
PROS
dozens of ember-cli addons will save time & bugs
backend agnostic (node, java, ruby, php, python, .net?)
ready for Functional reactive programming (RxJS)
CONS
learning takes longer
QUnit as default test-framework (see ember-cli-mocha!)
lazy loading of custom (route/template/model) is N/A
CONS
attention intensive / you need to check what's going on
absence of out-of-the-box i18n support
modifications are nontrivial - custom test runner, task
runner, test framework
WHY DO I THINK THAT IS EMBER
AWESOME?
BECAUSE:
DevX - intuitive, clean code, COC, DRY, KISS
Stability without stagnation principle
Tooling ember-cli & ember inspector
Is organized into 14D releases, many new features
Makes common tasks easy to complete (screen, widget)
Ember has vision, roadmap, architecture
COMING SOON
AND MORE
ember 2.0
Server Side Rendering / SSR via Fastboot
Ember Services / Improved DI
HATEOAS powered dynamic app generation
Ember RFCs - github.com/emberjs/rfcs
Q&A
www.joinzoom.com

Ember.js - Jak zatopit a neshořet!