Selleo Labs spółka z o.o.

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

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

[TOC]

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

[TOC]

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](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?

Do you want

Read Our Blog.
Make better products with us.

Read our articles on Selleo Blog

Business

Technology

Microfrontends To The Rescue Of Big Single Page Application Monoliths

Single-Page Applications: Ember vs Angular

Tell us about your project

Company

Our Services

Blog

Other Services

Countries

Awards & Certificates

Do you want

Read Our Blog. Make better products with us.

Read our articles on Selleo Blog

Business

Technology

Microfrontends To The Rescue Of Big Single Page Application Monoliths

Single-Page Applications: Ember vs Angular

Tell us about your project

Company

Our Services

Blog

Other Services

Countries

Awards & Certificates

Read Our Blog.
Make better products with us.