Error
Sorry, the page you're looking for:
cannot be found. That's what we call a four hundred n' four error.
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…
A few of the things that I love about working with Ember:
With that lovefest out of the way, on to ideas and criticism.
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.
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 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.
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.
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.
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.)
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.
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!
]]>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!
]]>Video below. My demo starts at 34:12.
]]>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.
]]>