ARTICLE CONSIDERED BY THE COMMUNITY OF HABR AS DISINFORMATION AND IS NOT RECOMMENDED TO READ!

In one of my social companies, the role of front-end developers is compared to bass guitarists in musical groups: they once dreamed of becoming solo guitarists with six-string electronics in their hands, or, drawing a parallel, real “hackers”, information technology gurus, but stumbling over pointers were forced to take a step back and stay the maker-ups. As far as this idea is correct, decide for yourself, but personally my familiar front-endners really once tried to learn almost an assembler and still sometimes regret that they did not cope with memory segmentation. In this article we will look at the opposite case - when an experienced system or application programmer suddenly decided to become a webmaster. The reasons may be different. Perhaps this is a student, like me, who has not yet received a diploma with which you can get a job in the specialty, and you need to make money now. Or the head ordered the system administrator to impose the company's website, because there is nobody else. Well, or perhaps you were lured by the idea of ​​stopping working for your uncle and becoming a self-sufficient freelancer, and on freelance exchanges, as you know, the most popular product is websites. Anyway, when completing tasks from HTML, CSS and JavaScript tutorials, you unwittingly partially follow your past experience in developing application and system software, while tutorials are designed for advanced beginners in the world of information technology. As a result, these newbies get their first sites faster and more easily than you. And all because with its charter in a strange monastery do not go. I will tell you about some of the errors identified by my own experience, which haunt novice front-end vendors who have a heavy portfolio with algorithms in C ++.

Waiting for easy profits

The first mistake is economic. If you come to the front-end with the goal of earning more than your boss allows, I’ll immediately disappoint you, you can stop reading. The demand for landings, layout and turnkey business cards on exchanges is really big, but the offer is also high. Instead of 8 hours of work in the office, during which you perform the work assigned to you, you will have to spend most of your day on an independent search for this work. Keep in mind that most employers are willing to cooperate only if you provide them with examples similar to the order from your portfolio, which means that the first month you are guaranteed to work for shishi, because this portfolio must first be collected, catching every chance to work for free . And even with him, dozens of freelancers like you will respond to the same project. Among them will be very experienced designers, who will complete half of the order immediately and provide as a demo version, and only beginners who, like you once, will offer to do everything for free. Most likely, the employer will choose one of these two legions, and the rest will have to sit at the monitor for a few hours to no avail, pressing F5. The situation can be compared with the market of lawyers in the CIS - once they were torn off with their hands, as soon as they reach the threshold of the alma mater, but now the supply far exceeds demand. At the same time, freelancing is different from working in law as a heightened danger: if you do not have your own personal entrepreneur, you can legally consider money earned by you in freelance to be illegal and then you will definitely regret not having stayed in that cozy office where you could have spent 8 hours doing things you love and getting a white salary for it. If I still have not dissuaded you, move on to the following errors.





')

Code scatter across files

We do this in high-level system languages ​​- each class - in a separate file. Good tutorials on layout immediately teach to save HTML and CSS in different files. It may seem that this technique applies to everything. Stop. Yes, it is better to keep CSS code separate from HTML, but, for example, keeping a reset of styles or templates separately from the main body of CSS site rules is a deadly mistake. The same applies to JavaScript. You don’t need to split the scripts into hundreds of files by class, just group them into two files: what is connected in the page header (head) and what is added to the end of the content (body). We are accustomed to linking programs in compiled languages ​​completely before execution. Everything is different here. Each linking in the site code is an additional request to the server. Surely you have noticed how slowly the social network Vkontakte has recently started working. Open the developer panel in any browser, update vk.com and see how much it makes GET and POST requests to the social network server. One such request takes a few microseconds of time, but because of their number, the process of full page load is stretched for seconds. Remember: the minimum number of requests - the main method of increasing the speed of the site. On the local server, this is imperceptible, but it becomes obvious when working with remote hosting. No one bothers you from storing dumps, style templates, classes, libraries in separate files, but before publishing, all this needs to be “glued together”, leaving HTML and CSS files from the sources, and a couple of JS files. There are webpack, browserify to build all the JS files into a single file, a “bundle,” and the SASS and LESS processors are designed for a similar CSS assembly. There are other optimization methods, for example, combining several images (most often lists of icons or avatars) in one file, but this is a topic for a separate article.

Brute force with classes and ids

Tutorials are advised to add attributes of classes and identifiers to all elements on the page so that they can be easily identified with CSS selectors. This is good advice, to a degree. When I first began to learn the layout, I just had everything covered with classes. This is mistake. I will give an example.







