Пробел в знаниях основ веб-разработки

Вчера я разговаривал с другом, который ищет разработчика на открытую вакансию. Он выразил некоторое разочарование, которое я тоже испытываю в последнее время:

Нет недостатка в учебных лагерях, курсах, полно ресурсов для изучения фронтенд-разработки. Но я собеседовал кучу ребят из этих учебных лагерей и думаю, что там серьёзно недооценивают важность CSS и основ JavaScript.

Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.

Восхищение новым

Наша индустрия восхищается новыми подходами к разработке. Чем ещё можно объяснить непрерывное стремление выбросить все наработки и «переделать с нуля» каждый раз, когда появляется новый, лучший и более сложный фреймворк? Каждый раз мы утверждаем, что это приведёт к более чистой, простой, идеально абстрагируемой архитектуре, и каждый раз всё заканчивается изобретением велосипедов, воссозданием багов и открытием заново всех пограничных ситуаций, которые снова приводят к такому же безобразному коду.

Это не означает, что никогда ничего не стоит переписывать или что новое никогда не бывает лучшим. Просто мы пали жертвами культа бесплатных вещичек и идеи идеальной абстракции. Каждая новая архитектура идеальна до тех пор, пока не сталкивается с жёсткими условиями реального мира. К сожалению, люди — довольно хаотичные существа, и весь наш софт создан для решения человеческих проблем. Поэтому каждая программа в реальном мире заканчивает дырявыми абстракциями, неуклюжими пограничными ситуациями и новыми компромиссами.

Эта гонка по бесконечной переделке и концентрации только на последнем и самом лучшем часто приводит к отказу от прежних решений тех проблем, которые в итоге появляются заново. Также она приводит к тому, что мы применяем новые инструменты в абсолютно неподходящих областях, просто потому что они новые.

Публикуя список рассылки по фронтенд-разработке, я каждый день вижу эту проблему во время текущего бума SPA. Читаю огромное множество статей, где авторы пишут о разных технологиях, и поверьте, почти все в мире JavaScript пишут об одном или другом из этих фреймворков как будто это абсолютно новая и уникальная инновация. Хотя это отличные инструменты, но каждый из них создан для решения конкретной проблемы. Они основаны на схожем базисе и делают разный выбор в зависимости от задач, для которых оптимизированы.

Можно взять React для примера, потому что он так сильно продвигается в последние несколько лет…

Не поймите меня неправильно, я люблю React. Это феноменально мощный инструмент. Он делает не только возможным, но и простым создание интерфейсов, которые казались нереальными, когда я начинал веб-разработку. Однако новички в индустрии приходят и видят всю эту шумиху вокруг React и предполагают, что это единственная истина, как следует писать на JavaScript. Сделать новое веб-приложение? Используй React! Нестандартный шаблон для блога? React! Переделать старый сайт? Переходи на React!

Это катастрофический подход к использованию технологии! И не слушайте меня, послушайте одного из самых видных разработчиков в сообществе React, Дэна Абрамова! Когда Кори Хаус попросил высказаться о недостатках React, Дэн дал наиболее подробное описание:

Its performance is worse than templates if many things update extremely fast at the same time. For example stock trading apps.

It trades memory pressure for expressiveness. React apps typically do more short-lived allocations under heavy load.

It’s mostly driven by the needs of Facebook. So if your apps are very different from what FB is building, may not satisfy your use case.

Это только часть, но открытость Дэна подтолкнула Кори к ответу:

Gotta say, I'm floored that the best input I've gotten on why "not* to use React is from you Dan. Really admire such candor and nuance.

Очевидно, у Дэна нет иллюзий о том, что React идеален для всего; он хорошо знаком с компромиссами, на которые пошли разработчики! Но такая большая часть сообщества спешит перейти на SPA-фреймворки для всего подряд и полностью игнорируют факт, что эти инструменты решают конкретные области задач. Да, это феноменальные инструменты и огромное удовольствие с ними работать… но часто они абсолютно не подходят для решения задач в других областях.

