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!

Presented at Wicked Good Ember in Boston.

Through my Ember.js consultancy, I have been working with the rest of the Yapp team and some talented folks at Tilde and MHE Labs on a technology proof of concept combining Ember with Oasis.js and Conductor.js to create an app framework that allows for the composition of many apps leveraging iframes for isolation and an elegant communication model. I recently demoed the app, called Glazier, at a Boston Javascript event called “The Future of Cards”.

Video below. My demo starts at 34:12.

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

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

The team at Yapp has been busy building toward Yapp’s vision: to make mobile app creation accessible to anyone and everyone. The early versions of our product have received rave reviews from our users and press including the Wall Street Journal, Good Morning America, the BBC, and many others. We’re just getting started, though — we have a very ambitious vision for where we want to take Yapp.

The other thing we’ve been busy doing is helping to build Ember. As you may know, our team at Yapp has some serious Ember chops. We enjoy contributing our skills and knowledge to the Ember community in the form of code contributions to Ember core, mentoring newer Ember developers, running the successful Ember.js NYC Meetup group, and more.

To date, we’ve done this all in our “spare time,” while building Yapp. Ambitious visions require resources, of course, and when it came time to think about funding the next stage of Yapp’s growth, we decided to explore an alternative to traditional venture funding and be true to our vision and what we love to do – making apps accessible to everyone, ordinary folks and developers alike. Out of this exploration, Yapp Labs was born.

The goal of Yapp Labs is to enrich the Ember community by helping companies to develop internal Ember expertise, resolve tough bugs and performance issues, fill in missing functionality of Ember core, and ultimately ship great apps that make us all proud to be associated with Ember.

To that end, we have begun offering the following services:

Sponsored OSS development

As awesome as Ember already is, there is a very long list of improvements to make the development experience and production experiences as good as they can be.

If shortcomings in a particular aspect of Ember or the Ember ecosystem are a frustration for you, you have three options: you can roll up your sleeves and fix it, wait for someone else to fix it, or engage with professionals like us to get it fixed. Much of Ember’s progress has come from companies generously funding talented developers to devote some full-time focus to particular areas of Ember.

Ember.js training

We have been cultivating Ember talent and building a community of professional Ember developers in New York and Seattle through the meetups in each of those cities. Through Hacker Hours, our liberal co-working invitations, and online venues, our team has now personally mentored hundreds of Ember developers.

We can develop and deliver a customized curriculum to help your team get started or level up their Ember skills. Courses can be customized to half-day, full-day, or multi-day lengths.

Support contracts

When deciding to adopt an open source project, it can help to know that you have a vendor to call if you get stuck. Our support contracts let you know that you’ll have an expert available to you if you get stuck. Support contracts include several hours per month of assistance and troubleshooting from an experienced Ember developer.

Ember app development (mobile, tablet & desktop)

Through our work on Yapp, we have rare expertise in Ember on mobile, where performance is critical, and in implementing cutting-edge user experiences in a wide variety of form factors. Our team members bring strong Ruby on Rails skills to build the performant and easy-to-maintain back-ends that are necessary for an Ember app that works and feels great.

Our favorite way to work is to augment an existing team, so that when it’s time for us to move on, we’ve leveled-up a few more Ember experts in the world and know that your app will be in good hands.

We’re excited about this new offering. If you’re interested in working with us, get in touch: luke _at_ yapp.us.

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.