Luke Melia

I’ve really enjoyed reading the varied blog posts responding to the core team’s call. I’m the past the deadline, but better late then never!

For background, I have been working with Ember since it was under early development as Sproutcore 2.0. Ember.js powers a SaaS company I co-founded, Yapp, and we funded our business for a couple of years doing Ember consulting under the Yapp Labs moniker. We’re full-time on product now, and my engineering team at Yapp (currently 3 people) maintains around 6 Ember apps. I help maintain a bunch of popular addons, including ember-cli-deploy, ember-modal-dialog, ember-wormhole, ember-tether, and more. Two former Yappers are on the Ember core team (hi Kris, hi Stef!). I started the Ember NYC meetup in 2012 and continue to co-organize it today.

So it’s fair to say that I am “all in” on Ember. Being part of the growth and evolution of Ember and its community has been one of most rewarding aspects of my career in software.

I’m going to leave the marketing and evangelism themes to other posts. They are important, but not my area of focus.

Instead, I’m going to write this #EmberJS2018 post about the pragmatic things I think the core teams and community could focus on to make day-to-day development more efficient, effective, and productive.

First some brief words on what is awesome, and then some ideas and whining about what needs improvement…

What’s good

A few of the things that I love about working with Ember:

• the component architecture
• the testing experience (especially the new style, paired with qunit-dom and ember-test-selectors!)
• pod-style colocation of JS/HBS/SCSS
• the addon ecosystem
• the addon architecture, and what you can do with nested addons to power internal code-sharing
• release train and upgrade paths have been awesome since 2.0. I have 7 year-old apps that have been upgraded to modern versions of Ember without pain (since 2.0 at least!)
• the deployment experience, powered by the ember-cli-deploy & plugins
• adoption of new standards to great benefit: async/await in tests and yield in ember-concurrency tasks are good examples
• styleguide-driven development with ember-freestyle is a joy
• the people! I can’t express the depth of my gratitude for the brilliant, kind and generous people I’ve met, befriended and collaborated with in this community.

With that lovefest out of the way, on to ideas and criticism.

Allow declaring the properties a component accepts

We’ve been using ember-prop-types to declare what passed properties our components accept. They can be really helpful in failing fast when a refactoring step is missed.

Not using this is like writing every function to accept a `params` hash — a developer has to read the code to figure out what keys are allowed to be passed in. We wouldn’t accept this practice for our Javascript code — why accept it for our components?

ember-prop-types is under-maintained and has some weird edge cases that make it underperform its potential. A higher quality version of this should maintained, endorsed and documented.

There may ways that Typescript can serve this purpose or enhance the developer experience in this area as well.

Error messages & debugging experiences need to be better

Test failures and runtime errors all too often do not log the initial error clearly and instead show a second or third-order effect instead. A community project could be initiated to catalog the most commonly thrown errors and make the top 50 have mind-blowingly awesome messages and debug experiences.

I have been writing Ember apps for since Day 1, and I still find myself in situations where there I am face failures that take me a few minutes to even understand what the actual failure message is. I shudder to think how new developers must experience this.

ember-cli build & rebuild times and tooling

Ember CLI has come a long way in build speeds. And yet, as projects grow, I have found that they become a real pain point. Worse, when a project is feeling slow, it is too hard for a developer to understand how to make it faster, or even what the tradeoffs are. For example, it seems from our ember-cli output that something related to source maps are making many of our builds painfully slow, but I don’t know what to do about it.

Live reload / hot reload

We should make sure live-reload is as awesome of an experience as possible, including supporting hot reloading of modules. I played with Toran Billups’s ember-cli-hot-loader and while it is a cool prototype, it left me convinced that this feature needs tight integration into ember and ember-cli to be done right. We spend a lot of time waiting for rebuild / reload cycles, and I don’t think we are alone.

Named Slots/Blocks

The power of component composition and contextual components are hampered by the lack of a “slots” story. A lot of work has gone into iterations of RFCs including this merged one and is listed on the Status Board as “In Implementation”, but I’m not sure what stage.

I predict that landing this feature in Ember will make us wonder how we lived without it for so long.

Stronger CSS conventions

When looking at a Ember codebase, I usually know what to expect from components, routes, and services — what will be in them, and how they will be organized. CSS has no such consistency across Ember apps, in my experience. I think there’s an opportunity here.

