EmberJS 2018: Dogfooding Ember on Emberjs.com

I started using Ember about 18 months ago. In that time I’ve come to learn the ins and outs, the good parts, and the frustrating parts, that make up Ember. I’ve wanted to give back to the framework that I was using, and I have made some minor fixes to some of the addons in the ecosystem, and just recently (yesterday) got a PR merged to fix an issue with the Ember Guides. But I get ahead of myself – I struggled to jump in and contribute to Ember itself. When there was a call for blog posts about the future of Ember in 2018, I knew what I wanted to speak about my experience and provide some motivation for the Ember community and team members to dogfood our own product to make marketing Ember better and to help make contributing simpler. From a technical point of view, I believe Ember is one of the top frameworks already, and it’s a shame more people don’t know that.

What is Dogfooding? – Its a term used to describe an organization using its own product.
The idea is that if the organization truly believes its own product to be superior, it would use the product itself.

Marketing Ember

I did a little competitive analysis when writing this post. Of all of the major frameworks I looked up, Ember was the only one that didn’t dogfood their framework for the main website. React, Angular, AngularJS, Vue…Knockout, Polymer, Meteor – I looked up quite a few of the common front end Javascript frameworks new and old, and every single one of the sites I looked at used their framework to build their site – except for Ember.

I know there are historical reasons for this. Well, I don’t think they hold water anymore. This year, 2018, Emberjs.com needs to be built with Ember. Other people have written in their posts about the need for better marketing of Ember. But all of that marketing falls flat if, when a prospective dev comes to the Ember website, and opens Wappalyzer, inspects the source code, or looks on Github and finds that it isn’t Ember. They don’t know any of the reasons for it. They just know that the people that build Ember don’t use it on their website. And that can put a seed of doubt in their mind. Maybe enough to move on to another framework.

New Contributors

The other aspect of this is the loss of potential contributors.

When I looked into what I could contribute to Ember, I gravitated toward helping the Learning Team with work on the emberjs.com website. So I went to the EmberJS repo on Github, found the Website Source, and started looking at the issues – found one or two I thought I could help with. I cloned the project, and tried to get it to run and was perplexed. My expectation was an Ember app, and instead I found a Ruby and Middleman website. When trying to get that running locally I found that there were known bugs running it on Windows, my main development environment at home. I did reach out on the Ember Slack and a few people tried to help me get things running to no avail. And I let it lay there for a bit, got busy at work and other side projects, and at that point, Ember had lost a potential contributor. I didn’t even know there were other apps that made up the website, so that was it at that time.

Ember is used by developers who tend to be focused on the front end ecosystem. And while there are plenty of front end devs who are great at Ruby and Middleman, that isn’t going to be the norm. And frameworks need new blood on the team. They need the enthusiasm people new to helping out of the framework can bring. The new ideas that come with those people. So let’s make it easier to do so, by ensuring Emberjs.com is built in the framework they likely use every day. Or at the simplest, in the languages they use every day (HTML/CSS/JS).

As a front end framework, obviously there needs to be some dev-ops and backend APIs for the website to work. But I’d argue that the Emberjs.com website is THE place for Ember to shine. If it can be done in Ember, it should be done in Ember. I envision the website repo on github as one of the places to go to see how to use Ember in practice.

Call to Arms

There are a number of benefits that come with dogfooding Ember:

• Greater awareness of rough areas and earlier problem detection
• More accurate marketing message around exactly what benefits Ember provides
• Higher level of confidence from those evaluating Ember and for those using it
• Boost to morale in the community to see Ember being used and promoted by the core team

There are already pieces of the site built with Ember. The Learning Team is actively working to transition more parts to Ember, just launching the recently Emberized Guides app a few days ago. This is not a critique of those efforts, but rather to encourage the effort of Emberizing the website to continue, and to set forth the goal of having the entire Ember website made from Ember this year, in 2018. And I encourage anyone reading who has interest in assisting in that effort to join me in asking what we can do to help.