I possess over 9 years of professional experience working with many clients and developers from all around the world. I have a variety of front-end programming skills and a vast knowledge of code styles. I enjoy sharing my skills and knowledge with others by contributing to the Open Source community and mentoring new developers.

Dariusz Pieńczykowski

As a CEO I am responsible for investigating and assessing new and existing technologies along with processes to develop innovative offering concepts as well as the technology strategy and vision. Being experienced in many programming languages and frameworks I create innovative concepts and solutions that help our customers gain a competitive edge in the fast-paced, dynamic business environment.

Dawid Pośliński

My diverse educational background allows me to approach software development problems from different sides and angles. I have bachelor degrees in Sociology and IT in Business. I am an agile Team Leader and Project Manager. Sport and Combat training allowed me to learn that success comes with hard work. Along came the self-improvement, loyalty, discipline and self-control.

**ABOUT MY TEAM** “...there is no **I** in **Team**”

My Team has an in-depth and long term experience (**4 years** on average) and currently consists of **9 members**. We specialize in **Ruby on Rails**, **React.js**, **React Native** and **Node.js**. We work from **one** **office** which guarantees close and **successful** **cooperation**. We use the following communication tools: Slack, Pivotal Tracker, Trello, Jira and Google Hangouts.

***"With few exceptions, the best players are the hardest workers"***

I love coding and I **enjoy** **solving** **various** **business** **problems** with my programming skills.

I collaborate with CTOs, Product Owners and their development teams to support the growth of their businesses with maintainable and scalable software solutions.

Radosław Jędryszczak

Tomasz is a Tech Expert with an enormous experience in both back-end and front-end solutions. He ensures that quality processes and automations are carried out through the whole software development cycle.

Tomasz Bąk

Proper frontend development is highly challenging, but scaling frontend development such that several teams can work simultaneously on large and complex products is much harder. We will address the recent trend of breaking up frontend monoliths into smaller, more manageable modules, which has become more common. This architecture improves the effectiveness and efficiency of teams collaborating on frontend code. It may be your goal is to build a responsive or progressive web application. But, there's no secure place to begin integrating these features into existing code. It may also be your goal to use new JavaScript language features. Yet, you find it hard to merge the critical build tools into your existing build process.

In another scenario, **you may want to scale development to involve many teams**. Yet, the coupling and complexity in the existing monolith could hamper efficient progress. This is because people are bound to step on one another's toes. These real issues can negatively affect everyone's delivery potential. As a result, customers may lose out on a high-quality experience.

## Traditional monolithic software

Ancient monoliths or monolithic systems had everything bundled inside one deployable unit. Some monoliths may be quick to design and simple to deploy. But, they are not as agile because the tiniest changes often need full redeployment. Here, we're talking about microservices. They are a more popular architectural concept. But micro frontends cater to the frontend. Instead of one significant, unwieldy frontend architecture, we have several small parts (modules). You develop each one in isolation.

Microservices revived the old idea of building smaller, reusable pieces of software. Each piece only has a minimal coupling to another. Each piece is also efficient at doing one thing well. Thus, they share no dependencies. Developers can also work on them and deploy them independently. Large organizations have used this architectural choice for their projects. Microservices architecture is gaining ground. The reason is that it breaks down the limitations of monolithic backends.

Some significant benefits of microservices include:

* fault isolation
* technology independence
* early scaling
* continuous development and deployment

The resounding success with server-side solutions has not simplified how frontend codebase works. It also does not address how it complements the backend services. Single Page Application (SPA) is popular for superior performance, user experience, and conversion. But, SPAs are also reliant on a monolithic architecture. As SPAs scale, their maintenance and deployment become slow. Every small change is needing regression testing. This increases the efforts in implementation, also leading to high-risk memory leaks

Microservices work to tame issues with traditional software architecture. This happens through following a modular strategy for development. Front-end development can occur through the concept of the micro-app. Hence the name, micro frontends. But, what are micro frontends? Micro frontends are the microservices approach to frontend web development. Again, one should ask why developers consider them to be so. Besides, what does a developer need to begin micro frontend development?

