Yesterday I spoke with a friend who is looking for a developer for an open position. He expressed some disappointment, which I also feel recently:

I have problems finding a front-end developer, mainly by WP, Foundation, CSS, JS, at a low level position. I can’t understand what’s the matter. None of the candidates have “basic knowledge” of any of the above. But they can make sites on React or other JS frameworks, or based on WP templates. But if I say that you need to make simple changes in CSS, they look empty-handed ... Or some little thing in pure JS, nothing.

There is no shortage of training camps, courses, full of resources for studying front-end development. But I interviewed a bunch of guys from these training camps and I think that they seriously underestimate the importance of CSS and the basics of JavaScript.

Of course, there are limits on how much you can learn in 12 weeks of study. But a huge part of the problem is that our industry admires the new, obsessed with the latest and greatest SPA frameworks, while at the same time depreciating CSS and the “old” implementations.

Admiration for the new

Our industry admires new development approaches. What else can explain the continuous desire to discard all the achievements and “remake from scratch” every time a new, better and more complex framework appears? Each time we claim that this will lead to a cleaner, simpler, ideally abstractable architecture, and each time it all ends with the invention of bicycles, the reconstruction of bugs and the rediscovery of all border situations that again lead to the same ugly code.

This does not mean that it is never worth rewriting anything, or that the new is never the best. We just fell victim to the cult of free gizmos and the idea of ​​perfect abstraction. Each new architecture is perfect until it encounters the harsh conditions of the real world. Unfortunately, people are rather chaotic creatures, and all of our software is created to solve human problems. Therefore, each program in the real world ends with holey abstractions, clumsy border situations and new compromises.

This race of endless remaking and focusing only on the latest and the best often leads to the rejection of the old solutions to those problems that eventually reappear. It also leads to the fact that we use new tools in completely inappropriate areas, simply because they are new.

Obsession with the latest and greatest SPA frameworks

By publishing the frontend development mailing list, I see this problem every day during the current SPA boom. I read a huge number of articles where authors write about different technologies, and believe me, almost everyone in the JavaScript world writes about one or the other of these frameworks as if this is a completely new and unique innovation. Although these are great tools, each one is designed to solve a specific problem. They are based on a similar basis and make different choices depending on the tasks for which they are optimized.

You can take React as an example, because it has progressed so much in the last few years ...

Don't get me wrong, I love React. This is a phenomenally powerful tool. It makes it not only possible, but also easy to create interfaces that seemed unrealistic when I started web development. However, newcomers to the industry come and see all the hype surrounding React and suggest that this is the only truth how to write JavaScript. Make a new web application? Use React! Custom blog template? React! Redo the old site? Go to React!

This is a catastrophic approach to using technology! And don’t listen to me, listen to one of the most prominent developers in the React community, Dan Abramov! When Corey House asked to speak about React's flaws, Dan gave the most detailed description:

“Its performance is worse than templates if many things are extremely quickly updated at the same time. For example, applications for exchange trading »

“For the expressive power of language, memory is sacrificed. React applications typically do more short-term memory allocations under heavy load. ”

“It is mainly designed based on the needs of Facebook. So if your applications are very different from what Facebook does, then React may not be suitable for your needs. ”

This is only part, but Dan's openness prompted Corey to answer:

“I must say, I am amazed that the best list of reasons not to use React came from you, Dan. I really admire such a frank and detailed answer "

Obviously, Dan has no illusions that React is ideal for everything; he is well acquainted with the compromises that the developers have made! But such a large part of the community is in a hurry to switch to SPA-frameworks for everything in a row and completely ignore the fact that these tools solve specific areas of problems. Yes, these are phenomenal tools and it is a great pleasure to work with them ... but often they are absolutely not suitable for solving problems in other areas.

Exalting the frameworks above everything else, we do not notice solutions that are much more suitable for these areas.

CSS Depreciation

There is a tendency in the industry to humiliate HTML and CSS as “not real development” and something of a lower level. I think this comes from the fact that logic began to be extolled over graphic / spatial thinking ... CSS and HTML embody hierarchical, graphic and spatial relationships, while JavaScript focuses primarily on logic.

But the great thing about logical languages ​​/ expressions is that often they can include other types of relationships ... which allows you to express spatial relationships in a logical language. However, we in the industry often misinterpret such a great breadth of possible expression as the fact that the expression in this language is strictly excellent.

This is not true!

In fact, if you look at examples from mathematics and physics, it is often the opposite! In these areas, if you start with a logical model, you often desperately try to find a spatial or graphical model that you can apply here.

The reason is that these spatial models often reveal much more intuitive or concise ways of representing problems - and they lead to important insights and conclusions, which we then painstakingly try to translate back into a logical form.

CSS provides an incredibly powerful framework for expressing graphic and spatial relationships, sometimes extremely complex!

