- updated ember post

_posts/2014-12-10-what-we-have-learn-from-ember.markdown

@@ -3,6 +3,10 @@ layout:     post
 title:      "What we've learn from Ember.js after 2 months developing our new product. A Solid story"
 categories:
   - general
+  - ember
+  - javascript
+  - front
+  - backend
 author:     guillaumepotier
 ---
 
@@ -12,69 +16,68 @@ We looked at [Angular.js](https://angularjs.org/) and [Ember.js](http://emberjs.
 
 After doing the famous [Todo MVC example](http://todomvc.com/) and some other POCs, we decided to go for Ember with [Ember-cli](http://www.ember-cli.com/).
 
-Here is ou real life Ember.js feedback, what we learnt, what we think it is cool, what is really uncool and what could be improved. Let's start.
+Here is ou humble 3 months real life Ember.js feedback for [Solid](http://getsolid.io), what we learnt, what we think that's cool, what is really uncool and what could be improved.
 
-## Ember
+
+## Ember.js
 
 ### Convention over configuration
-**Ember is not like Backbone. It's not a library, it's a framework.**
 
-That mean devs accepting to embrace Ember's philosophy will be greatly rewarded by the framework, whereas more reserved ones will suffer from fighting against concepts they may consider as very odd.
+**First of all, Ember is not like Backbone. It's not a library, it's a framework.**
 
-At the beginning, Ember is deep and obscure, it's like jumping in a gulf, blindfolded, and being turned back. But step after step, as conventions are understood and accepted, you discover how powerful it is, and how easily you can manage to make it perform very advanced tasks, very easily. Be be warned that your neurons will be shaken
+That mean devs accepting to embrace Ember's philosophy will be rewarded by the framework after the learning curve, whereas more sckeptical ones will keep fighting against concepts they may consider odd and won't unlock the framework potential. But hey, nothing new here, that's the same for every opinated framework in any language.
 
-#### What does that mean for scaling ?
-Using these conventions means that you will continue to use them as your app and team grows up.
+Using Ember conventions and components will allow you, once masterized, to scale only your business complexity part inside your app with your growing team, instead of handling framework complexity and improvement (rendering, syncing data for example).
 
-**Concerning the app:**
+We observed that, even in a short 3 months long period window, we took 2 sprints of 2 weeks to set up our application foundations with 2 javascript developers and then handled in the last 2 sprints more features with only one dev that we would ever do in our current Backbone production application. Integrating an authentication mechanism? There's an ember-cli plugin for that. Integrating Google analytics, Intercom or Mixpanel in our app? There are ember plugins for that too.
 
-The complexity you felt in your first days has been transformed into concepts you have integrated, so your app's complexity will grow faster than your code's complexity => that's good for scaling !!!
+It **feels right** to see in this javascript world with Ember the same benefits we experience with Symfony2 for long now with bundles and plugins that perfectly fit, easy to install or to maintain, thanks to the framework conventions.
 
 
-#### What does that mean for your team
+### What does that mean for your team and your productivity
 
 **Good points**
-- Concerning your current team members, they will tend to produce more homogeneous code, and that's a great thing for productivity and comprehension
-- That leads to the second good point. New team members understanding Ember will understand your code.
+- Your developpers will tend to produce more homogeneous code. That's a great thing for productivity, maintenance and scalability
+- New team members will already know Ember and will understand your code faster, they'll only have to look to your business code, no need for them to read and learn a framework related mechanism you could have developped inside your own framework
+- You won't have to maintain core parts of your code. Just keep your project Ember-up-to-date to benefits for latest community features and improvements. Again, no more team time waster to maintain something a community could maintain for you
 
 **Risks**
-- What happens if you integrate an "Angular" dev ? It's very possible, since this framework is far more "hype" at the moment than Ember. Despite the fact that Ember and Angular are different in some ways, their concepts doesn't seem that far, and the new "dev on the block" should feel at home within days (1-2 weeks max.)
-- You should consider understanding and using "the ember way" to do things, before trying to customize them => Think about tests, future upgrades, and glitches you should introduce in the app because "Hell yeah, i like to customize ALL THE THINGS"
+- What happens if you integrate an "Angular" dev? Despite the fact that Ember and Angular differs in many ways, their root concepts are not that far, and the new "dev on the block" should feel at home within days (1-2 weeks max)
+- You should consider understanding and using "the ember way" to do things, before trying to customize them => think about tests, future upgrades, and glitches you should introduce in the app because "Hell yeah, i like to customize ALL THE THINGS"
 
 ### The world is made of components
-Do you embrace DRY methodology ? Components are your new little friends ;)
 
-Ember.js allows you to wrap all of your repeated pieces of code inside of components. Whether you have repetitive chunks of templates, or UI elements, or event entire parts of your app, you should consider using components.
+Do you embrace DRY methodology? Components are your new little friends ;)
+
+Ember.js allows you to wrap all of your repeated pieces of code inside components. Whether you have repetitive chunks of templates, or UI elements, or event entire parts of your app, you should consider using them.
 
-Don't fear using components in components, the more "organic" your design / approach is, the more modular your components set will be. Oh, and you're likely to drink less coffee (think about your health Dude ^^)
+Don't fear using components in components, the more "organic" your design / approach is, the more modular your components will be. Oh, and you're likely to drink less coffee (think about your health Dude ^^)
 
 Ember 2.0 will put even more emphasis on components!
 
 
 ### NOT THAT COOL points
-- Before digging deeper in Ember, we have heard about its famous "learning curve". Some said it is like climbing a mountain, some compare it to a roller coaster. We tried and, we must admit, it's pretty heavy and almost sinusoidal, but really worth to surf. We've had bad days, and good days. We've had questions, we still have questions.
+- Before digging deeper into Ember, we heard about its famous "learning curve". Some said it is like climbing a mountain, some compare it to a roller coaster. We tried and, we must admit, it's pretty heavy and almost sinusoidal, but really worth to surf. We've had bad days, and good days. We've had questions, and we still have questions.
 - Maybe the "convention over configuration" is not for everyone
 - The way components communicate through actions is still very perfectible (notably the `sendAction()` method, which could be very confusing for beginners)
 
 
 ## Ember cli
 
 ### COOL points
-+ The most cool point about Ember-cli is its EcmaScript6 transpiler! It's really cool to write imports without requirejs headhaches, and to be able to use ES6 features, right now.
-+ It provides a full development environment with server, automatic incremental build with broccoli, live watch and reload, tests & jshint.
-+ Ember cli is bundled with lots of cool generators following "blueprints" rules that allow you to keep up a good workflow
-( create the right files, at the right place, create the corresponding basic tests,
-  etc...) There is no way to make a mistake when using generators, which is a very gound point for scaling (product + team). Blueprints can be created, so every team can reproduce its own workflow
++ The coolest point about Ember-cli is its EcmaScript6 transpiler, clearly. It's really cool to write imports without requirejs headhaches, and to be able to use ES6 features, right now.
++ It provides a full development environment with server, automatic incremental build with Broccoli, live watch and reload, tests & jshint.
++ Ember cli is bundled with lots of cool generators following "blueprints" rules that allow you to keep up a good workflow (create the right files, at the right place, create the corresponding basic tests, etc...) There is no way to make a mistake when using generators, which is a very good point for scaling (product + team). Blueprints can be created, so every team can reproduce its own workflow
 + Ember-cli brings its own resolver that provides/allows a way better file architecture (PODs are also possible)
 + The current version (0.1.2) brought Content Security Policy, which is a cool addition if content security is important for your app, and the browsers you target are not yet compatible
 + Version 0.1.3 will let you create multiple sets of css files. To start with, we'll try ti use it to target specific needs (mobile, desktop, and why not old browsers). We can't wait for the upgrade (but after the beta has launched ^^)
 
 
 ### NOT THAT COOL points
-- Despites Broccoli has really cool sides, the Brocfile is a bit complicated, and
-  the "front" team is a little reserved, lack of documentation, too...
-- Sass too long to be reloaded => NoCSS injection? (but it might change very soon => [see issue #2371 on ember-cli repo](https://github.com/stefanpenner/ember-cli/issues/2371))
-- The upgrade process can be a real pain in the ass (this is a very very perfectible thing)
+- Despites Broccoli has really cool sides, the Brocfile is a bit complicated, and our frontend team is a little reserved. This lacks some documentation too...
+- Sass is too long to be reloaded => NoCSS injection? (but it might change very soon => [see issue #2371 on ember-cli repo](https://github.com/stefanpenner/ember-cli/issues/2371))
+- The upgrade process can be a real P.I.A (this is a very very perfectible thing)
+
 
 ## Handlebars
 
@@ -105,7 +108,7 @@ Ember 2.0 will put even more emphasis on components!
 
 ## Internationalization
 
-We tried [ember-i18n](https://github.com/jamesarosen/ember-i18n) that was a good start but did not embrace fully gettext philosophy. We had a look to [Jed](slexaxton.github.io/Jed/) and [i18nnext](http://i18next.com/) but there were both too complex, shipped too many unecessary features, so we came with our own plugin [LINK HERE] and [Handlebars xgettext parser](https://github.com/Wisembly/xgettext-php) written in PHP. We'll make in the near future a more complete post about internationalization and gettext / Poedit.
+We tried [ember-i18n](https://github.com/jamesarosen/ember-i18n) that was a good start but did not embrace fully gettext philosophy. We had a look to [Jed](slexaxton.github.io/Jed/) and [i18nnext](http://i18next.com/) or [format.js](http://formatjs.io/) but there were too complex, shipped too many unecessary features, or did not follow gettext standards, so we came with our own tiny plugin [ember-gettext](https://github.com/Wisembly/ember-gettext). We'll make in the near future a more complete post about internationalization and gettext / Poedit standards and phylosophy.
 
 
 ## Tests