TripleTen experts
TripleTen.Coding Bootcamps

IT career tips

Sign up for our newsletter to get future-proof advice from tech industry experts.

Stay in touch
TripleTen.Coding Bootcamps

TechStart podcast

Explore the realities of changing careers and getting into tech.

Listen now

This is the third article in our Frameworks series. Here are the first and second articles.

Getting things in order: Flux

Flux is not only a library for storing the global state of an application, it's also an architectural pattern. It was primarily introduced as an addition to React, although it can be applied anywhere. In other words, Flux is framework-agnostic.


Passing data between components in React, like in any application that uses an MVVM approach, looks like this:

Typical interaction pattern for many MVVM frameworks

Flux was designed to solve this disaster. The main goal of Flux is to make the data movement in an application predictable, that is, it should always follow the same path.

Flux consists of 4 main parts: the dispatcher, stores, actions, and views. These can interact with one another in various ways:

  • The dispatcher is an object that receives actions and directs them to stores**.** There is always a single dispatcher for the entire application.
  • The store stores data. It responds to an action dispatched by the dispatcher and then broadcasts an event declaring its change.
  • Actions are simple objects that can send views for processing to the central dispatcher.
  • Views are already familiar to you; these are React components in most cases.

This is what a unidirectional data flow looks like:

Data flow using the Flux architecture

The view sends an action to the dispatcher. It, in turn, notifies all the stores that are registered with the dispatcher. In turn, the stores update the model as necessary and notify the view about the changes. This cycle is constantly repeated until we close the application — or until it crashes.

As a result of problems like this, in 2015, Dan Abramov and Andrew Clark introduced a new tool to the community: Redux. It implements the Flux architecture while providing some additional advantages.


Redux is a library with a simple API, an application state container, and a unidirectional data flow. Flux has many data stores, while Redux has one global state.

Redux's features

React's data flow with and without Redux is hugely different. Imagine you've decided to sell your hand-knitted sweaters. On your own, you'll need to spend time looking for potential customers, and this might be difficult and inefficient. This is like how React works without Redux. But as soon as Redux is added, a large marketplace appears: the Redux store. This can be compared to Ebay or Walmart, where sellers add their goods and quit selling independently. Let's compare the two via this diagram:

Comparison of data flow in React with and without Redux

Here's how the data flow in Redux breaks down:

Data flow diagram in Redux

With the exception of reducers, you're already familiar with the elements above.

A reducer is a pure function that receives an action and then changes the state of the application, i.e. the model. Moreover, it doesn't mutate the application itself. Instead, it always returns a new state. With this data flow, components can be notified of changes in different parts of the store.

Even though Redux was built with a focus on React, it's often used with other libraries and frameworks, even Angular.


There are a few downsides to Redux. For instance, it comes with a lot of boilerplate code. For each command, you need to write an action (sometimes asynchronous), a reducer, and a selector. And the more code you write, the larger your application's bundle will be.

And while the Redux community positions it as a simple tool to use, that's a bit easier said than done. One must learn the subtleties and methods with Redux and how to design a store. Generally, it's hard to do all of these things right the first time you work with Redux.

Redux remains popular even in 2021, and many projects have already been written using a combination of React and Redux.

Next.js: from multipage apps to SPA and back

Previously, we talked about SPA frameworks, which can dynamically build pages without reloading. SPA applications usually include a lot of code that must be downloaded when the user first starts the application. This upfront code affects both the page's initial loading speed and, of course, the UX (User Experience). In addition, search engine bots are not particularly disposed to indexing pages built using JavaScript — Googlebot is one of the few to index SPAs in 2021.

How page load speed affects the user experience

Before newfangled SPAs appeared on the scene, the multipage approach was still the trend, and it didn't have this initial load time problem. However, we did have to reload a page in order to display some new state.

The ZEIT company decided to combine these two strategies of working with applications. In 2016, a SSR (server-side rendering) framework was released for React called Next.js. It allows developers to quickly write and deploy multipage applications, and once the user receives a page, to work with it as a fully-fledged SPA.


The main feature of Next.js is SSR. This framework is built based on React, so it makes full use of React's isomorphism, which allows for serving templates with pre-filled data. After that, a script is added to the page. However, this script doesn't block any of the DOM construction process and subsequently loads all the necessary JavaScript to dynamically work with the page. After the data is displayed, the user can interact with the page as a fully-fledged SPA application.