This is the code I wrote, being new to the web. Now consider all the errors. Firstly, it is not specified in the technical designation to decorate the navigation tabs with different colors and it is not planned to indicate, and therefore all tab identifiers simply load up the user's site processor in vain. Feel free to remove. Secondly, all elements of the “topnav” class are <li> elements and are nested in <ul>, moreover, the <ul> element can contain only <li> elements, so our “topnav” class is identical to the "#topnav li" selector . We erase the topnav classes. And thirdly, there is a single navigation bar in the TOR, which means that there should be only one <nav> element on the whole page. Yes, TK can change, but adding an identifier is much easier than reading someone else's code in searching for the right word. In addition, the elements of the class <nav> we also get identical to the selector “nav ul”. We remove everything.



Here is the final result:







No class or identifier! But at the same time everything you need is allocated selectors.



The following two codes apply the same rules:







But the second is less burdening you and the processor, and the one who will read your code, because you don’t have to search the page for the desired identifier or class and think what its name means.

All right The above strikeout information is incorrect and also represents an example of an error. Contrary to the self-help books, at a certain stage of comprehension of the layout, it seems that extra classes and identifiers do not need anything, and that the second example loads the site user’s processor less because the browser does not need to completely go through the DOM tree looking for all elements of the .topnav class. However, such a simplification, on the contrary, will increase the search time and is not optimizing. This is because the style selectors are expanded from right to left: in the second code, all the <a> elements will be found on the whole page first, and then their parents will be checked for compliance with the <li> element, then the parents of the <li> elements will be checked, and so on. As a result, the disclosure of the desired selector will take the passage of the entire tree, plus three checks of the sample list instead of one pass in search of the elements of the ".topnav" class. In addition, the rejection of classes and identifiers goes against the principle of “HTML for designation, CSS for presentation”, since CSS selectors should not depend on the type of elements that they choose. That is, when replacing <ul> and <li> with <div> and <span> they should remain unchanged. Do not neglect classes and identifiers. The best solution, perhaps, in our example would be this:



By the way, about the names. Regardless of how deeply you have already plunged into the layout, if you don’t know the microformats yet, google now and study so as not to invent sophisticated class names and make search engines easier to work with.

Avoiding Anonymous Functions

We are used to the fact that when writing programs, our names of functions, variables, and objects have only three limitations: they must begin with a letter, contain only letters and numbers, and should not coincide with the keywords of a programming language. The names of third-party libraries are usually enclosed in convenient namespaces, so we usually do not use lambda functions in our application programs. On the web with names, the case is more complicated. Here JavaScript has only one global space — the space of the loaded page. Nothing will happen if you write all the scripts for the site personally. But for large and serious projects, third-party solutions will be needed. And here they can literally “make a secret” of this unique name space, seriously limiting you in choosing new identifiers. The way out is anonymous lambda functions, which, although they are executed a little longer, and require a little more resources, but they have their own personal space inside, independent of the external global one.

Using complex libraries to solve simple problems

jQuery, React, Vue, Angular, Backbone ... The list goes on. The common feature of all these JavaScript libraries is that they are used to work with complex projects, when the size of the code really matters. For the same, to simply select an element on the page by its identifier, it is better to use the usual getElementById (). It not only works faster, but also works in principle on more old browsers. If your script refers for all the time to two or three elements on the page, think, maybe it makes sense not to load the browser and the user's network with a heavy library.

Outdated study materials

This is for C ++ developers the work of Straustrup will remain relevant even after many decades. Web tools, on the other hand, are developing at an incredible rate. HTML, CSS, JavaScript, layouts, frameworks, libraries — as you read this article, all of them have new versions, often overwriting old tutorials. Conclusion - when choosing educational materials for the front-end provider, it is important to look at the release dates and versions of the tools used (HTML at least 5.1, CSS at least 3.0, ECMAScript at least 6). Perhaps HTML coding has not gone far ahead since the release of HTML 5, but it’s too late to watch the 2016 video courses on JS in 2019. Choose 2018. It is even better if you speak English at least at the level of translation of a technical text with a dictionary. Then I will immediately recommend the online book Eloquent JavaScript .

Lack of support for older browsers

Paradoxically, if you are lucky to find the newest selection of textbooks on the frontend, you can fall into another trap - the lack of support for older browsers. Although the <video> and <audio> elements are actually supported by all, even very ancient versions of browsers, many CSS effects cause problems, and this is not only a matter of Internet Explorer. One way out of the trap is to carefully read the TOR in the place where the supported browsers are indicated, and verify the HTML tags used, the CSS rules, and the JS methods by their versions.



This article is a kind of notebook for the rake and will be updated with the experience of the author.