Contrary to the functional CSS approach recently championed by Sam & Ryan from EmberMap, my team has had excellent experience with colocating `style.scss` files with our components, with isolation gained from the SUIT CSS naming conventions. (The SUIT conventions are largely a prettier BEM.)

I don’t feel strongly about the specific naming conventions, but I do think that isolation and maintainability should be the key criteria we’re looking for. In my opinion, the separation of concerns you get from a separate stylesheet outweighs the benefits of assembling class names in your HBS files. You can embrace a limited CSS vocabulary through mixins if needed.

The larger point on CSS in Ember apps, though, is this: let’s get to the point where we can end the bikeshedding and have a standard way of styling our apps that we can start building experience and abstractions on. (Maybe CSS Blocks can be that path? I don’t know enough about it yet.)

Ember Native

As someone who maintains a lot of Android and iOS native code alongside several Ember apps, I look longingly at React Native. I would prefer the conceptual consistency and code sharing possibilities of “Ember Native” instead.

If someone who understands the right Glimmer hooks did a basic implementation, I think a sub-community will rise to fill out the project.

This suggestion feels somewhat heretical given the web evangelism and native-trashing of the EmberConf keynotes. I sympathize with this, but hey, I promised pragmatism.

Fin

If you read this far, I you came away with this some good topics to think about in the above, or at least that you enjoyed reading it as much as I enjoyed writing it.

Viva la Ember!

I got an Amazon Echo on Tuesday. The always-available voice interaction model is pretty awesome and feels ripe with possibility.

Out of the box, I find our new friend Alexa most useful for giving me the weather forecast as I’m getting dressed. As the person in my household who is asked what the weather is going to be like each morning (why me?), it gives me much joy to be able to delegate this task to Alexa.

I would love if the Echo could tell who is speaking (i.e. different members of my family). That would open up some some fun interactions. Also, as others have reported, the Echo has trouble understanding my 7 year old daughter, though it is remarkably good with the rest of us.

The privacy issues are worrisome to me. Along with our computers, tablets and phones, there’s now one more hackable internet connected microphone in my apartment. It seems inevitable that a determined hacker will compromise a target’s Echo to transmit everything. But for now… ¯\_(ツ)_/¯

I spent some time with the dev kit today and wrote my first “skill” for Alexa. I call it “The Fish” and it aims to address another annoyance in my household. We have a fish (who everyone is kind of ambivalent about because she killed the other fish that arrived with her). The kids are generally supposed to feed her but sometimes forget, leading my wife or I to query in a loud voice, “Did anyone feed the fish today?”. Enter my new skill. When you feed the fish, you say “Alexa, tell the fish that I fed her.” Alexa pings my web service (implemented on AWS Lambda in node) which pushes the time stamp into a redis “fish-feedings” list, and instructs Alexa to reply “OK, got it. Thanks for feeding the fish”. Later, instead of the loud query, we can say, “Alexa, ask the fish if she has been fed” and it will reply “The fish was last fed 3 hours ago” thanks to the same web service reading the most recent timestamp and generating a humanized version of it (e.g. “3 hours ago”). We’ll see how well it works, but I’m rather tickled to hear it in action.

For anyone else who wants to build skills using AWS Lambda, a couple of tips: 1) forget to add Alexa Skill Kit as an Event Source to your Lambda functions. 2) if you want to use redis like I did, don’t try to use the AWS Elasticache redis because it can only be seen by EC2 instances; I used redistogo instead.

I’m looking forward to hearing how others extend it!

I delivered this talk at the Boston Ember.js Meetup on Thursday, September 12th, 2013. (Jump to 0:58:10 for my talk)

https://www.youtube.com/watch?v=g5CSaK3HqVA

I delivered this talk at the Ember.js NYC Meetup on Thursday, May 24th, 2013. (Jump to 11:52 for my talk.)

I delivered this talk at the Ember.js NYC Meetup on Thursday, March 28th, 2013.

This talk was delivered to the Ember.js NYC Meetup on Tuesday, September 18th.

This talk was delivered to the Ember.js NYC Meetup on Wednesday, August 22nd.

Note: This post is a refresh of Yehuda Katz’s post of June 11, 2011, Using SproutCore 2.0 with jQuery UI. Thanks to Yehuda for his review.

Another note: Updated on 8/24/2012 to bring up to date to ember-1.0.pre from 8/3/2012.

