‼️ 🌱 ⁉️ Frontend development in the company: what it is and how to make it effective ✌🏼 👏 🧚

We at KORUS Consulting CIS have been organizing the development of web services for our customers for more than ten years. We already have several dozen serious projects in the banking sector, some of which have received international recognition.

Over the past two years, the number of teams and projects in our company has increased several times, while the effectiveness of frontend development has also grown many times. We learned how to create applications in a few weeks instead of a few months.

We are constantly working on the development of the infrastructure of our front-end development, and today I will share some developments on the organization of the front-end department, which may be useful to those who organize the front-end in their company.

In this article, you will learn about our path to answering the following questions:

what do you need to do applications on now so that they are not out of date for several more years
What frameworks provide an increase in speed, quality and lower development costs;
how to cure a zoo of technology in a company;
Why do I need an application template;
Do I need to make my own library of interface components and how;
how much development efficiency can grow.

What is a modern frontend

The frontend part of a site or application is what you see in your browser, this part actively interacts with the server (backend) part, which is located on any server, constantly exchanging data with it.

From a technical point of view, the front-end of the application is a set of files, among which there are HTML, CSS and JavaScript files, pictures, etc. Work with CSS and HTML is related to typesetting, JavaScript - to programming. Both of these areas offer a large number of tools and technologies for work, are actively developing and require a lot of knowledge. This is especially true for JavaScript, which has written a huge number of frameworks and libraries for "more and more efficient" creation of web applications.

Somehow I was asked on what now do I need to make applications so that they do not become obsolete for several more years?

As a programmer, I can give a completely accurate and completely useless answer: HTML, CSS and JavaScript. What exactly to choose, jQuery, Angular or React - these are the details.

If you delve into these details, you can give another equally correct and useless answer: on anything. Yes this is true. The application can be written on anything, it will work, it can be changed and developed.

What is the difference?

To find the answer, let's look at what the business wants from the front end. I think that I will not surprise anyone if I say that the business wants to quickly and inexpensively get a high-quality result.

So, what do you need to do applications on now, so that development goes quickly, efficiently and does not ruin the customer?

Development speed

A programmer with extensive experience with React will be able to quickly write an application in React, having experience with Angular gives the speed of working with Angular, and so on. Everything is pretty obvious. The frameworks themselves save development time by providing solutions to common problems and tasks. In essence, these solutions can be very close to each other, and the difference between them can be in the syntax or programming paradigm.

The speed of development using a particular framework depends on the experience and qualifications of the programmers who write on it, the framework itself is of secondary importance.

Product quality

It’s the same here: it’s good and bad you can write on any framework. You can lay right and wrong architecture anywhere.

It all depends on the experience and knowledge of the developer.

Cost

All the main modern frameworks are free, so if you omit the details, the development cost is the cost of time that developers spent on studying the requirements, technologies, elaborating the architecture and writing code. Plus the cost of finding / training these developers.

Hence the conclusion: you need to rely not so much on technology as on developers and the organization of their work.

Almost any modern popular framework is good enough to create on it almost any application that modern business may require.

Therefore, it will be further about the effectiveness of the front end in terms of the organization of development.

How was it with us

By 2017, we had applications on almost everything that deserved attention in the JavaScript world: from jQuery to different versions of Angular and React on Typescript and Flow. Layouts and backend / fullstack developers worked on the client side of our applications. Each developer chose tools for their tasks, depending on their knowledge of front-end technologies.

Now I can only speculate, but it seems to me that the choice of frameworks and libraries by fullstack / backend developers was something like this:

“Let's see what they write on the Internet ...”

Well, you understand.

When choosing a framework / library, the developer is limited in time, most often he has no time to independently deploy new frameworks for him and make test applications. Therefore, he somehow makes a more or less well-reasoned choice and then follows in the chosen direction.

At different points in time, this choice may be different even for the same developer (see illustrations above). At the same time, he does not become less reasoned. What then to expect from different developers with different experiences?

Unbeknownst to 2017, we turned into a real front-end technology zoo.

Frontend as a separate unit

A large number of different technologies in the company is a source of risk. A developer with the necessary knowledge can be busy on another project, he can completely leave the company. Hiring specialists with extensive experience in various fields is also not an easy task.

High-quality documentation can mitigate the negative effects of such diversity, but it usually takes a long time to study and immerse yourself in unfamiliar technology.

In 2017, a front-end division appeared in our company, which was a response to the growing demands on the quality of the front-end part of our projects and their quantity, as well as an attempt to stabilize the diversity of technologies and increase development efficiency.

This was an important stage for the development of our company: what we are doing now, it would be impossible to do with the help of developers without specializing in front-end.

How to cure the zoo?

An uncontrolled variety of technologies makes it difficult to predict the speed and quality of development in general, while commercial development requires just that.

Therefore, our next step was to unify the company’s stack with the help of experts from the new division.

A unified stack is a strictly limited set of libraries and tools that developers can use to solve business problems. It also includes policies regarding different approaches to programming, for example, the use of a predominantly functional approach, or vice versa, rejection of it.

A single stack gives the developer the ability to quickly switch from one project to another, conduct a cross-team review, and effectively share experience and best practices with colleagues.

The main task here is not to decide what we are writing on React or Angular, but to make sure that developers use the same tools for creating applications and the same approaches to solving common problems.

For reference: our main tool is React, but we are also developing expertise in Angular.

This is where the fun begins. Forcing in the programming world works very poorly.

Therefore, instead of coercion, you need to make sure that the developers themselves want to follow certain development rules.

To do this, you need:

