<commit_before>---
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
---

Here [@Wisembly](http://wisembly.com) we strive to change the way people meet, work and collaborate during meetings. We come from a Symfony2 / Backbone.js / socket.io world with our event / training / conf call products, and when it came to thinking about our next product, [Solid](http://getsolid.io), we slowed down things a bit and looked for maybe a different and possibly better way to manage our frontend application.

We looked at [Angular.js](https://angularjs.org/) and [Ember.js](http://emberjs.com/) that were trending among cool kids out there and that looked both promizing for us to manage an ambitious javascript application with our growing developpers team (by the way, [we are hiring!](http://wisembly.com/jobs)).

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 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.js

### Convention over configuration

**First of all, 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 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.

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).

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.

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 and your productivity

**Good points**
- 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? 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 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 will be. Oh, and you're likely to drink less coffee (think about your health Dude ^^)

Another cool aspect of using components as a front-end developer/UI developer is to list UI oriented ones in a styleguide and, in that way, help developers to test, see regressions and find which ones are available with their parameters.

Ember 2.0 will put even more emphasis on components!


### NOT THAT COOL points
- 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 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 to 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 our frontend team is a little reserved. This lacks some documentation too...
- Broccoli is quite slow compared to Gulp.
- The fact that it recompile everthing, including JS even if you change only a line of CSS is not good at all.<commit_msg>Added a paragraph about questions<commit_after>---
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
---

Here [@Wisembly](http://wisembly.com) we strive to change the way people meet, work and collaborate during meetings. We come from a Symfony2 / Backbone.js / socket.io world with our event / training / conf call products, and when it came to thinking about our next product, [Solid](http://getsolid.io), we slowed down things a bit and looked for maybe a different and possibly better way to manage our frontend application.

We looked at [Angular.js](https://angularjs.org/) and [Ember.js](http://emberjs.com/) that were trending among cool kids out there and that looked both promizing for us to manage an ambitious javascript application with our growing developpers team (by the way, [we are hiring!](http://wisembly.com/jobs)).

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 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.js

### Convention over configuration

**First of all, 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 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.

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).

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.

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 and your productivity

**Good points**
- 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? 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 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 will be. Oh, and you're likely to drink less coffee (think about your health Dude ^^)

Another cool aspect of using components as a front-end developer/UI developer is to list UI oriented ones in a styleguide and, in that way, help developers to test, see regressions and find which ones are available with their parameters.

Ember 2.0 will put even more emphasis on components!


### NOT THAT COOL points

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...

The first of these questions is about [Ember Data](https://github.com/emberjs/data). It's an awesome library, no doubt about it: well documented, very active, and strong / stable enough for what we want to build.
But the fact is that our APIs are not fully compatible with it: not fully "JSON API" compliant, and not very modifiable, since they are shared accross our products. Since Ember Data is not very permissive, we've had some headaches. That's why we are wondering if we shall build our own data store/cache/api layer.

In some cases, we still wonder where is the best place to do things, and how to do it.
For example, let's say you have to implement a global notification center for your app: we're still investigating and iterating to find the best way to do it... Even if a "service" is what sounds like to be the best idea, it is not as simple as it seem...

How does it interact with push events (we make a heavy use of [socket.io](http://socket.io/) ? How does it interact with the "bubbling" of Ember actions ? What if a component has to notify the app of its state ? What if you want your models to auto-notify the user when they are saved / errored ? 
We implemented all of these behaviors but we are not very sure if we did it the right way, and trying to find better methods every day (ok, finally it's pretty normal for devs ^^)



- 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 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 to 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 our frontend team is a little reserved. This lacks some documentation too...
- Broccoli is quite slow compared to Gulp.
- The fact that it recompile everthing, including JS even if you change only a line of CSS is not good at all.
{'fraction_non_alphanumeric': 0.05215920915712799, 'fraction_numerical': 0.0027315296566077004, 'mean_word_length': 4.3134070490670355, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 3, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '527746', 'n_tokens_mistral': 3826, 'n_tokens_neox': 3636, 'n_words': 2415}