Notes on Ember.js overcomplicating...

index.md

Some random notes on the pangs of ember. Will be expanding as they are uncovered.

Building a form

Say you have a form that maps to a model, something like:

<form>
  <fieldset>
    <legend>Who are you?</legend>
    <ol>
      <li class='field string required validate'>
        <label>First Name</label>
        <input name='user[first_name]'/>
      </li>
      <li class='field string required validate'>
        <label>Last Name</label>
        <input name='user[last_name]'/>
      </li>
      <li class='field string required validate'>
        <label>Email</label>
        <input name='user[email]'/>
      </li>
    </ol>
  </fieldset>
</form>

To handle this in jQuery all you have to do is this:

$(function() {
  $('#user-form').submit(function() {
    var form  = $(this);
    var data  = {};
    var id    = form.attr('id');
    var user  = App.User.find(id);
    
    $('.field', this).each(function() {
      // really, some `serialize()` function...
      var name    = $(this).attr('name');
      var value   = $(this).val();
      data[name]  = value;
    });
    
    user.updateAttributes(data);
    
    if (!user.valid()) {
      for (var key in user.errors) {
        // firstName-input (pretend at least)
        $('#' + key + '-input', form).addClass('invalid')
          .append("<output class='error'>" + user.errors[key].join("\n") + "</output>");
      }
      return false;
    }
  });
});

... it took me like 5 minutes to write that, and I'm sure I can refactor that to something reusable in any app in an hour or two. Maybe even make it a plugin on Github, another 1 or 2 hours...

Now to make that same thing in Ember...

1. Build the HTML form using Handlebars markup.
2. Build the views
3. Build the controllers

Not only that, think about orders of magnitude more variables.

First, build the HTML, simple enough (and getting excited because of how simple it seems):

