- PVSM.RU - https://www.pvsm.ru -
Вчера я разговаривал с другом, который ищет разработчика на открытую вакансию. Он выразил некоторое разочарование, которое я тоже испытываю в последнее время:
У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.
Нет недостатка в учебных лагерях, курсах, полно ресурсов для изучения фронтенд-разработки. Но я собеседовал кучу ребят из этих учебных лагерей и думаю, что там серьёзно недооценивают важность CSS и основ JavaScript.
Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.
Наша индустрия восхищается новыми подходами к разработке. Чем ещё можно объяснить непрерывное стремление выбросить все наработки и «переделать с нуля» каждый раз, когда появляется новый, лучший и более сложный фреймворк? Каждый раз мы утверждаем, что это приведёт к более чистой, простой, идеально абстрагируемой архитектуре, и каждый раз всё заканчивается изобретением велосипедов, воссозданием багов и открытием заново всех пограничных ситуаций, которые снова приводят к такому же безобразному коду.
Это не означает, что никогда ничего не стоит переписывать или что новое никогда не бывает лучшим. Просто мы пали жертвами культа бесплатных вещичек и идеи идеальной абстракции. Каждая новая архитектура идеальна до тех пор, пока не сталкивается с жёсткими условиями реального мира. К сожалению, люди — довольно хаотичные существа, и весь наш софт создан для решения человеческих проблем. Поэтому каждая программа в реальном мире заканчивает дырявыми абстракциями, неуклюжими пограничными ситуациями и новыми компромиссами.
Эта гонка по бесконечной переделке и концентрации только на последнем и самом лучшем часто приводит к отказу от прежних решений тех проблем, которые в итоге появляются заново. Также она приводит к тому, что мы применяем новые инструменты в абсолютно неподходящих областях, просто потому что они новые.
Публикуя список рассылки по фронтенд-разработке, я каждый день вижу эту проблему во время текущего бума SPA. Читаю огромное множество статей, где авторы пишут о разных технологиях, и поверьте, почти все в мире JavaScript пишут об одном или другом из этих фреймворков как будто это абсолютно новая и уникальная инновация. Хотя это отличные инструменты, но каждый из них создан для решения конкретной проблемы. Они основаны на схожем базисе и делают разный выбор в зависимости от задач, для которых оптимизированы.
Можно взять React для примера, потому что он так сильно продвигается в последние несколько лет…
Не поймите меня неправильно, я люблю React. Это феноменально мощный инструмент. Он делает не только возможным, но и простым создание интерфейсов, которые казались нереальными, когда я начинал веб-разработку. Однако новички в индустрии приходят и видят всю эту шумиху вокруг React и предполагают, что это единственная истина, как следует писать на JavaScript. Сделать новое веб-приложение? Используй React! Нестандартный шаблон для блога? React! Переделать старый сайт? Переходи на React!
Это катастрофический подход к использованию технологии! И не слушайте меня, послушайте одного из самых видных разработчиков в сообществе React, Дэна Абрамова! Когда Кори Хаус попросил высказаться о недостатках React, Дэн дал наиболее подробное описание:
«Его производительность хуже шаблонов, если много вещей исключительно быстро обновляются одновременно. Например, приложения для биржевой торговли»
«Ради выразительных возможностей языка приносится в жертву память. Приложения React обычно делают больше краткосрочных размещений в памяти под большой нагрузкой»
«Он в основном спроектирован исходя из потребностей Facebook. Так что если ваши приложения сильно отличаются от того, что делает Facebook, то React может не подойти для ваших нужд»
Это только часть, но открытость Дэна подтолкнула Кори к ответу:
«Должен сказать, я поражён, что лучший список причин не использовать React пришёл именно от вас, Дэн. Действительно восхищаюсь столь откровенным и подробным ответом»
Очевидно, у Дэна нет иллюзий о том, что React идеален для всего; он хорошо знаком с компромиссами, на которые пошли разработчики! Но такая большая часть сообщества спешит перейти на SPA-фреймворки для всего подряд и полностью игнорируют факт, что эти инструменты решают конкретные области задач. Да, это феноменальные инструменты и огромное удовольствие с ними работать… но часто они абсолютно не подходят для решения задач в других областях.
Превознося фреймворки над всем остальным, мы не замечаем решений, которые гораздо более подходят для этих областей.
В индустрии появилась тенденция унижать HTML и CSS как «не настоящую разработку» и нечто низшего уровня. Думаю, это идёт от того, что логику стали превозносить над графическим/пространственным мышлением… CSS и HTML воплощают иерархические, графические и пространственные отношения, в то время как JavaScript фокусируется в первую очередь на логике.
Но замечательная особенность логических языков/выражений состоит в том, что часто они могут включать другие типы отношений… что позволяет выражать пространственные отношения на логическом языке. Однако мы в индустрии часто неправильно интерпретируем такую большую широту возможного выражения как то, что выражение на этом языке строго превосходно.
Это НЕ так!
На самом деле, если посмотреть на примеры из математики и физики, то часто наоборот! В этих областях, если вы начинаете с логической модели, то часто отчаянно пытаетесь найти пространственную или графическую модель, которую можно здесь применить.
Причина в том, что эти пространственные модели зачастую раскрывают гораздо более интуитивные или лаконичные способы представления проблем — и они приводят к важным озарениям и выводам, которые мы затем кропотливо пытаемся перевести обратно в логическую форму.
CSS представляет невероятно мощный фреймворк для выражения графических и пространственных отношений, иногда исключительно сложных!
Это приводит меня к моему ключевому тезису о разработке ПО — сохранение сложности.
В любой решаемой проблеме есть некий присущий уровень сложности, и эта сложность должна быть где-то учтена.
Это всплывает во многих случаях, но в данном примере речь идёт о сложности выражения графических и пространственных отношений. Различные элементы на странице пространственно взаимосвязаны друг с другом невероятно сложным образом на разных уровнях, особенно с учётом манипуляций и перемещений этих элементов. Эта сложность должна быть где-то учтена, а в случае CSS браузер делает почти всю работу за вас!
Существует *невероятно много* кода JavaScript, написанного просто потому что разработчик недостаточно хорошо знает CSS.
«Это правда. Я работала над проектом, где 2000 строк JS делали то, что уже реализовано в
position: absolute
, просто потому что разработчики не понимали этого»
Я не пытаюсь сказать, что нам не следует использовать или учить людей новейшим и самым лучшим инструментам. SPA-фреймворки вроде React, Angular, Vue и Ember позволяют создавать в вебе невероятно мощные интерфейсы, которые просто были невозможны всего несколько лет назад. Эти инструменты действительно изменили представление о том, что возможно сделать в онлайне.
Но я считаю, что следует искоренить элитизм SPA и вновь подчеркнуть важность фундаментальных знаний и выбора правильного инструментария.
Создатели этих фреймворков редко заявляют, что они хороши для всего подряд, но мы в индустрии настолько их возвысили, что новички полностью пропускают изучение базовых основ и предполагают, что только этот сложный инструментарий — единственный «правильный» способ решения их проблем.
Если все новые разработчики будут с презрением смотреть на CSS, то мы придём к тому, что 2000 строчек JavaScript будут пытаться заново реализовать position: absolute;
.
Если все новые разработчики решат, что новый код HTML и JavaScript можно писать только через SPA, то мы придём к исключительно перепроектированным, глючным и тормозным блогам, маркетинговым сайтам и всему остальному, что сейчас хорошо реализовано на старых технологиях.
Нам следует серьёзно поговорить о том, какие навыки мы ожидаем от разработчиков в нашей отрасли и чему мы их обучаем. Вполне нормально начать обучение новичка в каком-нибудь учебном лагере, но есть серьёзный разрыв между современными выпускниками этих лагерей и тем, что требует индустрия. Может быть нереально ожидать соответствие этим требованиям после 8-12 недель обучения, но нужно хотя бы направить их по правильному пути.
Я не составлял учебник основ веб-разработки, но несколько вещей определённо включил бы туда. Они перечислены ниже со ссылками на бесплатные и платные ресурсы для более глубокого изучения, но что бы ВЫ включили в список? Напишите в комментариях.
this
. Понять this
фундаментально важно для более глубокого понимания, что происходит в коде JavaScript. Непонимание this
— причина путаницы № 1 у начинающих программистов JavaScript, частично потому что многие библиотеки используют и злоупотребляют ею (я смотрю на тебя, jQuery!). Для создания фундамента в понимании рекомендую великолепную статью Зелла «Это в JavaScript [21]».Автор: m1rko
Источник [24]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/267406
Ссылки в тексте:
[1] September 16, 2017: https://twitter.com/dan_abramov/status/909181242167431170?ref_src=twsrc%5Etfw
[2] September 16, 2017: https://twitter.com/dan_abramov/status/909181948844748800?ref_src=twsrc%5Etfw
[3] September 16, 2017: https://twitter.com/dan_abramov/status/909185225288241152?ref_src=twsrc%5Etfw
[4] September 17, 2017: https://twitter.com/housecor/status/909240876651745280?ref_src=twsrc%5Etfw
[5] September 16, 2017: https://twitter.com/sarah_edo/status/908995987598798849?ref_src=twsrc%5Etfw
[6] отличную статью: https://learn.shayhowe.com/html-css/opening-the-box-model/
[7] Learn to code HTML & CSS: https://learn.shayhowe.com/html-css/
[8] видеокурс по модели окна в CSS: https://www.jamesstone.com/products/box-model/
[9] отличный обзор для начала: https://www.smashingmagazine.com/2007/07/css-specificity-things-you-should-know/
[10] этот справочник от CSS Tricks: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
[11] этот на Treehouse: https://treehouse.7eer.net/c/469710/228915/3944?u=https%3A%2F%2Fteamtreehouse.com%2Flibrary%2Fcss-flexbox-layout
[12] этот на Udemy: https://www.udemy.com/flexbox-tutorial/
[13] руководство по трюкам CSS: https://css-tricks.com/snippets/css/complete-guide-grid/
[14] Сетка CSS на примерах: https://gridbyexample.com/
[15] посмотреть её курс: https://thecssworkshop.com/
[16] Treehouse предлагает хороший вводный курс: https://treehouse.7eer.net/c/469710/228915/3944?u=https%3A%2F%2Fteamtreehouse.com%2Flibrary%2Fcss-grid-layout
[17] книгу SMACSS: https://smacss.com/book/
[18] BEM: http://getbem.com/introduction/
[19] ITCSS: https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/
[20] Вы не знаете JS: типы и грамматика: https://github.com/getify/You-Dont-Know-JS/tree/master/types%20%26%20grammar
[21] Это в JavaScript: https://zellwk.com/blog/this/
[22] Изучим замыкания в JavaScript: https://medium.freecodecamp.org/lets-learn-javascript-closures-66feb44f6a44
[23] Объяснение цикла событий JavaScript: https://blog.carbonfive.com/2013/10/27/the-javascript-event-loop-explained/
[24] Источник: https://habrahabr.ru/post/341626/
Нажмите здесь для печати.