Saving Difficulty

This leads me to my key point about software development - maintaining complexity .

There is a certain level of complexity in any problem to be solved, and this complexity must be taken into account somewhere.

This pops up in many cases, but in this example we are talking about the complexity of expressing graphic and spatial relationships. The various elements on the page are spatially interconnected with each other in an incredibly complex way at different levels, especially considering the manipulations and movements of these elements. This complexity must be taken into account somewhere, and in the case of CSS, the browser does almost all the work for you!

There is * an incredible amount * of JavaScript code written simply because the developer does not know CSS well enough.

"It's true. I was working on a project where 2,000 lines of JS did what was already implemented in position: absolute, simply because the developers didn’t understand it. ”

What to do?

I am not trying to say that we should not use or teach people the latest and greatest tools. SPA frameworks like React, Angular, Vue, and Ember allow you to create incredibly powerful interfaces on the web that were just impossible just a few years ago. These tools really changed the idea of ​​what can be done online.

But I believe that the elitism of SPA should be eradicated and the importance of fundamental knowledge and the selection of the right tools should be emphasized again.

The creators of these frameworks rarely claim that they are good for everything, but we in the industry have excelled them so much that beginners completely skip the basics and assume that only this complex toolkit is the only “right” way to solve their problems.

If all new developers contemptuously look at CSS, then we will come to the conclusion that 2000 lines of JavaScript will try to re-implement position: absolute;.

If all new developers decide that the new HTML and JavaScript code can be written only through SPA, then we will come to exclusively redesigned, buggy and nerdy blogs, marketing sites and everything else that is now well implemented on old technologies.

We should seriously talk about what skills we expect from developers in our industry and what we teach them. It is quite normal to start training a beginner in a training camp, but there is a serious gap between the modern graduates of these camps and what the industry requires. It may not be realistic to expect compliance with these requirements after 8-12 weeks of training, but at least you need to direct them along the right path.

To the basics curriculum

I did not compile a web development basics tutorial, but a few things would definitely include there. They are listed below with links to free and paid resources for more in-depth study, but what would YOU include in the list? Write in the comments.

CSS

1. The basic block model in CSS (box model). This is the main foundation you MUST understand. As a free resource, you can recommend the excellent article by Shaw Howe from his free Learn to code HTML & CSS course . On the paid side, especially if you’re more comfortable with audiovisual content, my friend James Stone has a nice CSS block-based video course .
2. CSS specificity . This is another important foundation that you need to understand if you are going to do web development. Without a solid understanding of specificity, you will continuously try to get your CSS code to work as it should. Smashing Magazine has a great overview to get you started .
3. Flexbox . Flexbox specifications revolutionized layout methods, and you certainly need to take advantage of this technology. The best Flexbox resource I've seen is this CSS Tricks reference . If you're looking for a video tutorial on Flexbox, check out this one on Treehouse or this one on Udemy .
4. Grid in CSS . Although this is a new standard and not supported by older browsers, CSS Grid is an exceptionally powerful technology and is definitely a step forward in creating layouts. Among the great free resources - guidance on CSS tricks and Grid CSS on examples from Rachel Andrew. On the paid side, Rachel Andrew is a guru, and you should definitely watch her course , and if you are looking for a less expensive option, then Treehouse offers a good introductory course .
5. Basic CSS architecture . This is a really deep topic, and I don’t want to go too deep into it, but first I would read the free SMACSS book . It will give an excellent understanding of some fundamental principles of CSS organization and concepts - from there you can move on to other approaches and conventions like BEM , ITCSS , etc.

Javascript

1. Types and casts . JavaScript has weird types. It all comes down to this. They provide a kind of "weak typing" and a rather bizarre behavior. If you want to delve deeper into JavaScript, you need to understand them. The best resource I've met is the first four chapters of “ You Don't Know JS: Types and Grammar ”.
2. Contexts andthis . Understanding is thisfundamentally important for a deeper understanding of what is happening in JavaScript code. Misunderstanding thisis the number one confusion among novice JavaScript programmers, in part because many libraries use and abuse it (I'm looking at you, jQuery!). To create the foundation in understanding, I recommend Zell’s excellent article “ It's in JavaScript .”
3. Short circuits . Closures will open you up to all types of concepts and show why almost the same code works so differently, and you will begin to gradually introduce functions as first-class objects. Here is a well-written introduction from Free Code Camp: “ Learning JavaScript Lockups ”.
4. Events and the event loop . The event loop model distinguishes JavaScript from many other programming paradigms, and without a good understanding, you may have serious troubles when you first start working with non-trivial interactions between asynchronous events. I did not find a resource that I would absolutely like on this topic (let me know if you know one), but this Carbon Five article is not bad: “ Explanation of the JavaScript event loop ”.