{{#with App.newUser}}
  <form>
    <fieldset>
      <legend>Who are you?</legend>
      <ol>
        <li class='field string required validate'>
          <label>First Name</label>
          {{view Ember.TextField valueBinding="first_name"}}
        </li>
        <li class='field string required validate'>
          <label>Last Name</label>
          {{view Ember.TextField valueBinding="last_name"}}
        </li>
        <li class='field string required validate'>
          <label>Email</label>
          {{view Ember.TextField valueBinding="email"}}
        </li>
      </ol>
    </fieldset>
  </form>
{{/with}}

Now, I don't want the model to update every time I enter something in the keyboard. After reading through docs and source code for a few minutes, I realize I can just change

{{view Ember.TextField valueBinding="email"}}

to

<input type='text' {{bindAttr value="email"}} />

But now in the first case, I'm using an Ember.View object, and in the second case, am I using an Ember.View instance? Not clear, so look it up in the docs. Oh, and if I remove that <input...> element, what's going to happen do the bindings? Now all of a sudden I can't do the quick-and-easy $('input').remove(). Instead, I have to do Ember.View.VIEWS[$('input[name="email"]').attr('id')]].destroy(). That's pretty ugly. There's a way around that though, no worries! All you have to do is make the <form> an Ember.View, or wrap it all in an Ember.View as a template.

But now, I want to start adding something like an autocomplete box, or the stackoverflow-like tag box. In jQuery I can just listen to the keyup event, run some ajax, and position some divs over the text field:

$('input').keyup(function() {
  var input     = $(this);
  var position  = input.offset();
  $.ajax({
    url: '/autocomplete',
    data: {query: $(this).val()},
    success: function(words) {
      var divs = [];
      for (var i = 0; i < words.length; i++) {
        divs.push('<div>' + words[i] + '</div>');
      };
      $('#popup').empty().append(divs.join('\n'));
    }
  });
});

Again, took 2-3 minutes to whip together that function.

For Ember what do I have to do? I have to create an App.AutocompleteView, and should that be an Ember.ContainerView or Ember.CollectionView? Then I have to think about how and where the event handlers go (for clicking on the tag in the autocomplete box, for example).

Anyway, all of a sudden, with Ember, I have to have a full-on set of UIComponents, with very rich event handling systems, like flamejs:

• alert_panel.js
• button_view.js
• checkbox_view.js
• collection_view.js
• disclosure_view.js
• form_view.js
• horizontal_split_view.js
• image_view.js
• label_view.js
• list_item_view.js
• list_view.js
• list_view_drag_helper.js
• loading_indicator_view.js
• menu_view.js
• panel.js
• popover.js
• progress_view.js
• radio_button_view.js
• root_view.js
• scroll_view.js
• search_text_field_view.js
• select_button_view.js
• stack_item_view.js
• stack_view.js
• tab_view.js
• table_data_view.js
• table_view.js
• text_area_view.js
• text_field_view.js
• tree_item_view.js
• tree_view.js
• vertical_split_view.js

And those aren't easy classes to make, they're pretty involved. And now I'm up to 300KB of JavaScript just to get back to the ability to do basic things I could do in a few lines of jQuery.

Anyway, I'm not going to spend the time describing the details of all this, it would take hours/days. All I'm going to say now is I feel like I have to build basically sproutcore and then some on top of Ember.js in order to get back to what I could do with jQuery 5 minutes with only a few lines of code.

I should start by saying that it's still too difficult to determine best practices when using Ember, and that this will hopefully be resolved with more blog posts and Ember guides. I've been working with Ember for a few months and have some recommendations.

I would start by examining the reason you'd like to avoid bindings in your form. Perhaps you want to only apply changes after a user clicks an Update button? One approach is to create a copy of your model which is then bound to your form, and the attributes of that model are then applied to the original model upon success. Here's a simple example using ember-rest. Perhaps better yet, using ember-data, you could wrap changes in a transaction which is only committed when your form is submitted, like in this ember-data example. (Note: both of these examples will be cleaned up with the new conventions being introduced in Ember 1.0 - see below).

However, if you really don't want any bindings (and you want to pull values from the form on submit), you could just use an unbound value:

<input type='text' name='user[email]' value="{{unbound email}}" />

Unbound values won't configure any binding logic and therefore don't require any teardown code. Even if you were to take a bound approach, you still shouldn't need to manually destroy the input. It would be better to wrap the logic which determines its presence in your template. For example:

{{#if canHazEmail}}
  {{view Ember.TextField valueBinding="email"}}
{{/if}}

---

I don't think that Ember requires a "full-on set of UIComponents". The Ember core team is specifically trying to avoid rebuilding Sproutcore. UI libs like Flame.js have their place, just as libs like jQuery UI do, but such a lib is in no way required for using Ember. It is one of the specific goals of Ember core to only include HTML4 native controls where bindings or custom event handling are common. The general preference is to defer to standard HTML elements and use helpers such as {{bindAttr}} and {{action}} where appropriate. This is the reason that Ember.Button was recently removed from core, now that <button {{action}} /> is effectively the same.

For your autocomplete box, don't forget that you could still configure it with jQuery from within Ember. You would need to do so from within your view's didInsertElement() event, which indicates that the view has been inserted into the DOM. However, if you want to reuse your logic and generalize your data bindings, creating an AutocompleteView would be an elegant way to go.

Last but not least, I think that the work being done now in Ember regarding view / controller relationships, state managers, and routing is pretty exciting. These are problems that all complex JS MVC apps face, and Ember will try to tackle them together in a cohesive way that provides clear conventions for developers. Because they won't be handled by different libs, I think their inclusion in Ember will actually decrease total js size for most apps. I'm hoping the advantages of Ember will become really clear as 1.0 takes shape and more end-to-end, complex examples and guides are written.

@viatropos without going into detail this second (more later, when I get a second), I'll say that your critique is valid. While Ember's primitives are very solid, there are still common cases where figuring out how to wire them up is non-trivial. Your case is a combination of missing features and documentation, and it reflects a pretty common pattern that should be easier to figure out in Ember.

The benefit that you get with Ember (when things go right) is similar to the benefit you get with unit testing. It's a bit more effort in the beginning, but it pays for itself quickly when you add new features. Your jQuery example would work (and I've written plenty of examples like it), but it composes extremely poorly with future features that work with the same data.

Ember shines when working with multiple areas of the screen that reflect different views of the same data (e.g. a list of things and a separate count of those things). That type of scenario shows up repeatedly in every app I've ever worked on, and is the source of unending, irritating bugs.

@viatropos It seems like your main complaint, rightly, is that it's still very hard to figure out how to best use Ember. I know people are working hard to remedy that and better expose good Ember patterns.

If you went the plain jQuery route ... you will be done with your app mastering the next thing in your field.

Ignores the implicit fact that you already know jQuery and have spent time learning how to best put together applications using it. There are many, many people who haven't walked that road yet and will spend the next few years stumbling through worst practices and anti-patterns as they begin writing stateful, in-browser applications for their job, clients, or fun.

Your frustration is identical to what was voiced for Rails in 2005: "Why bother, I can do this better/faster/easier in PHP/Java/C#." It was equally valid for Rails in 2005 as it is for Ember now. Yes, a person can use their existing skills and tools to put together something better and faster then learning a new set of tools and skills and then building – especially when the resources for learning are as scare as Ember's.

But the counter point is the same for both frameworks: Ember is an attempt to gather already discovered good ways of accomplishing a goal so that everyone doesn't have to go through the same rough experimentation.

You simply cannot judge the efficacy or usefulness of a framework by your first few uses: it will always compare poorly. Being an early adopter is rough because there's a total lack external validation that spending the time to become skilled will have enough payoff. You kind of have to go with your gut.

My gut tells me that Ember is the winner in its category. Its patterns have a distinct correct solidness to them that other frameworks lack, which is why I started committing to it. If you don't agree or aren't sure, give the project sometime to build up a reputation for success before returning and investing the time.

Best of all: the longer you wait the better the framework and available resources for learning will become.

I think you're also running into the problem that good app development is hard, period. Ember can make it better, but you'll never be able to develop a good app in your sleep. There's always going to be lots of work to plan your app and architect it properly. Of course, if you don't care about making a really solid app and just want to hack something together, Ember is certainly not the easiest way. However, I imagine that, like the rest of us, you actually want to make apps that are good. Be careful that you don't blame Ember for something inherent in the process. That said, I do think there's more we can do to make the process easier, but I think it's naive to expect that building apps will ever truly be easy.