Второе обещанное размышление на тему технологий.
Jeffrey Zeldman делится в "A List Apart" своими соображениями о сложившимся в индустрии "культе сложного". Хотя основной акцент заметки лежит в плоскости клиентских веб-технологий (CSS, HTML, etc.), мне кажется, проблема касается всей IT-отрасли.
С начала 200х веб-технологии прошли длинный путь. Возможно, вы еще помните выражение "табличная верстка", когда, чтобы сделать сколь-нибудь сложный макет, разработчики вставляли table при каждом удобном случае, а структуру страницы сложно было назвать семантичной.
Потом пошла волна "отказа" от таблиц в сторону использования возможностей CSS. Казалось, что верстка станет лучше, но то ли в силу существовавших ограничений, то ли в силу недопонимания логики, заложенной в систему тегов HTML и CSS, сознательно или бессознательно, толпы разработчиков и, особенно, разработчиков фреймворков, начали делать одну и ту же "странную" вещь. Они начали везде использовать div и span элементы. Вместо параграфов (p) мы видели блочные элементы, вместо заголовков (h1-h5), div с классом "h2", вместо внутренних (inline) элементов, блоки, которым насильно через css приписали inline-свойство и т.п.
Если вы откроете какой-нибудь популярный большой сайт и посмотрите на его код, вы можете ужаснуться глубине вложенности некоторых div-цепочек.
И это все происходило и происходит несмотря на общий хайп вокруг HTML5, веб-стандартов, важности семантической разметки и т.п. Порой даже может показаться, что разметка классами (css) победила разметку смыслами (семантикой html).
Если вы зашли в веб-разработку или веб-дизайн в последние несколько лет, вы почти наверняка в своей работе опираетесь на какие-то готовые фреймворки, большинство из которых построены на базе манипуляций множеством div и span элементов. И если задуматься, почему так происходит, то ключевой ответ -- это JavaScript, все больше и больше JavaScript.
И, в принципе, если вы понимаете, что вы делаете (!), в этом нет ничего плохого. Вы достаточно быстро можете получить хороший результат и выпилить те элементы, которые делают ваш продукт хуже с точки зрения пользователя (например, генерируют излишнее количество блоков, утяжеляя страницы или рендеринг).
Сегодня мы получили ситуацию, когда большинство разработчиков не представляют себе запуск нового проекта без добавления нескольких пакетов из NPM или Composer, не будучи при этом уверенными, чем занимается вносимый код. Фактически, мы оказались в условиях, когда мы научили целое поколение разработчиков учить создавать и запускать проекты с недоверенным кодом (!).
Причем как факт деятельности, а не как ее осознание. Вы скорее найдете вакансию, в которой от вас требуют знания конкретных новых, модных фреймворков, нежели спросят о способности написать с нуля чистый и безопасный код.
Когда эта резиновая конструкция из пятнадцати слоев кода, который мы не понимаем и который писали не мы, начинает натягиваться и лопаться по швам, мы обвиняем HTML и CSS в ошибках разработчиков. Это приводит к созданию новых культов сложности -- более специализированных CSS, как правило, натянутых на JavaScript.
И снова, проблема не в JavaScript, а в том, что за счет усложнения технологии мы получаем сиюминутное (массовое) решение проблемы вместо намеренного воздействия на точку ее возникновения. Массовый workaround становится нормой разработчиков, но никто не замечает, что она вся стянута кусками изоленты.
Часто оказывается, что для проблемы даже есть готовое решение (вроде CSS Grid для управления позиционирвоанием блоками), но... ведь уже есть неплохой фреймворк? Да, придется инвестировать с обучение (изучение нового), но часто оказывается, что это полезная инвестиция, открывающая в том числе те возможности, которые в фреймворк не были заложены в принципе.
Jeffrey Zeldman делится в "A List Apart" своими соображениями о сложившимся в индустрии "культе сложного". Хотя основной акцент заметки лежит в плоскости клиентских веб-технологий (CSS, HTML, etc.), мне кажется, проблема касается всей IT-отрасли.
С начала 200х веб-технологии прошли длинный путь. Возможно, вы еще помните выражение "табличная верстка", когда, чтобы сделать сколь-нибудь сложный макет, разработчики вставляли table при каждом удобном случае, а структуру страницы сложно было назвать семантичной.
Потом пошла волна "отказа" от таблиц в сторону использования возможностей CSS. Казалось, что верстка станет лучше, но то ли в силу существовавших ограничений, то ли в силу недопонимания логики, заложенной в систему тегов HTML и CSS, сознательно или бессознательно, толпы разработчиков и, особенно, разработчиков фреймворков, начали делать одну и ту же "странную" вещь. Они начали везде использовать div и span элементы. Вместо параграфов (p) мы видели блочные элементы, вместо заголовков (h1-h5), div с классом "h2", вместо внутренних (inline) элементов, блоки, которым насильно через css приписали inline-свойство и т.п.
Если вы откроете какой-нибудь популярный большой сайт и посмотрите на его код, вы можете ужаснуться глубине вложенности некоторых div-цепочек.
И это все происходило и происходит несмотря на общий хайп вокруг HTML5, веб-стандартов, важности семантической разметки и т.п. Порой даже может показаться, что разметка классами (css) победила разметку смыслами (семантикой html).
Если вы зашли в веб-разработку или веб-дизайн в последние несколько лет, вы почти наверняка в своей работе опираетесь на какие-то готовые фреймворки, большинство из которых построены на базе манипуляций множеством div и span элементов. И если задуматься, почему так происходит, то ключевой ответ -- это JavaScript, все больше и больше JavaScript.
И, в принципе, если вы понимаете, что вы делаете (!), в этом нет ничего плохого. Вы достаточно быстро можете получить хороший результат и выпилить те элементы, которые делают ваш продукт хуже с точки зрения пользователя (например, генерируют излишнее количество блоков, утяжеляя страницы или рендеринг).
Сегодня мы получили ситуацию, когда большинство разработчиков не представляют себе запуск нового проекта без добавления нескольких пакетов из NPM или Composer, не будучи при этом уверенными, чем занимается вносимый код. Фактически, мы оказались в условиях, когда мы научили целое поколение разработчиков учить создавать и запускать проекты с недоверенным кодом (!).
Причем как факт деятельности, а не как ее осознание. Вы скорее найдете вакансию, в которой от вас требуют знания конкретных новых, модных фреймворков, нежели спросят о способности написать с нуля чистый и безопасный код.
Когда эта резиновая конструкция из пятнадцати слоев кода, который мы не понимаем и который писали не мы, начинает натягиваться и лопаться по швам, мы обвиняем HTML и CSS в ошибках разработчиков. Это приводит к созданию новых культов сложности -- более специализированных CSS, как правило, натянутых на JavaScript.
И снова, проблема не в JavaScript, а в том, что за счет усложнения технологии мы получаем сиюминутное (массовое) решение проблемы вместо намеренного воздействия на точку ее возникновения. Массовый workaround становится нормой разработчиков, но никто не замечает, что она вся стянута кусками изоленты.
Часто оказывается, что для проблемы даже есть готовое решение (вроде CSS Grid для управления позиционирвоанием блоками), но... ведь уже есть неплохой фреймворк? Да, придется инвестировать с обучение (изучение нового), но часто оказывается, что это полезная инвестиция, открывающая в том числе те возможности, которые в фреймворк не были заложены в принципе.