Превознося фреймворки над всем остальным, мы не замечаем решений, которые гораздо более подходят для этих областей.

Обесценивание CSS

В индустрии появилась тенденция унижать HTML и CSS как «не настоящую разработку» и нечто низшего уровня. Думаю, это идёт от того, что логику стали превозносить над графическим/пространственным мышлением… CSS и HTML воплощают иерархические, графические и пространственные отношения, в то время как JavaScript фокусируется в первую очередь на логике.

Но замечательная особенность логических языков/выражений состоит в том, что часто они могут включать другие типы отношений… что позволяет выражать пространственные отношения на логическом языке. Однако мы в индустрии часто неправильно интерпретируем такую большую широту возможного выражения как то, что выражение на этом языке строго превосходно.

На самом деле, если посмотреть на примеры из математики и физики, то часто наоборот! В этих областях, если вы начинаете с логической модели, то часто отчаянно пытаетесь найти пространственную или графическую модель, которую можно здесь применить.

Причина в том, что эти пространственные модели зачастую раскрывают гораздо более интуитивные или лаконичные способы представления проблем — и они приводят к важным озарениям и выводам, которые мы затем кропотливо пытаемся перевести обратно в логическую форму.

CSS представляет невероятно мощный фреймворк для выражения графических и пространственных отношений, иногда исключительно сложных!

Сохранение сложности

Это приводит меня к моему ключевому тезису о разработке ПО — сохранение сложности.

В любой решаемой проблеме есть некий присущий уровень сложности, и эта сложность должна быть где-то учтена.

Это всплывает во многих случаях, но в данном примере речь идёт о сложности выражения графических и пространственных отношений. Различные элементы на странице пространственно взаимосвязаны друг с другом невероятно сложным образом на разных уровнях, особенно с учётом манипуляций и перемещений этих элементов. Эта сложность должна быть где-то учтена, а в случае CSS браузер делает почти всю работу за вас!

Существует *невероятно много* кода JavaScript, написанного просто потому что разработчик недостаточно хорошо знает CSS.

Truth. I worked on a project that had 2000 lines of JS to do what position: absolute already does because they didn't understand it

Что делать?

Я не пытаюсь сказать, что нам не следует использовать или учить людей новейшим и самым лучшим инструментам. SPA-фреймворки вроде React, Angular, Vue и Ember позволяют создавать в вебе невероятно мощные интерфейсы, которые просто были невозможны всего несколько лет назад. Эти инструменты действительно изменили представление о том, что возможно сделать в онлайне.

Но я считаю, что следует искоренить элитизм SPA и вновь подчеркнуть важность фундаментальных знаний и выбора правильного инструментария.

Создатели этих фреймворков редко заявляют, что они хороши для всего подряд, но мы в индустрии настолько их возвысили, что новички полностью пропускают изучение базовых основ и предполагают, что только этот сложный инструментарий — единственный «правильный» способ решения их проблем.

Если все новые разработчики будут с презрением смотреть на CSS, то мы придём к тому, что 2000 строчек JavaScript будут пытаться заново реализовать position: absolute; .

Если все новые разработчики решат, что новый код HTML и JavaScript можно писать только через SPA, то мы придём к исключительно перепроектированным, глючным и тормозным блогам, маркетинговым сайтам и всему остальному, что сейчас хорошо реализовано на старых технологиях.

Нам следует серьёзно поговорить о том, какие навыки мы ожидаем от разработчиков в нашей отрасли и чему мы их обучаем. Вполне нормально начать обучение новичка в каком-нибудь учебном лагере, но есть серьёзный разрыв между современными выпускниками этих лагерей и тем, что требует индустрия. Может быть нереально ожидать соответствие этим требованиям после 8-12 недель обучения, но нужно хотя бы направить их по правильному пути.

Я не составлял учебник основ веб-разработки, но несколько вещей определённо включил бы туда. Они перечислены ниже со ссылками на бесплатные и платные ресурсы для более глубокого изучения, но что бы ВЫ включили в список? Напишите в комментариях.