Learn by doing, help by sharing.

As a small software development studio, Ruby on Rails is our technology of choice. We love working with it and, 90% of the time, it suits our projects really well. But we know that sometimes, it’s just not the right tool for the job. So we always try to leave our preferences at the door when it comes to selecting the right technologies for our clients. We sit down, assess the technical and business requirements and needs, then draw a plan of action. Which includes choosing the right tools. And that’s exactly what we did when The Filter approached us to build their new internal project. The Filter build recommendation and relevance tools that power search, discovery and navigation within digital media. They use artificial intelligence to generate personalised experiences for their clients’ customers. What they wanted was a tool for their clients to have total control over what they wanted to display to their customers. The requirements. When you gather requirements, you need a lot more than just a list of features. You need to understand the context of the application, who the users are, how they will use the app, on what device(s) and what is important or not to them. In this instance, here are the (non-feature) requirements we uncovered: The application didn’t need any database management on our side. The Filter’s API would act as our database. The application wasn’t going to be used by millions. Only a few people on the The Filter’s clients teams were ever going to use this application. The application would mainly be used during working hours, and should perform work-related tasks as quickly as possible on a predefined set of web browsers. Even if we were going to be responsible for the creation of the original application, the Filter’s development team should be able to amend the application’s code when needed. Their team is composed of Microsoft .NET experts so they didn’t feel comfortable with Ruby, but JavaScript wasn’t an issue at all. The application was going to be big and mission-critical for their clients, and needed a long-term support solution. With that in mind, we started to test a few JavaScript-based solutions and from there, we were able to give them the right recommendations. EmberJS vs Angular and React. We have some experience with Angular and React, but none with EmberJS. However: Angular v1 (the only version available at the time) can lead to a messy feeling when you have a large codebase, so we discarded the option. React was still young and moving swiftly. Each new version could potentially break our app, and it would have been quite difficult to stay on top of it. EmberJS had always been under our radar, but somehow, we had never dedicated any time to explore further. On paper it ticked all the boxes: It offers conventions and enforces the Ember way to do things, similar to Ruby on Rails. It is in fact heavily influenced by Ruby on Rails. It uses most of the same conventions, namings and all, making adoption faster for us. It has good, comprehensive documentation and a decent amount of add-ons to everything we were going to need. So we decided to create a quick throwaway application just to get a feel for it. After a little bit more digging and assessments, we collectively decided that it was the right tool for the job. One year later... We’ve always been weary of writing blog posts about an experience with a new technology just days or weeks after having adopted it. So we gave it some time. We’ve been working on this project for more than a year now, and with an exponentially growing codebase and multiple developers from various background working on it, we firmly believe that we made the right choice to go with EmberJS. As with all things, EmberJS is not the right choice for everything. But it has grown to be the right choice for any serious/large single page application. React and Angular still have their place, but EmberJS seems to offer the same level of productivity and pleasant feeling as Ruby on Rails. Which, for a Javascript framework, is not an easy task. A few resources. In our journey of discovery, we found a few helpful resources, whether they are starting points or about more specific add-ons: The Ember Guides – the first place for you to check if you’re interested in learning Ember. EmberAddons – the equivalent of our beloved RubyGems. To use in combination with the Ember Observer EmberJS Discourse – the best place to ask questions about Ember if you’re new to it. Ember Weekly – inspired by Ruby Weekly or JavaScript Weekly, a weekly newsletter dedicated to EmberJS. I hope our positive experience with EmberJS will inspire you to give it a go. And please, do share your experience with us!

Card Nest website gets stylish redesign

AutonoMe and CookiesHQ release V2 of award-winning app

Introducing our latest partner - The Career Portal

CookiesHQ's highlights of 2018

The art of selecting features for your minimum viable product

How to create a maintainable and scalable search for your Ruby on Rails app

Get 30% off your Voxxed Days ticket through our DBM meetup group

How we optimise performance for our clients' Ruby on Rails applications

Rspec, system test, JavaScript and Select2 recipes

Being a co-founding couple - pros, cons, tips and tricks

Street2Boardroom helps street hustlers become entrepreneurs

Why we chose EmberJS to build The Filter's console app

We solve problems and achieve goals.

It all starts with a chat