Building an Electron App with Ember and then Burning it Down 🔥


Fires can’t be made with dead embers, nor can enthusiasm be stirred by spiritless men. Enthusiasm in our daily work lightens effort and turns even labor into pleasant tasks.
– James Baldwin

When I was first introduced to Electron, I was intrigued and excited to get to dig in and play with all the slick features it can provide to a native desktop app, integrating it seamlessly into the user’s operating system. One of the cool things about an Electron app is that it can be built using any JS framework, library, or even our old friend vanilla JavaScript. My top-notch partner MaryJane and I decided to design and build an interpretation of a traditional desktop application using Electron that would let our user store and manage their recipe collection. In our ideal vision of the app, the user would be able to enter recipes into the app manually and upload images of each dish, as well as upload scanned copies of their existing hard copy recipes (who doesn’t want to preserve Grandma’s famous noodle recipe forever?). We also intended to pull in the Spoonacular API to provide extra features such as being able to search for and extract a recipe from any website.

Electron uses Node.js and Chromium, which enables the developer to design the app for Google Chrome, and yet it will still work the same in IE, Safari, etc. This is a huge boon to developers as it eliminates the need for cross-browser testing. Additionally since it is exclusively a desktop app, you can skip mobile-first design. You can also define and restrict the app size which would give you the added benefit of styling an app for one specific browser size if you so choose. Electron gives you complete control over how you want your user to view and interact with your app, just try not to let that power go to your head, ok?

We decided to build our app using Ember, an opinionated JavaScript framework that takes a lot of the decision-making out of the build process for a project. Ember spins up a complete app structure for you, including a customizable testing suite. (It’s always a great feeling to start building your app and already have some tests passing!) This is a very nice feature, unless you are the kind of developer that likes or needs to create their own project build. I have nothing against creating my own build, I even enjoy it from time to time, but you have to give it to Ember for the time saving factor, especially when you have a tight deadline, as we did. Ember is very specific about where files and functionality go. Electron and Ember work nicely together — I like to think of Electron as a viewing container for your app that you can customize in ways that you can’t on a website. Ember then provides the content and functionality of your app. If Electron is the bun, Ember is the burger.

Our goal was to complete this project within a time frame of seven days. Things started out so great! Although this was only my second experience using Ember, it was really starting to click for me how all the components, routers, templates, and controllers work together and I was feeling excited and confident. The Ember docs are very well written and do an excellent job of explaining and mapping out how the pieces work. In order to persist the user’s data we decided to integrate SQLite3 to create a database on the user’s OS. This is when our project came to a screeching halt. We spent over 48 agonizing hours trying to implement an adapter in Ember to translate data between our SQLite database and Ember Data. Over the course of the next several days, we reached out to several senior developers to help us debug, none of whom could isolate the exact problem. So, what are two resourceful developers to do when you’re mere days away from a looming deadline and you know you won’t have an MVP? You burn it down, of course!

A girl’s gotta do what a girl’s gotta do!

Burning an app down when you’re in deep creates both a sense of relief and a sense of fear. You can start fresh and hopefully avoid the pitfalls of your first iteration, but worry that you may not finish all the features you want to implement by your deadline. You just have to plow ahead and trust that your skills and your drive to succeed will enable you to submit most of the features on your docket. We chose to start over using jQuery as we thought it was a library we could implement in Electron at a rapid pace (considering we had about 2.5 days left until deadline). We even learned how to simulate a single page app using plain old jQuery (thank you jQuery!) through hiding and displaying elements based on user interactions. It was definitely a simpler implementation, while still presenting its own challenges. This time around, to persist our data, we installed electron-storage and were successfully able to get and set recipe data to a local JSON file on the user’s OS. Finally! A successful recipe storage system!

A Promise to give us the recipes we’ve been asking for!
Our recipe app in its current iteration — using jQuery and Electron.

While we didn’t accomplish all of the goals we laid out for ourselves in the prescribed time frame, we were able to successfully deliver a minimum viable product. I fully intend to continue extending this project in the future and add in many of the features we didn’t have time to build in our 7 day sprint. I want to implement image rendering from user upload and I am really excited to see what kinds of great features I can implement from the Spoonacular API. I’d love to be able to pull nutrition information into the app, add categorization of recipes, and detect food from text to make it a multi-faceted and dynamic app. Someday I want to revisit implementing this app using Ember but perhaps choosing a different database model. I enjoy SQL and am disappointed that we couldn’t get it to play nicely with Ember and Electron. I think our goals were solid and many people we shared our idea with were excited and wanted to have a copy of our app for their own use, so this probably isn’t the last you’ll hear from us! Above all, what I take away from this project is an ever-growing respect for single page app frameworks after experiencing the tedium of writing repetitive code across multiple pages. We will meet again Ember, tell Tomster to be ready for me!