Code splitting is another important feature for speeding up the opening of individual pages. When receiving a separate page, we don't send the entire application as JS code, but only a small part of it. As a result, data transfer over the network is faster. The browser executes the code but it doesn't pull any unnecessary dependencies that won't be used on the desired page.

With Next.js, you can save a tremendous amount of time on application deployment. Just one command is enough to do the job. In addition, Next.js does all the dirty work which isn't always so fun for a developer.

It also comes with a couple more features:

  • TypeScript support
  • Hot Reloading, so that code changes are immediately reflected on the page
  • A built-in router


There are no ideal solutions and Next.js is no exception to that rule. It forces developers to accept its non-flexible structure, which is necessary to correctly build a functioning Next.js application.

If you're used to building projects with Webpack, where you add a bunch of loaders and plugins to optimize your builds, Next.js won't work for you. The build configuration is hidden and can't be edited.

On top of that, Next.js is a rather large project and it takes time to get into, although the documentation and community are pretty good.

In 2015–2016**,** there were many disputes about SPA vs. SSR. There's nothing new under the sun, so the developers gladly accepted the multipage approach proposed by Next.js. Nevertheless, SPA applications didn't lose popularity; on the contrary, they began to complement SSR. In 2021, both the SPA and SSR approaches are widely used. Each approach solves their own problems and are suitable for use with certain types of applications. Accordingly, the number of debates concerning this topic has noticeably decreased.


In 2014, React was just gaining momentum, while at the same time, AngularJS was losing its popularity and Angular (the next version) had yet to be released. Front-end developers already had access to a large selection of tools, but despite this, not all of the framework and library problems had been resolved. For example: there was a steep learning curve, slow development speeds, and the necessity to write a lot of code to make your application work. A new framework appeared to solve these problems: Vue.js. The creator of Vue.js was formerly a Google employee and had used AngularJS extensively in his work. Because of this, Vue.js is syntactically similar to that framework.

Vue.js has had a long history, with features being added in each new release. At the beginning, many predicted it would fail, but with the release of each new version, it only gained popularity. The latest version, 3.0, was released in 2020. A close-knit community of developers helped to develop it, and technology evangelicals helped to popularize it.

Quite rapidly, the framework entered the list of the top 3 frameworks and began to compete with Angular and React:

Statistics comparison of the top 3 frameworks on GitHub


Looking at its features, Vue has borrowed some best practices from various tools.

Example of using templates:

{{ message }}

{{ message }}

Users liked many things about Vue.js, starting with the lower learning curve and ending with the speed of application development.

Vue.js features include:

  • Two-way data binding (similar to Angular)
  • SSR; you can use something called Nuxt.js as an out-of-the-box solution
  • A component approach (components have their own life cycle, similar to React)
  • Its own state container: Vuex (an analogue of Redux for React)
  • A CLI (command line interface), a set of utilities for developing applications
  • JSX can be used to write components
  • A smaller bundle size compared to React and Angular

Vue.js didn't bring anything new. It builds on an already accumulated knowledge base from React/AngularJS/Angular, and other tools, removed the bloated and complex API, and put everything in a minimalistic form.

Vue.js is a simple framework, so you don't need to study its ecosystem for a long time, look for additional libraries, or write a special build configuration for it. And for many, Vue's documentation is an ideal example of what docs should be like. Indeed, there is no doubt that you can quickly write powerful applications in Vue.js.


During the development of this framework, developers complained about a small community and the lack of guides for writing large-scale applications. At a certain point, they did not know where and how to move on.

Thankfully, the Vue.js community has grown and more developers now have experience using this framework. As a result, these problems have almost been completely eradicated.

Another drawback is that, in terms of flexibility, the component approach in Vue.js falls short of competitors like React. However, this is not Vue.js's fault. Vue is a framework that provides tools for the full development cycle of an application, whereas React is a rendering library that mainly focuses on the component approach and views.

Overall, Vue.js has proved itself as a way to quickly develop a project with only modest resources. It's easy to learn, and you can always find specialists who are ready to support and develop your project. With Vue, even beginners can quickly get involved in front-end development.

IT career tips

Sign up for our newsletter to get future-proof advice from tech industry experts.

Stay in touch

TechStart podcast

Explore the realities of changing careers and getting into tech.

Listen now
No items found.
No items found.