How to make something eternal, or how to build a ziggurat

Good day to all.

In this article, I decided to share my experience gained over many years of work in the front-end. Like all of you, I was young and dreamed of creating something immortal. Oh, how young I was, and how stupid I was. Nothing is eternal and everything dies sooner or later. However, it is possible to create something that will last much longer than usual and will even adapt to changes for a while. Therefore, today I propose to talk about design patterns for front-end applications, the choice of technologies and what not to do. In this article I will draw many analogies with the construction theme and the reason for this is the well-known story: “If programmers were building houses.”

What to build from?

Everything seems to be simple here, but not always obvious. As they say, let’s figure it out. Supernova technologies with breakthrough ideas are right by. You ask me why? So let’s fantasize about the fact that you took them into the project: after a year and a half, the project itself did not receive the support of the community, and its creator scored on it. You are left with an irrelevant stack, no way to find developers to create code and further support the project. No updates, read in two years you have an old brown substance on your hands.

Let’s look at the other side of the coin: by taking an ultra-reliable solution that is many years old, you doom the project to a quick update or to die. I knew a large company that used java 8. The motivation sounded like this: it is as reliable as a Swiss knife. For a moment, it’s 2021 and it is outdated not only morally, but also technically (at the time of writing, the current version is java 17).

Based on the above, we conclude that the choice should be something in between: not a novelty and not a proven old school. The best choice would be an instrument with 3-5 releases, depending on their frequency. This is a smoke test for the fact that the creator has not abandoned his creation, trying to develop and improve it. If the stack is good, then during the release of the releases it will acquire normal documentation, and maybe the community. As a result, you can be helped with questions.

As the front-end, we have a significant variety of standards and syntactic sugar at our disposal. I propose to take the current ES as a basis, adding on top of TS. The TS standard will help with typing that saves you from silly mistakes and reducing the time to search through the code, if the need arises. Now let’s digress for a minute and start catching Dart fans before they start their favorite song: “the future has already arrived.” I’ve heard these speeches since 2015, but the reality is still different, and will be different until one of the main development tools of the front moves to it.

We decided on the foundation, chose the brick, turn for the mortar. Oh, what kind of competition is there: the very case when less is more! The more dependencies, the greater the risks of degradation of the “tool”, as well as conflicts that will be generated. Although if it is impossible to do without this, I recommend using the same rules for selecting dependencies as for the Framework.

Wangyu: now ask about all sorts of wrappers, like ionic and the like. I must say right away that I consider this a solution: “herak-herak and into production”. They work slower than native applications, and in the output they give much more jams related to the peculiarity of the environment. At a long distance, this is almost a 100% shot in your own leg, so I am totally against it.

How to build?

History has recorded many cases when, using the best materials, engineering miscalculations let all the work go to the causal place. Front-end is no exception: it is not enough to take the best, you also need to know how to use it.

Always start by understanding the concept of the application:

· What will it do?

· Why is it created?

· Who will use it?

· In what conditions will it be used?

The more background information you collect, the better. I see a mute question in your eyes: “Why ?!”. This is one of the following: “I am a developer, I have a technical specification, according to which I work.” In fact, this is not entirely true, it is enough to compare two situations: you do document flow exclusively for the internal needs of the bank, and, you develop a boxed solution for the mass market. If you have any objections, I suggest discussing it in the comments.

When you figure out who you are doing this for, and for what purpose, I propose to start collecting information for a table of criteria with weighting coefficient values. I tell you what it includes: a list of the functionality that should be, technical requirements for the project and the coefficient (how important they are for the project). The actions are simple, and at the exit you get a rough version of the roadmap. Based on this sketch, you can already make the final drawing of your future Ziggurat.

Do you want to surprise? Even with a blueprint, you will not build your stronghold. You will, at a minimum, need technology and techniques. In our case, these are prettier, linter, and other rules for standardizing the work of the brigade. Remember, the composition of the team changes, but the documentation remains, and it is imperative to follow it in the same way as the safety rules. They are both written in blood.

With the documentation in hand, the first step is to study it. Yes, even if you wrote it yourself. Read from the point of view of the person who sees it for the first time. If you have ever seen the plan of any house, then you probably paid attention to the section with service information. It contains data where the dignity should be. node, wiring and so on. The same principle works in the front-end: you have to understand what is where and how it interacts.

Have everyone seen on the Internet a photo with a toilet in the kitchen? If you are not pursuing similar goals, you should logically split everything into separate modules at the very beginning. First, create an abstraction layer for working with the API, exposing cookies and other service business logic. Imagine that this is a utility room in a private house and take out all communications there: control of light, boiler room, water, and so on.

The sink is used to wash the dishes, no one will try to fall asleep in it (your cat does not count). So the components on the front should be as “stupid” as possible: sharpened for one thing. If this is a modal, then it should show that something was transferred to it, and that’s it. No checks and additional conditions. There are services in your arsenal, so use them.

In construction, the term quality control is used. For example, first, 5-10 cubes measuring 15 * 15 cm are cast from each mixer that came to pour the foundation. If a crack appears in a cube, there is always an opportunity to identify and check the concrete brought by a particular truck. In our profession, the same principle applies: we also need tests to maintain the quality of the code. As you know, tests can be not only for operability, but also for performance.

What shouldn’t you do?

The main thing is not to try to do something universal. This applies to both the application and the components.

The truth is quite common: the combination of a kitchen and a living room is permissible, but a kitchen and a restroom is already a bad form. Do you need to display two different text output templates in a component? This is permissible. If you put checks or something else into the component, then such actions start to smell bad. You will bring the situation to the point that the component will be overloaded and, as a result, it will no longer be possible to use it, since you will need a whole petition to make it work. It is better to create a separate component that will implement the given scenario than cross a hedgehog with a rhinoceros. If there is documentation, a large number of components is not critical, but a lack of understanding of the code and interaction with the component is yes.

Don’t disregard the rules and don’t make exceptions. Having said once: “And so it will do”, you will not have time to look back as you will bring the project to death by repeating such exceptions.

Before doing something, ask as many questions as possible: why; what will it give us; how should this be implemented? There is a funny practice “5W”, at one time it was invented by Toyota. The principle is simple: to find a problem, you must ask the question “Why?” Five times. If you get an answer to the question “Why?” Five times, then the cause of the problem and the method of solving it will become obvious. The solution (or “How?”) Is denoted as 1H. Thus, the five “Why?” equal to one “How?” (5W = 1H). By following this algorithm, you will understand the problem.

Outcomes

To summarize, I propose to stick to sound skepticism. If a business has come to you with the words: “We have f * ck!”, Do not rush to correct it. Perhaps the problem is not in the code, but in its perception. There is a funny anecdote on this topic:

“There are two railway workers, a young and a seasoned one. There is a command for them to move the cars to such and such a track. Young is undermined. Experienced him:

– Sit down!

Then they sit, again the command goes to them, to move the cars to another track. Young is undermined again. Experienced him:

– Sit down!

So they sat, there were several more teams and the last one to put the cars in the same place where they are.

The experienced one says to the young:

“You see what experience means!”

It is often the same in life. When creating an application, nothing is eternal, you can only make it more resistant to changes in external factors. I shared my experience on how to do this above, there are still questions: write in the comments. And remember: the dumbest question is the one that hasn’t been asked.

PS

My experience may be different from yours. I will not tire of repeating: first we think, then we do. Remember: the front should be lazy, it should only do what leads to a positive outcome. The purpose of this article is not to engage in your teaching, but only to share the experience that I have accumulated.