No rest for the weary: Updated on 4/14/2013 to bring up to date to ember-1.0.0-rc.2 from 3/29/2013.

N.B. Ember 1.0 has shipped! I updated the repo on 9/20/2013 to move to ember-1.0.0 final from ember-1.0.0-rc.2. I also updated jQuery and jQuery UI to latest stable versions. No code changes were required in the example code or blog post.

One of the goals of Ember.js is to make it trivial to integrate the tools you’re already using.

One way that we do that is to provide hooks to interact with the DOM the way that you have learned to with jQuery.

Quick Refresh: Handlebars Templates

You can take any piece of HTML and attach it to an Ember view. You would typically do this in order to attach event handlers to the view or to define a function that computes how a particular value should be displayed. For instance, let’s say we have some HTML that shows a business card for a person:

[sourcecode language=”html”]
<div class="card">
<p class="name">{{salutation}} {{fullName}}</p>
<p class="address">{{number}} {{street}}</p>
<p class="region">{{city}}, {{state}} {{zip}}</p>
</div>
[/sourcecode]

We can wrap this chunk of HTML in an Ember view, which will define the sources of each of the properties used in {{ }}.

[sourcecode language=”html”]
<script type="text/x-handlebars">
{{#view App.BusinessCardView}}
<div class="card">
<p class="name">{{salutation}} {{fullName}}</p>
<p class="address">{{streetNumber}} {{street}}</p>
<p class="region">{{city}}, {{state}} {{zip}}</p>
</div>
{{/view}}
</script>
[/sourcecode]

Wrapping the HTML snippet in a <script> tag tells Ember to render it using its template engine. Let’s look at the view and controller implementation :

[sourcecode language=”javascript”]
App.BusinessCardView = Ember.View.extend({
// view will render with it’s corresponding controller as the context
});

App.BusinessCardController = Ember.Controller.extend({
firstName: "Yehuda",
lastName: "Katz",
salutation: "Mr.",
streetNumber: 300,
street: "Brannan",
city: "San Francisco",
state: "CA",
zip: "94107",
fullName: function() {
return this.get(‘firstName’) + ‘ ‘ + this.get(‘lastName’);
}.property(‘firstName’, ‘lastName’)
});
[/sourcecode]

If we reload the page, we will see a static business card with Yehuda’s information in it. If we were to use the console to update the content by executing App.__container__.lookup('controller:business_card').set(key, value), Ember will automatically update the HTML for you. If you update any property, including firstName or lastName, which are used only as dependencies of fullName, Ember will automatically handle updating the HTML for you.

didInsertElement

You can also define some code to run every time an element is rendered. You can use this hook to wire up any JavaScript library to the element that Ember has created. For instance, let’s say we want to zebra stripe the three lines in our business card once it has been created (note: you probably would not use JS to zebra stripe in real life).

Let’s extend our view:

[sourcecode language=”javascript”]
App.BusinessCardView = Ember.View.extend({
didInsertElement: function() {
this.$("p:even").addClass("even");
}
});
[/sourcecode]

All Ember views have a $ function, which is the normal jQuery function, scoped to the current element. You can also call this.$() to get back a jQuery object wrapping the element itself.

You can use this hook to do anything you want, allowing you to hook in any library you want. You would use this hook a lot like you’d use a jQuery(document).ready hook, but scoped to the view being created.

Ember also provides a willDestroyElement hook, which you can use to tear things down that you set up when the element was inserted. This is relatively rare, and is mostly used when interfacing with another toolkit that requires a teardown, or to tear down custom Ember observers.

jQuery UI

We can use these hooks to build some basic integration with jQuery UI. Yehuda and Tom Dale wrote a demo (which I’ve adapted for current Ember.js) that shows how to connect Ember bindings to jQuery options at http://lukemelia.github.com/jquery-ui-ember. You can also check out the annotated source code and the GitHub repo.

The most important thing to look at is the JQ.Widget mixin, which can be mixed into view classes to attach jQuery UI options and events to Ember’s binding and event system.

You can get started with Ember.js over at emberjs.com.

Until next time!

My friend and colleague Noah Davis and I gave a presentation last night at the NoSQL NYC meetup. The topic was how we use Redis at Weplay.

I had a great time presenting this talk at GoRuCo 2010. If you watch it, please don’t be shy with your feedback, tips, or criticism.