It sometimes happens that a project does not get launched on time, exceeds the initially planned costs or lacks some of the required functionalities. Why is that? There might be several reasons for this: project management, vague requirements, poor technical performance or constant changes to the project scope.**
There is nothing particularly unusual in the fact that customers want to implement some changes, especially when they are presented with an application for the first time. However making changes is often costly, time-consuming and requires extra effort. Thus changes introduced may have a significant impact on the application in the later stages of implementation as well as the final price. Many techniques are used to minimize the number of changes, but it is not always possible to eliminate them.
A good way to reduce extra work is by turning to Single-page applications. They are perfect for a number of platforms, allow to use server side in a minimalistic way and provide a fairly fluid user experience. The article briefly presents the concept of SPAs as well as explores the pros and cons of using Ember.js and Angular to implement SPAs.
What are SPAs?
A crucial difference between Single-page applications and standard ones is the one-page interface and moving logic from the server to the client side. Most of the application logic is written with client-side technology using JavaScript and is executed in the browser. HTML markup, JavaScript and CSS are loaded once when the application starts, while all the other required resources are retrieved dynamically when needed. One example of a SPA is Gmail.
The history of Single-page applications
The history of SPAs begins with the introduction of AJAX in 2005. AJAX is a JavaScript-based technology that makes it possible to fetch data from the server in real time. The interaction with the server is done without reloading the entire document, in an asynchronous manner. This is to enable a more dynamic interaction with the user than in the traditional model, where each new data request meant that the whole HTML page had to be reloaded. The AJAX technology made it possible for the content to be updated on the same page. However, a serious drawback of the AJAX technology is that its implementation within a website usually requires fairly strong programming language skills. The problem was solved with the introduction of jQuery, which was designed to make client-side HTML scripting and building AJAX websites much easier.
The next step came with Backbone.js and the popularization of the MVC framework. An application based on the MVC model contains three separate components: models (which process database logic), views (user interface components) and controllers (which contain the logic that controls the whole application). With MVC frameworks, web programmers are now able to create bigger Single-page applications than they used to.
The Backbone.js framework would not be as functional if it were not for its integration with the jQuery / Zepto libraries and Underscore.js / lodash.js. As a result, many operations have been simplified and can be performed more quickly. Another advantage of Backbone.js is its stability and access to technical documentation and numerous case studies. There are quite a few professional web applications available on the market that were created using Backbone.js. What is more, the framework also enjoys one of the largest communities of users, which is particularly helpful if you have any questions to ask or need a tutorial.
What are the benefits of SPAs?
As previously mentioned, Single-page applications rely on client-side operations and on performing the functionality within a single page that relies on JavaScript and AJAX. There are several benefits to this solution: one of them is greater efficiency, which results in better and more native-app-like UX.?
If the majority of application features are executed on the client side, the server load is smaller, thus allowing the application to work with more users. Consequently, the maintenance of the application is much more cost-efficient.
SPAs usually operate through two independent paths: a frontend and a REST API, which only redirects the request to the database. Some of the apps can communicate directly with the frontend.
What is more, unlike traditional web applications, a SPA can go offline. When users do not have access to the network, they can still use the app and all the changes will be synchronised later. It can also be a competitive advantage – if other apps have a similar range of functions, but do not operate offline; at least some users are likely to opt out for the solution with offline mode.
Another benefit worth mentioning, is the fact that because with SPAs more logic is moved to the client side, frontend web developers are more independant and can implement features with less dependency on backend skills.
Ember.js
In December 2011 the project previously known as SproutCore 2.0, created by Yehuda Katz, was renamed to Ember.js. It is an open JavaScript library that makes it easier to write client-side web applications that are competitive to native applications; the solution is based on the Model-View-Controller (MVC) pattern. Its core concepts include routes, templates, models, controllers, views and components.
The templates are written in the Handlebars templating language, backed by a model and updating automatically whenever the model changes. Then there are routes, whose purpose is to make the templates display a particular model. Every route is connected to a given model, which stores the current state of the application.
Controllers respond whenever a user interacts with a template. They are also responsible for exposing the data to the template. Views are generally created in order to convert primitive browser events to meaningful actions in the application. These are later sent to the controllers or routers, which are responsible for reacting to the event. The basic function of the components is to define application-specific HTML tags and implement their behaviour with the help of JavaScript. Thanks to components developers can create reusable elements and use them to simplify the templates.
Angular.js
Angular.js is another open-source web application framework used to create single-page applications whose history starts in 2009. It was developed by Miško Hevery and Adam Abrons and is now maintained by the Google community.
The philosophy behind Angular.js is based on a distinction between declarative and imperative programming. According to Angular.js developers, the former should be used for building UI and wiring software components, while the latter is perfect for expressing business logic. It is based on a concept that HTML, while excellent for static documents, was never designed for rich web applications. To overcome this limitation, Angular.js enhances the HTML to make it suitable for describing dynamic views.
The most crucial components of an Angular.js application are the so-called directives. These are markers on a DOM element, e.g. an attribute or a CSS class, which are added to implement new behaviour. They ensure that the traditional HTML elements become more interactive.
The building blocks of AngularJS are organized into models, views, controllers, and (optionally) services. The model refers to JavaScript objects which correspond to the data the application can access.
The role of views is twofold: to provide the user with the data from the models in a visual and useful format, and to translate user interactions into actions specific to the application. Controllers define the application logic and are responsible for connecting models to the right views. Services can perform various tasks from providing remote data to ensuring the implementation of an algorithm.
Ember.js and Angular.js – similarities
Both of the frameworks in question are open-sourced and aimed at creating single-page applications using the MVC model. The application is divided into three components (a model, a view and a controller). The binding code is moved to a separate class file and the code can be reused several times.
They also tend to push the templating to the browser in order to free the server, which now only fetches data. As a result, client-side developers have greater control over the templates. It proves useful when you want to update one section of the website without refreshing the whole page. It is a great solution with which the code can be easily reused and maintained.
Another similarity between Ember.js and Angular.js is that they both use two-way data binding, thanks to which developers can avoid writing some parts of the boilerplate code, which would be used for manipulating the DOM in regular web apps. Both Angular.js and Ember.js share a similar concept of routing.
Ember.js and Angular.js – differences
There are a few differences between the two frameworks, particularly when it comes to templating. With Angular.js, the templating engine is HTML, while Ember.js uses handlebars, which enable embedding expressions that change what is displayed. Ember requires additional Handlebars and jQuery libraries to function, while Angular can stand on its own.
When it comes to the learning curve, it can be quite steep in both frameworks. Learning Ember, however, takes more time at the beginning, as it requires developers to follow a convention, as opposed to Angular; the latter offers more freedom in this respect, but this comes also with a negative side – the codebase might be of much lower quality, if the developers involved in the project have a low or varied level of skills. Angular seems quite easy at first, but once you have mastered the very basics the learning curve gets steeper.
Because of the technique called “dirty checking”, which is used for monitoring the changes, Angular.js may have problems updating an interface with a large number of bindings. The process of dirty checking involves scanning each object together with its bound properties in order to compare the current value to the previous one. The bigger the number of objects, the more expensive it becomes. Performance issues may be encountered when the application displays more than 2000 bound objects at a time. With Ember, you do not need to think about such limitations.
It is also worth mentioning that a number of professional service applications and big companies decided to use Ember.js over other MVC frameworks. These are Yahoo, Yapp, Zendesk, Discourse, Groupon, LivingSocial and many more. All said, there are projects where Angular may very well satisfy the requirements and is thus a valid technology to use – it may even, for example, be a faster option to choose.
Ember.js or Angular.js – which should I choose?
On the whole, it seems to us that Ember.js may be more suitable for large-scale, more ambitious and long-lived projects, while Angular.js appears perfect for smaller applications or components added to the already existing applications.
Ember.js provides programmers with a set of tools and a bunch of rules and conventions. The solution tends to make crucial decisions for you, saving time usually wasted on researching and combining libraries together. High performance, easy APIs, amazing routing and a convention over configuration philosophy is what makes Ember a great and reliable technology, the choice for your next Single-page application.
If you need help with your Ember development, feel free to contact our team of experts.
We have also created a downloadable Ember testing guide that will help you improve your work and provide best practices.
