Yesterday I talked with a friend who is looking for a developer for an open job. He expressed some disappointment, which I also feel lately:

I have trouble finding a front-end developer, mostly by WP, Foundation, CSS, JS, for a low-level position. I can not understand what's wrong. None of the candidates have “basic knowledge” of any of the above. But they can create 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, look with empty eyes ... Or some little thing on pure JS, nothing.

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

Of course, there are restrictions 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 most recent and wonderful SPA frameworks, while at the same time depreciating CSS and “old” implementations.

Delight new

Our industry admires new approaches to development. What else can be explained by the continuous desire to throw out all the groundwork 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 abstracted architecture, and each time everything ends with the invention of bicycles, the re-creation of bugs and the rediscovery of all border situations that again lead to the same ugly code.
')
This does not mean that nothing is ever worth rewriting or that something new is never the best. We just fell victim to the cult of free things and the idea of ​​the perfect abstraction. Each new architecture is ideal as long as it does not face the tough conditions of the real world. Unfortunately, people are rather chaotic creatures, and all our software is created to solve human problems. Therefore, each program in the real world ends up with leaky abstractions, awkward borderline situations and new compromises.

This race in endless alteration and concentration only on the last and the best one often leads to the abandonment of previous solutions to the problems that eventually reappear. It also leads to the fact that we are applying new tools in absolutely inappropriate areas, simply because they are new.

Obsession with the latest and greatest SPA frameworks

When publishing a mailing list for front-end development, I see this problem every day during the current SPA boom. I read a great many 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 it were a completely new and unique innovation. Although these are excellent 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 for an example, because it has been advancing so much in the past 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 unreal when I started web development. However, newcomers to the industry come and see all the hype around React and suggest that this is the only truth about how to write in JavaScript. Make a new web app? Use React! Custom blog template? React! Redo the old site? Come on React!

This is a catastrophic approach to the use of 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 the shortcomings of React, Dan gave the most detailed description:

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

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

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

This is only a part, but Dan’s openness pushed Corey to the answer:

“I have to say, I'm amazed that the best list of reasons for not using React came from you, Dan. I really admire such a frank and detailed answer. ”

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

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

CSS depreciation

In the industry, there is a tendency to humiliate HTML and CSS as "not a real development" and something of a lower level. I think this comes from the fact that logic has been praised over graphic / spatial thinking ... CSS and HTML embody hierarchical, graphical and spatial relationships, while JavaScript focuses primarily on logic.

But the great thing about logical languages ​​/ expressions is that they can often 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 wide breadth of a 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, then 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 presenting 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!

Preservation of complexity

This leads me to my key thesis on software development - maintaining complexity .

In any problem to be solved there is a certain inherent level of complexity, 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 taking into account the manipulations and movements of these elements. This complexity should be taken into account somewhere, and in the case of CSS, the browser does almost all the work for you!

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

« . , 2000 JS , position: absolute, »

?

, . SPA- React, Angular, Vue Ember , . , .

, SPA .

, , , , — «» .

CSS, , 2000 JavaScript position: absolute;.

, HTML JavaScript SPA, , , , .

, . - , , . 8-12 , .

-, . , ? .

CSS

1. CSS (box model). , . Learn to code HTML & CSS. , , CSS.
2. CSS. , , -. CSS , . Smashing Magazine .
3. Flexbox. Flexbox , . Flexbox, , — CSS Tricks. Flexbox, Treehouse Udemy.
4. CSS. , CSS Grid — . — CSS CSS . , — , , , Treehouse .
5. CSS. - , , SMACSS. CSS — BEM, ITCSS ..

JavaScript

1. . JavaScript . . « » . JavaScript, . , — « JS: ».
2. this. this , JavaScript. this — № 1 JavaScript, ( , jQuery!). « JavaScript».
3. . , , . Free Code Camp: « JavaScript».
4. . JavaScript , , . , ( , ), Carbon Five : « JavaScript».