It sometimes happens that a project does not get launched on time, it exceeds the initially planned costs, or lacks some of the required functionalities. Why is that? There might be several reasons for it: 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. But 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 the various technologies used to implement SPAs.
What are SPAs?
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.
The history of Single-page applications
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.
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.
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 a new behaviour. They ensure that the traditional HTML elements become more interactive.
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 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 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.
If you are considering the technologies from a skills point-of-view, Ember.js provides programmers with a set of tools and a bunch of rules and conventions that need to be mastered and followed in order to be able to enjoy all its features. If you are not ready for the steep learning curve, perhaps Ember.js is not the best solution for you. Angular.js, on the other hand, is much more versatile and flexible, as there might be several ways to achieving one thing, but it also comes with its own drawbacks.