As a rule, one back-end development is enough for the full-fledged existence of the project. You can even get away from the layout if you use frameworks like Bootstrap. Moreover, most of the existing sites are just design, layout and backend. But there are situations when such a scheme does not work.
As an example, let’s take a look at the Hexlet practice runtime. The first thing that catches your eye when working with it is the absence of the classic web request-response scheme. The page never reloads, and the site itself at this moment looks like a full-fledged code editor. In fact, this is a full-fledged code editor.
By definition, it is impossible to implement such interactivity through server-side logic. Indeed, in this case, clicking on any link would lead to a page reload. Agree that doing the exercises would become unbearably painful. Fortunately, there is a way out of the situation.
Thanks to this, it became possible to create sites that are not inferior in capabilities to conventional applications. Microsoft Office is a thing of the past for many, and Google Docs has taken its place. Even the most sophisticated Photoshop tool is already online. Social networks are filled with a variety of applications built on the basis of modern front-end technologies. And, of course, games.
It is important to understand that frontend development is not an integral part of web development. The real need for a rich interface does not arise on every second site. In addition, the introduction of logic into the frontend significantly complicates and increases the cost of development. And sites whose entire frontend is built in a browser are called Single Page Application (SPA).
Modern front-end development is extremely difficult. From the fact that dozens of languages have been built on top of JS, eliminating some of its shortcomings, to a huge number of frameworks, server-side tooling and areas of work.
The increase in complexity has led to the allocation of a category of people who are called front-endders. Here we will dwell in more detail. People often say “we need a front-end”. There can be a lot behind this phrase. At some point, it became out of fashion to say “layout designer”, and he was also replaced by the word “front-end”. In total, it turns out that by front-end they mean the following:
- Layout designer.
- JS programmer and layout designer at the same time.
- JS programmer who knows the layout well, but no tasks for it.
All three are completely different people.
Layout designers usually know basic JS, but often they don’t know how to program. Sometimes they do a little jQuery and add simple interactive elements to the page. A good layout designer is not an HTML generator from layouts, but a specialist in presenting information and interfaces in the context of web pages. He is familiar with the principles of design in the broadest sense of the word, usability, user experience and issues of human interaction with digital interfaces.
On the other hand, front-end developers most often grow out of layout designers, but this situation changes over time. Many backend developers are also happy to write or switch to frontend (the opposite is also true).
It is a completely normal situation (and I am a supporter of this approach) when there is a separate layout designer and a programmer who, if necessary, writes the front or back, depending on the task. There is nothing difficult in this, especially considering that the modern front-end relies very heavily on the back-end on the one hand, and on the other, it offers sufficiently mature tools for solving typical tasks.
The features of different approaches to organizing development and specialization in teams are more related to process stories. If you want to get a little closer to this area, check out the differences between component teams and feature teams.
The main thing that I want to convey to everyone who plans to become a front-end programmer: such a person is first of all a programmer, and secondly, a front-end.
The relevance of this thesis only grows over time, since the stronger the specialization becomes, the more often the novice developers get the idea that the frontend is a separate world, although in reality everything is exactly the opposite.
Building the frontend of a modern application makes full use of the server-side js ecosystem: batch manager, processing (pre- and post-), server-side rendering (generating pages on the server to speed up access and improve SEO). In addition, databases are increasingly being used to manage client state. Even browsers already contain a built-in database.
But that’s not all. As practice shows, the root of most of the problems that any developers face is their lack of knowledge of operating systems. Moreover, programmers themselves do not always realize this (Blab’s paradox and the Dunning-Kruger effect). They ask again and again questions, the answers to which (and many others) are in the classic books on the device of the OS. Not to mention the fact that many of the tasks faced by developers are solved in one way or another at the OS level. Those with the appropriate knowledge are two steps ahead of their peers and can not only quickly understand the source of the problem, but also find better solutions based on the experience of generations.
If we talk about tooling, then we can say that recently React has revolutionized how you can build front-end applications.