somehow fix, formalize development requirements;
Encourage developers to follow these guidelines.

Formalizing a stack is an activity that requires the ability to keep a balance. It is not necessary to draw up detailed regulations for everything in order to convey the basic ideas to the developers. In addition, creating and maintaining detailed specifications consumes a lot of resources.

We solved the motivation issue as follows: it is better than any documentation to give the developer a semi-finished application (template).

This allows developers to solve tasks faster and impress colleagues with their productivity and at the same time encourages them to adhere to the basic rules that are already protected in the code.

On the one hand, similar applications in the end give a significant increase in development speed due to the accumulation of experience, ready-made solutions, a deeper review and the ability to switch from project to project. On the other hand, each project has its own peculiarities, therefore it is also important here not to overdo it with standardization.

What you need to lay in the application template

When starting new projects, developers usually solve the following typical tasks:

definition of architecture, selection of technologies / tools;
application framework creation, assembly;
creation and configuration of common mechanisms: error handling, modal windows, notifications, routing, server requests;
definition of a set of interface elements;
search / creation, customization, stylization of interface components with the necessary functions;
form processing, validation;
layout;
implementation of functionality by order of a client (business logic);
code review;
records management.

Which of these tasks can your developers solve in a few minutes?

The application template that we developed closes the first three items from this list. In this template, we expressed not only our wishes for a single stack for development, but also the basic rules of the application architecture.
Compared to popular solutions that are in the public domain (for example, create-react-app), our template already contains:

ready-made folder structure;
configured router (routes);
Configured redux storage
server request module;
ready-made mechanisms for displaying various types of loaders, notifications and modal windows through redux;
error processing module (server and user) with the output of messages to the user;
template pages;

business logic template modules to which error, loader, and notification handlers are connected.

In essence, this is a production-ready application with one page that says hello world. Starting with morning coffee, by lunchtime, the developer can show the first page of a working project.

But then a large number of other interesting (and not so) tasks await the developer.

Component Library Selection

Everything that concerns layout, interface components (drop-down lists, calendars, etc.), forms and validation, we decided using our own library. It was the hardest part.

In 2017, the company's main library was the paid Kendo component library, which provided UI solutions for various technologies, starting with jQuery. For various reasons, it did not suit us, and we decided to consider alternative libraries, including the option of creating our own.

This is a very important point at which you need to make the right choice: find another library that is better for us, or create your own. The further distribution of development resources and the time that teams spend on creating and finalizing interface elements depend on this choice. In our choice, we proceeded from the following considerations.

;
;
.

( , , );
;
, . ;
, . .

;
;
.

;
, / ( ..);
( , , , ).

In fact, ready-made solutions are not so ready-made. Almost every library needs to be prepared to one degree or another. If you need to make one small project, then you may not encounter such a need, but if you are doing some kind of large project, or many small and different projects, then the cost of improvements may end up higher than the cost of creating your own library, which fully meets your needs.

It turns out that you have to choose between installing immediately ready-made functionality with a bunch of limitations and developing your own solutions with the need to wait and spend additional resources on development.

None of the options completely suited us, and we found another solution.

We decided to make our add-on for the finished library.

Let me remind you that at that time we already used the Kendo library in its pure form, an alternative of which we wanted to find. That is what we decided to take as the basis of our main library of components for applications on React. And our new library itself was a facade over Kendo. I will omit the technical details, I’ll only say that such a solution allowed us to immediately get all the Kendo functionality, and we did what we lacked, including the quick fix of bugs, in the layer between the client API of the library and Kendo.

This architecture allowed us to quickly expand the number of components due to other libraries and modules, simply by embedding them in our layer. For library clients (for application developers), this looked like a quick increase in the functionality of one library (I will discuss this in detail in a separate article).

Over time, we replaced all the components with our own implementations and released the second version of the library, where we took into account all previous experience, revised the API and made our own documentation.

We decided to put our achievements in the public domain, soon they can be downloaded and used in our projects, follow the announcements.

What did we get in the end?

Now we have more than 10 front-end developers in several teams working on the same stack and with one set of technologies. On one stack, we have already created about twenty projects.

Statistics show that work efficiency has more than tripled over two years. The projects that we used to spend 4-6 months on, now we do in 1-2 months (we are talking about the front-end part).

We began to reduce development time by changing the structure of the tasks of programmers. Let's look at how they have changed.

I already gave a list of tasks that developers solved two years ago:

definition of architecture, selection of technologies / tools;
application framework creation, assembly;
creation and configuration of common mechanisms: error handling, modal windows, notifications, routing, server requests;
definition of a set of interface elements;
search / creation, customization, stylization of interface components with the necessary functions;
form processing, validation;
layout;
implementation of functionality by order of a client (business logic);
code review;
records management.

Of these, in our company today, developers are engaged in only the last three:

implementation of functionality by order of a client (business logic);
code review;
maintaining project documentation.

The rest is already decided in the application template and component library.

This affected not only the speed of work, but also in general the mood of the developers. Anyway, the implementation of business logic is much more interesting than setting up drop-down lists. It is also much easier for the project manager to explain to the customer that a week of working time was spent on developing important business features, and not on the fact that it required the completion of a small interface element, although they can be quite equivalent in terms of labor costs.

We continue to work in the chosen direction and one of the main tasks for the near future is to increase the motivation of developers to deepen their competencies in the selected stack and to search for new effective solutions. Scaling such solutions across the entire company is now easy thanks to a common library and application template.

With wishes for efficiency and see you soon!

Frontend development in the company: what it is and how to make it effective