<Baner name={software-development} />

## What is micro frontends architecture?

Micro frontends describe the modular approach to web development. An application is broken up by its pages and features; each feature becomes the responsibility end-to-end of a single team. A reusable, component-dependent architecture employs multiple pieces of code. It combines these components to create a monolith frontend which sits on a layer of backend services.

A micro-frontend also makes sure that **each feature is individually developed and tested**. With micro frontends, the codebase is much smaller. It is also cohesive, meaning it is convenient to maintain. **It decouples the features and pages, allowing independent teams to work on them**. Now, you can understand why **it is much easier to upgrade parts of an application**. It is also **easier to update and rewrite parts of the application** than it would a monolith.

![](https://s3.amazonaws.com/a.storyblok.com/f/86602/800x501/35e0f06680/microfrontends2.png)

Sample application structure that mounts multiple microfrontends inside one container application. Apps can communicate with each other via common message bus with standardized interface:

![](https://s3.amazonaws.com/a.storyblok.com/f/86602/800x411/b8778dff07/microfrontends1.png)

## Which to choose – monoliths or Microfrontends – and why

It is essential to decide whether to go the route of a monolith SPA or micro frontend architecture. This decision must come before web application development begins. To be fair, micro frontends do not suit every project. They come with their own set of benefits, but they are not ideal for every case.

**The complexity and size of the project** are two critical factors in making this decision. But, a big team with subteams may work on a project. **Each subteam will work on individual modules and functionalities**. A micro frontend architecture is a relevant decision. A small- or medium-sized project that needs less regular releases or updates. The teams also depend on each other for releases. Here, they can opt for a monolithic architecture for frontend web development.

## The cost of adopting a microfrontend architecture

Using micro frontends offers microservice-like benefits. It's important also to point out the cost of developing micro frontends architecture. Everything does come at a price in software architecture. Some micro frontend implementations can engender dependencies duplication. It increases the number of bytes users must download. Also, the dramatic rise in team autonomy can lead to fragmentation in team function. But, these are manageable risks. The benefits of micro frontends even often outweigh the costs.

## Testing

Testing doesn't quite differentiate between monolithic frontends and micro frontends. In general, the methods for testing a monolithic frontend applies to individual micro frontends. So, each micro frontend should have its comprehensive suite of automated tests. This strategy ensures quality and code correctness. The apparent disparity would be integration testing of the various micro frontends. Use the container application for this. This can happen using any functional/end-to-end testing tool you prefer (for instance: Cypress) yet, tread with caution.

Functional tests only cover aspects that you may not be able to test at a lower level of the Test Pyramid. This means unit tests should cover your low-level business logic and rendering logic. You can then use acceptance tests to confirm that you correctly assemble the page. For example, you may load up the fully-integrated application at a particular URL. You may also assert that the hard-coded title of the relevant micro frontend is available on the page. If your user journeys span several micro frontends, use functional testing to cover those. But, ensure the acceptance tests focus on validating the integration of the frontends. It should not impact the internal business logic of each micro frontend. Unit tests should cover these beforehand. Consumer-driven contracts can help to specify the interactions between micro frontends directly.

### Sample solutions

* [https://single-spa.js.org/](https://single-spa.js.org/) (integrates multiple frameworks)
* [Ember Engines](http://ember-engines.com/) (ember dedicated solution for micro-frontend approach)

## Conclusion

Frontend codebases become more complex, creating a growing need for more scalable architectures. There must be boundaries establishing the appropriate levels of coupling and cohesion. These are vital for domain and technical entities. It has to be easy to scale software delivery across independent, autonomous teams. This approach is not the only one. There are many real-world cases where micro frontends deliver these benefits. This approach works with legacy codebases and new ones too. Businesses can assess if micro frontends are appropriate for them or not. That said, frontend engineering and architecture continue to evolve in exciting ways. Every serious developer should keep abreast.

If you prefer watching to reading, here is a video on the topic:

<YouTube id="0HTPmOeBsog" />

Proper frontend development is highly challenging, but scaling frontend development such that several teams can work simultaneously on large and complex products is much harder.

Microfrontends To The Rescue Of Big Single Page Application Monoliths

I’ve been using EmberJS on a daily basis for over a year now. In this short article, I will focus on some benefits of choosing the EmberJS framework as a tool for building a single-page application (SPA). I will mostly describe business advantages of that choice rather than technical benefits.



To begin with, I want to highlight that the EmberJS framework has a pretty steep learning curve in comparison to its competitors such as [React.js](https://selleo.com/react-expert-developers-team) and Angular( I mentioned [React.js](https://selleo.com/react-expert-developers-team), but in fact, React is more like a library than a complete solution as it requires some additional extensions to achieve the same things as EmberJS or Angular). Even if it has the steep learning curve, it will pay off the time invested into learning Ember.



### Predictable

While you plan your software related business, you should determinate potential risks. When you select a given solution, you don’t want to change it in the near future for some other one (because of costs, slowing down new features arrival, losing customers, potential new bugs, etc.).



The front-end world changes very rapidly. Because front-end tools are usually open sourced, the authors of these tools don’t need to support everything for a very single release. That drives us to the problems with upgrades. The EmberJS’s creators decided to address that concern of product owners. They have introduced a Long-Term Support (LTS) release channel of their product (with a 6-month support for the given version of the framework). But this is not the only difference in comparison to its competitors.



### Structured

EmberJS follows the **convention over configuration** principle. Similarly to Ruby on Rails, there is a predefined structure that most developers follow. What does it mean for the product owner? In the case of changes in the development team, a new team member, who already knows EmberJS, can start to work on it sooner than before. He doesn’t have to learn as many team-specific practices as before because the tool enforces developers to use its rules. It also means that the human resource lock-in is smaller and it is easier to scale up/down your development team in the future.




### Solid

EmberJS has gone through a long journey. The biggest changes have already taken place, and every new release makes it easier to migrate from one version to another. Moreover, following current version of the EmberJS framework is pretty straight forward. Another important remark: Pay attention to who is actually using EmberJS. There are plenty of big names involved in using and improving this solution, the list of whom you can find on [Built With Ember](http://builtwithember.io/). For the sake of example, I would mention Apple, Sony or GoDaddy.



To sum it up. If you really care about your business stability, consider my advice. I highly recommend the EmberJS framework as a **tool for medium/large and single-page applications**. Of course, it always depends on your development team preferences, such as a specific use case or some other aspects. However, don’t skip this solution at the beginning only because it seems to be too complex. Instead, **check out EmberJS if you are looking for a solution which is likely to last for a long time**.

If you need help with your Ember development, feel free to contact our [team of experts](https://selleo.com/ember-expert-developers-team).

We have also created a downloadable [Ember testing guide](https://selleo.com/ebook/ember) that will help you improve your work and provide best practices.

<a href="/ebook/ember">
  <img src="/uploads/banner-ember.jpg">
</a> <br>

I’ve been using EmberJS on a daily basis for over a year now. In this short article, I will focus on some benefits of choosing the EmberJS framework as a tool for building a single-page application (SPA). I will mostly describe business advantages of that choice rather than technical benefits.

Why Don’t You Pick EmberJS When Building Your Next Single-Page Application?

**If you are a web developer or a businessman, wondering what web application to choose for your specific needs, take into consideration Angular.js. **This open-source framework, supervised by Google and individual or corporate development teams, can be used to s**implify the development and testing of single-page applications**. Angular.js developers use it for building dynamic mobile and desktop Web applications to accomplish their tasks in the best possible way.

Many developers decide to learn and use Angular.js because this framework allows them to use HTML as a template language and then develop its syntax to express their application’s components clearly. **[**Angular.js developers**](https://selleo.com/)** state that what saves their time is the Angular’s data binding and dependency injection solutions. Further, they explain that as a declarative language for static documents, HTML brings about much effort to solve some impedance mismatch between dynamic applications and static documents. Therefore**, Angular.js developers introduced a construct called directives to teach a browser new syntax**, and this way minimize the discrepancy occurring between document centric HTML and time consuming steps to create new HTML constructs. The directives introduced to Angular. js by developers include,

* Data binding
* Document Object Model (DOM) control specifications for repeating, showing and hiding DOM elements
* Support for forms and form validation
* Adding new behavior to DOM fragments, such as DOM event handling
* Grouping of HTML into reusable components. (AngularJS Guide, 2016)

Thanks to many good solutions, **Angular.js developers** **get full control over the initialization process in automated tests**. For example: A developer can load only necessary services and successfully perform automatic tests using the separation feature module. Besides, if following “one file – one module” principle, they do not need to remember module loading order.

Concluding, we want to signalize that because of its large community (the core team members and many contributors), the [Angular.js open-source framework has been evolving dynamically](https://selleo.com/blog/migrating-to-angular2). A lot of Angular modules can be found at the Angular Modules website (most popular include AngularUI for AngularJS, Angular directives for Twitter’s Bootstrap, Angular authorization, and restangular). So, why not to [choose Angular.js for your next project](https://selleo.com/contact)?

If you are a web developer or a businessman, wondering what web application to choose for your specific needs, take into consideration Angular.js.

With Angular Js Developers Can Bootstrap Their Apps Easily

**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 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](https://selleo.com/ux-design).?

![Img](https://a.storyblok.com/f/86602/571x294/643d7698e1/single-page-app.png)

**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](https://selleo.com/front-end-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](https://www.yehudakatz.com/)**, 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.

![Img](https://a.storyblok.com/f/86602/225x225/75a20ca85b/ember-logo.jpg)

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](https://twitter.com/mhevery) 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](https://selleo.com/ember-expert-developers-team).

We have also created a downloadable [Ember testing guide](https://selleo.com/ebook/ember) that will help you improve your work and provide best practices.

<a href="/ebook/ember">
<img src="/uploads/banner-ember.jpg">
</a> <br>

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?

Single-Page Applications: Ember vs Angular

### BUILDING SINGLE-PAGE WEB APPLICATIONS WITH RUBY ON RAILS

## **What are single-page apps?**

The pursuit of better user experience changes the way we think about browsing the web. As the Internet matures, we abandon the classic approach whereby the user is presented with a handful of URLs which reload the page when clicked; **the new approach aims to make the web application work seamlessly**. This is achieved by retrieving all the code needed with a single-page load and, subsequently, changing only some elements on the page, depending on the actions taken by the user. Such an approach has a few benefits. It ensures a fine-grained control over the user experience as it eliminates network latencies and disruptions caused by page redraws. It can also save resources like bandwidth and CPU time on the server side.

There are various techniques which allow to retain a single-page during the client-server communication process. On a higher level of abstraction, the main difference between these techniques boils down to the opposition: **“thick server architecture vs. thin server architecture” or “fat client vs. thin client”**. A “fat client” is able to perform many tasks without accessing the server. In contrast, a thin client, generally, does as little processing as possible and depends on connecting to the server each time user input needs to be processed or validated.

There are certain advantages to making the client thin and delegating all the data processing, such as, for example, rendering appropriate HTML and/or JavaScript, to the server. For instance, it is easier to develop and deploy web applications where almost the entire code runs on the server. The disadvantage of frequent server access is that your thin-client single-page application is as fast as the network connection between the client and the server. So, just as **the user experience was affected by page redraws, it is now limited by the request/response scheme.** Having taken an action in the system, the user is presented with spinners or flash messages like “work in progress…”, rather than immediate results. [Some say](https://alexmaccaw.com/posts/async_ui) that single-page apps could take another step forward and make the interfaces completely non-blocking. The interactions should be resolved instantly, without spinners or “please wait…” messages affecting user experience. And decoupling network requests from the application interface is the only way to **escape the “”jail” where “the web application is as fast as the network connection”.**

Moving the application logic to the client would not be possible without the help of Javascript.  Fortunately, there are a number of Javascript frameworks that let you pull some business logic from your [Ruby on Rails](https://rubyonrails.org/) application to the client side. But before I dive into reviewing Javascript frameworks that let you build great single-page applications with Ruby on Rails, I feel obliged to answer an important question:

### **Why Rails?**

Rich and smart single-page applications require a backend to provide data validation, access control support, authentication and session management, data calculations and all the other support you would expect from a webservice. **Rails has it all**. ActiveRecord as an orm and validation module, Ruby gems like [devise](https://github.com/plataformatec/devise) and [cancan](https://github.com/ryanb/cancan) for authentication/authorization respectively, and you name it. Some of these solutions are baked-in in vanilla Rails, some are distributed as gems and plugins (just check the Ruby ToolBox for the available solutions, e.g. [authentication](https://www.ruby-toolbox.com/categories/rails_authentication.html), [access control](https://www.ruby-toolbox.com/categories/rails_authorization) and [orms](https://www.ruby-toolbox.com/categories/orm) ). Of course, a rich single-page application does not rely on a Ruby on Rails backend for rendering views / templates and sending back HTML documents. Instead it requires JSON objects which a Ruby on Rails application can deliver without sweat – let’s just mention [Jbuilder](https://railscasts.com/episodes/320-jbuilder) and the other [nifty ways of passing data to Javascript](https://railscasts.com/episodes/324-passing-data-to-javascript). I could dwell [on the topic for long](https://railscasts.com/episodes/348-the-rails-api-gem), showing how easy it is to use the Ruby on Rails framework to create applications meant to respond with JSON. Rather than do that, I would prefer you to use the links to access specific ready-made solutions which speak louder than words.

On the whole, with the approach, we move the business logic to the client. One might wonder if we really need all the backend functionalities. Unfortunately, we do. Since you do not have complete control over what your client application does, you **cannot trust the client blindly**. Hence, you will often find yourself duplicating the code on both the client and the server side (for example, validations).

The Javascript frameworks for building single-page web applications are usually back-end agnostic. In fact, you can leave the ins and outs of the data to the API provided by the application build with Ruby on Rails, [Django](https://www.djangoproject.com/), [Node.js](https://nodejs.org/) (the [Express](https://expressjs.com/) framework) or any other platform that suits you. Yet RoR with its flexibility and robustness does stand out among the other competitors. Still not convinced? Then let me add that a lot of [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) / [MVVM](https://en.wikipedia.org/wiki/Model_View_ViewModel) **Javascript frameworks for building single-page apps are inspired by the Ruby on Rails framework itself**. To give an example, [Yehuda Katz](https://yehudakatz.com/), a member of the Ruby on Rails core team, is championing one of the frameworks – [Ember.js](https://emberjs.com/). [Batman.js](https://batmanjs.org/) developers are advertising their framework as: [“APIs are heavily inspired by Rails and designed to make Rails devs feel right at home”](https://www.webappers.com/2011/12/28/batman-js-for-building-rich-single-page-browser-apps/).

In the following sections of the article, I will focus on the Javascript frameworks for building single-page web applications and I will discuss them from a Ruby on Rails developer’s perspective. **Javascript MVC/MVVM frameworks for building single-page web application with Ruby on Rails**. There are a number of Javascript frameworks suitable for building single-page web applications. The ones that make Ruby on Rails developers feel at home might be:

* Batman.js
* Backbone.js
* Ember.js

What about [Knockout.js](https://knockoutjs.com/) or [Spine.js](https://spinejs.com/) or yet another solution? I will comment on the other contenders that did not make it into my list of the prefered choices as well as try to explain why I chose to omit them.

To start with, **what do we expect from a good Javascript MV* framework**? Before I get to the point, the asteriks after “MV” is there to capture the two major philosophies behind Javascript frameworks:  the Model-View-Controller and the Model View ViewModel paradigms. **The best definition of the MVC pattern I have read is the one introduced by the Smalltalk’s inventors**: Model-View-Controller [“is the concept of encapsulating some data together with its processing (the model) and isolate it from the manipulation (the controller) and presentation (the view) part that has to be done on a UserInterface”](https://c2.com/cgi/wiki?ModelViewController).

The MVVM paradigm originates from MVC. The model and view layers are similar to the layers defined in MVC. Basically, the model layer holds the data while the view layer refers to the elements such as buttons, labels, and other controls displayed by the [GUI](https://en.wikipedia.org/wiki/GUI).The view model can be described as a layer that fills the gap between the ‘real’ state of data in the model and the concept of displaying it in the view.

To clarify, let me furnish an example: there is an application which has a user profile page which displays a picture uploaded by the user. The avatar image information is stored in the User model. Your job as a developer is to write the ‘displaying’ code. Everything works well if the user has uploaded the avatar picture before. If he did not, you should display an image placeholder instead. **Where do you place the code that determines whether to display an image or a placeholder?** Such code does not fit into the model since it is view-related. You should not place it in the view as it is not an appropriate place for the logic. A helper method? Could work. But helper methods are just simple methods in a global namespace and you feel that something more specific to the model would be a better idea.

**The example above pictures one of the problems an MVVM architectural design is trying to solve by introducing a ViewModel layer**. The MVVM concept is barely present in in Ruby on Rails. The existing [decorator / presenter solutions](https://www.ruby-toolbox.com/categories/rails_presenters) are often quite tightly coupled with the model layer. On the contrary, as defined by the MVVM pattern underlying conditions, the ViewModel should not necessarily be aware of where its data comes from.

Thus the considerations of MVC vs. MVVM were a factor behind the selection of specific solutions for the list compiled. Ruby on Rails developers are far more familiar with MVC rather than MVVM frameworks. It should be noted though, that the MVC implementation in JS frameworks is a bit different from its counterpart in Rails. For the purpose of this article, I will make use of TodoMVC – “a project which offers the same Todo application implemented using MV_ concepts in most of the popular JavaScript MV_ frameworks of today”.

[Batman.js](https://batmanjs.org/) According to the creators, Ruby on Rails developers should [feel at home](https://batmanjs.org/docs/batman.html) with [Batman.js](https://batmanjs.org/). The reason for this might be the fact that Batman.js was extracted and shaped into a framework from an existing Ruby on Rails application: [Shopify](https://www.shopify.com/). Batman.js is a framework for building rich single-page browser applications. It is written in CoffeeScript and its API is developed with CoffeeScript in mind. Batman.js is suitable for running both in a browser and in [Node.js](https://nodejs.org/) ( v0.4.x and v0.6.x). As for the browser compatibility, Batman.js developers are targeting Chrome, Safari 4+, Firefox 3+, and IE 7+. The code samples from the project site should illustrate why a Ruby on Rails developer may easily fall in love with Batman.js.

I do feel at home. The feeling may very well be aroused by Coffeescript leveraging, which was inspired by the Ruby language. As regards the implementation of the Batman.js sample application in TodoMVC project, it is hard to decide what to choose: the original coffeescript file or the javascript conversion. The former reflects the spirit of the framework better and lends itself better to present the features. The js-converted version ensures consistency –  all other examples are written in Javascript. However, the automatically converted code looks just ugly and is very hard to read. Since I consider using Coffeescript an advantage, I eventually decided to use the Coffeescript version.

The Todo app [code](https://github.com/addyosmani/todomvc/blob/master/labs/architecture-examples/batman/js/app.coffee) is very well organized and the structure resembles the architecture of an RoR application: there are routes, model and controller sections. Below, you will find a Batman.js model example from the TodoMVC project. It is a Todo application class with a Rails-style looking definitions concerning encoding, persisting, validations and storageKey, as well as accessors definitions:

In the example above, we add a class name to a list element if the todo.completed binding evaluates to true. Other examples of handling complex behavior are data-mixin and data-event-* attributes. In this case, the data-event-change will attach respective event handlers to the specified node:

As you can see the computed properties allow you to treat a function definition as a regular property. What is more, the computed properties can have dependencies on other properties and if you list the dependencies properly, Ember.js makes all the binding updates when necessary. Neat!

If you would like to see how Ember.js can integrate with Rails, read the case-based articles by [Zack Hubert](https://twitter.com/#!/zhubert) :

* [Ember.js and Rails, Part 1: Rails Setup](https://www.zhubert.com/blog/2012/04/26/ember-dot-js-and-rails-part-1/)
* [Ember.js and Rails, Part 2: Client Side Data](https://www.zhubert.com/blog/2012/04/28/ember-dot-js-and-rails-part-2/)
* [Ember.js and Rails, Part 3: Client Routing and Layout](https://www.zhubert.com/blog/2012/05/01/ember-dot-js-and-rails-part-3/)
* [Ember.js and Rails Part 4, Client Views](https://www.zhubert.com/blog/2012/05/07/ember-dot-js-and-rails-part-4/)
* [Ember.js and Rails Part 5, Naive Real-time](https://www.zhubert.com/blog/2012/05/11/ember-dot-js-and-rails-part-5/)

### Ember.js pros and cons

**Pros:**

* **Support for organizing views in a hierarchical order.** Ember.View also allows you to encapsulate HTML templates, which enables you to use views composition techniques in your application (reusing templates).
* A big part of Ember’s appeal comes from **leveraging Handlebars.js declarative templates**. After setting up the DOM (using helper methods like _{{view}}, {{action}}_ and _{{bindAttr}}_), you no longer have to worry about keeping the DOM up to date.
* Ember.js offers a lot of support for integration with Ruby on Rails and boosts developers productivity.
* Very powerful implementation of **bindings and computed properties**.
* Due to Ember.js design, it is easy to mix Ember.js with other Javascript libraries.

**Cons:**

* Ember.js still exhibits **limited adoption**. Yet the project website features some respectable brand names, such as [Zendesk](https://www.zendesk.com/) or [Square](https://squareup.com/).
* The Ember.js framework is in a state of flux as the framework has yet to hit 1.0. A lot of framework elements are changing and **some of its parts are definitely not production ready**, like the Ember Data module.
* If I had written this article a few months ago, I would, without doubt, have added “Poor documentation” in the cons section. But Ember.js maintainers have recently refreshed the project website with some nice docs and guides. For all the effort, you can still find some undocumented, quirky parts in the Ember.js framework.
* Ember’s view binding system implementation can sometimes be the cause of poor performance of a single page application.
* Ember.js loses against batman.js and Backbone.js when it comes to size: **42k min+gzip**.

### Summary
The selection of a technology stack for single-page web applications can be executed in two steps:Choosing the right tool/framework for the back-end service / API,

Choosing the right library / framework for the client part of the application.

As for the first step, I presented the arguments why Ruby on Rails with its RESTful approach, decent JSON objects manipulation support and backend features is a decent choice. What about the client side of the single-page application? I have made an attempt to answer this question **from the perspective of a Ruby on Rails developer**.  If your choice is Ruby on Rails, it is optimal to choose the Javascript framework that integrates well with REST services and follows the MVC pattern. And vice versa, if you have chosen a specific Javascript framework make sure the back-end technology is suitable for the framework. There are many other great JS frameworks for building rich client-side applications. I have, however, found them to be **less suitable for Ruby on Rails**. For example, it seems that [Cappuccino](https://cappuccino.org/) and [SproutCore 1.x](https://sproutcore.com/) force native-like paradigms, which lack a good presentation layer. [Knockout.js](https://knockoutjs.com/) does not provide the abstractions for async communications with the server nor does it play well with out-of-the-box REST services. Similarly, [Spine.js](https://spinejs.com/) is optimized more for local storage scenarios rather than for the integration with REST services. If you would like to share your experience concerning the integration of Ruby on Rails with the frameworks featured in this article (or those I chose to omit), feel free to post them in the comments section. **I will be happy to hear from you**.

As the Internet matures, we abandon the classic approach whereby the user is presented with a handful of URLs which reload the page when clicked; the new approach aims to make the web application work seamlessly.

Read our articles on Selleo Blog

Business

Technology

Microfrontends To The Rescue Of Big Single Page Application Monoliths

Why Don’t You Pick EmberJS When Building Your Next Single-Page Application?

With Angular Js Developers Can Bootstrap Their Apps Easily

Single-Page Applications: Ember vs Angular

Building Single Page Web Applications With Ruby On Rails

Tell us about your project