Краткое содержание (TLDR)

Асинхронный JavaScript в форме одностраничных приложений (SPA) предлагает невероятные возможности для улучшения пользовательского опыта ваших веб-приложений. CSS-фреймворки, такие как Bootstrap, позволяют разработчикам быстро вносить изменения в стили, работая над структурой и поведением вещей.

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

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

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

Примеры включают:

  • судебный процесс
  • плоский рост
  • неспособность повернуть
  • упущенные возможности
  • кошмары найма и кадрового обеспечения

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

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

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

Для фреймворков SPA рекомендуется применять методы кодирования, обеспечивающие здоровое разделение проблем. Хотя это можно сделать с помощью React, Vue.js предлагает превосходный подход к достижению этого, который предлагает лучшее сотрудничество с более традиционными разработчиками внешнего интерфейса.

Показатель

  • Предисловие
  • Фон
  • История: асинхронный JavaScript | CSS-фреймворки
  • Симптомы: Div Soup | Смешение проблем
  • Проблемы: неуловимые ниндзя | Потеря опыта | Потеря ловкости | Сводка по влиянию проблемы
  • Основная причина: бэкендификация.
  • Решения: Работа с CSS Framework | Работа с фреймворками SPA

Предисловие

В 2014 году я поступил на программу веб-дизайна в Технологический институт Британской Колумбии (BCIT). По окончании меня взяли на работу в школу, чтобы я помогал с онлайн-обучением. Когда мне сказали, что я буду работать с Bootstrap, супер модным CSS-фреймворком Twitter, я очень обрадовался ...

Однако вскоре это волнение улеглось. Поработав с ним, я не мог не задаться вопросом, зачем это вообще было нужно. Загадочные class имена и либеральное использование <div> тегов, казалось, запихнули всю логику в HTML. Вскоре начали поступать жалобы, поскольку другие функциональные группы боролись с новыми накладными расходами.

Мы были техническим институтом, но наша кафедра была спроектирована на основе успеха инструкторов. Онлайн-курсы, разработанные нашей командой, в конечном итоге будут переданы нетехническим инструкторам из бизнеса, средств массовой информации, медсестер, строительства и т. Д. Если они не смогут понять это, они позвонят в службу поддержки Ed-Tech. Если бы Ed-Tech не могла этого понять, работа снова приземлилась бы на наши столы [часто с огромным глухим стуком].

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

Эти фреймворки соблазняли нас обещанием легкости и простоты, но оказалось, что это относительные термины. Для нас Bootstrap (и некоторые другие неудавшиеся эксперименты) вылились в большую борьбу с небольшим вознаграждением. Это была просто замаскированная ловушка для техобслуживания.

После нескольких месяцев намеков команда начала увлекаться идеей создания пользовательского фреймворка, основанного на фактической простоте (или, скорее, устранении всей сложности из HTML ). Решение, разработанное на основе сверхчистого кода с использованием терминологии, характерной для онлайн-обучения.

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

Самое главное, что наша команда больше не была бутылочным горлышком в жестких дедлайнах.

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

Являются ли многие современные инструменты и методы клиентского интерфейса всего лишь замаскированным техническим долгом?

Фон

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

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

История

Асинхронный JavaScript

В 2005 году Google поразил мир запуском Google Maps. Перетащите экран, и, как по волшебству, маленькие плитки будут появляться в поле зрения одна за другой.

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

CSS-фреймворки

В 2011 году Twitter, которому позавидовал мир технологий, приветствовал нас в их стиле разработки с использованием Bootstrap.

Bootstrap был первым широко распространенным фреймворком CSS, «Созданный для ботаников» «Для всех уровней квалификации». Он мгновенно снизил планку для работы с интерфейсом. Внезапно каждый бэкэнд-разработчик, кодирующий шаблон страницы на стороне сервера, мог добавить несколько классов к элементам и вуаля - CSS не нужен. Они получили возможности, которые соответствовали и даже превзошли возможности значительного числа традиционных разработчиков внешнего интерфейса.

Симптомы

Изменить: Похоже, что этот раздел заставил некоторых людей сделать ошибочные выводы о статье. Если вы не согласны с рекомендациями в этом разделе, это странно, потому что я на самом деле их не даю…
Мои настоящие рекомендации находятся в разделе "Решения" 😉

Div суп

В настоящее время CSS Frameworks стали почти повсеместными. Bootstrap, похоже, сохранил свое превосходство, с почетными упоминаниями ZURB’s Foundation и Google Material Design. Также растет поддержка составных фреймворков, таких как Tailwinds, которые заявляют, что избавляют от некоторых проблем, присущих всем остальным.

Фреймворки SPA были немного более нестабильными, чем их аналоги на CSS. Backbone, Knockout и Ember безраздельно правили, пока не появился Angular от Google. Другие фреймворки приходили и уходили, ни одна из которых не предлагала значительного скачка в стоимости, но все в целом способствовали возникновению ощущения «усталости от JavaScript».

Затем в игру вступил Facebook с React, который был основан на идеальных композиционных компонентах и ​​молниеносной виртуальной модели DOM. Это было похоже на сборку лего с двигателями и краской.

Все это звучит нормально, пока вы не откроете инструменты разработчика. Под капотом вы сталкиваетесь с беспорядочной массой имен классов, разбросанных по ужасной смеси div soup.

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

Смешение проблем

Когда добавление 6 или 7 загадочных имен классов в тег HTML квалифицируется как «стиль», я бы сказал, что мы сделали огромный шаг назад во времени. Мы благополучно вышли за рамки макетов таблиц, но лишь чуть-чуть превзошли использование встроенных стилей.

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

Важно отметить, что для тех, кто присоединился к веб-разработке в последние несколько лет, это ненормально.

Мне нравится этот твит, но в их примере явно отсутствуют какие-либо правила представления, которые могут быть еще более заразными для проекта React. Добавьте в смесь Bootstrap, и вы получите идеальный рецепт большого шара грязи, граничащего с бетоном.

РЕДАКТИРОВАТЬ:
Мне сообщили, что знаменитый Крис Койер недавно опубликовал статью под названием Великое разделение, в которой говорится немного глубже. в симптомы этого явления. Если вы жаждете более подробных сведений о бэкэндификации, я настоятельно рекомендую прочитать его. В противном случае продолжайте читать мой анализ проблем, их причин и некоторых доступных решений.

Проблемы

Неуловимые ниндзя

В 2014 году фронтенд-разработчики были объективно дешевле, чем бэкэнд-разработчики. Спустя 5 лет фронтенд превратился в полноценный стек.

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

Не поймите меня неправильно, это чистый позитив, по крайней мере, для небольшой части общества, но потенциально разрушительный для любого, кто пытается вести малый или средний бизнес (SMB).

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

Потеря опыта

Ниндзя на самом деле не существует. Мастер на все руки на самом деле не является мастером ни в чем. Как универсал, я полностью осознаю, что нельзя быть хорошим во всем (даже если я стараюсь). Хотя универсалы определенно имеют место в вашем бизнесе, вероятно, им не следует работать в одиночку в глубине вашей кодовой базы.

Когда каждый разработчик в вашей команде является «JavaScript-ниндзя», вы фактически оставляете себя незащищенным от слепых зон. Несомненно, повсюду в приложениях полно трагических случаев <div className="btn" onClick={this.handleClick}>.

«Какая разница, все работает нормально», - говорите вы? Хотя это может работать для здорового человека, те, кто полагается на вспомогательные технологии, не смогут получить доступ к частям вашего приложения.

Доступность (A11Y) на начальном этапе, как правило, способствует лучшему взаимодействию с пользователем для всех, поэтому, если вы выберете здесь ярлыки, вы можете быстро изменить что-то большее, чем просто визуальные, физические или когнитивные.

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

[Национальная федерация слепых] и Секстон заявили, что Target.com нарушил [Закон об американцах с ограниченными возможностями], потому что слепые пользователи не могут просматривать продукты и покупать те, которые им нужны. Слепые пользователи также не могут получить доступ к такой информации, как возможности трудоустройства, новости для инвесторов и политика компании. 27 августа 2008 г. NFB и Target урегулировали иск о выплате 6 000 000 долларов США плюс дополнительный ущерб и строгий постоянный мониторинг для обеспечения постоянной доступности.

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

Потеря проворства

Такие фреймворки, как Bootstrap и React, привлекательны тем, что предлагают невероятную скорость запуска. Bootstrap часто называют отличным инструментом для создания прототипов. Тем не менее, инструменты прототипирования по своей сути производят дешевое и низкокачественное представление готового продукта.

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

Не верите мне? Подумайте о будущем, в котором ваша укладка начнет казаться устаревшей. Вступают новые соревнования с более привлекательным пользовательским интерфейсом, и пора улучшить свою игру или столкнуться с неактуальностью.

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

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

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

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

🤯

10 фунтов кофе, и несколько месяцев спустя вы снова готовы соревноваться в цене (но не совсем) ...

Если ваша цель - краткосрочное приобретение, возможно, вам все равно. Но помните, ловкость и маневренность в технологиях - это сила. Если долгосрочное видение вашего продукта - это медленно движущаяся машина, вы можете оказаться в проигрыше за столом переговоров.

Сводка по влиянию проблемы

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

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

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

  • Годовое обслуживание = 15–20% от первоначальных затрат.
  • Пожизненное обслуживание = 40–80% (в среднем 60%) от общих затрат.

Вот как выглядят 100 долларов США на первоначальную разработку при 20% ежегодном обслуживании в течение 10 лет:

Как видите, затраты на обслуживание превышают затраты на разработку всего за 5 лет. Он превышает 60% -ный порог общих затрат между 7 и 8 годами.

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

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

Первопричина

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

Это всего лишь гипотеза кресла, но я думаю, что эта диаграмма помогает объяснить тот порочный круг, в котором мы оказались:

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

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

Я часто слышу среди сторонников Bootstrap: «Как легко создать красивый рабочий прототип». Точно так же сторонники React скажут: «Мне нравится, что я никогда не покидаю JavaScript».

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

Однажды я стал свидетелем жарких дебатов по поводу инфраструктурного решения, в которых одна из сторон указала:

"Это делает простые задачи сложными ради того, чтобы сделать тривиальные задачи еще проще".

Когда я увидел типы вещей, которые наша команда пыталась решить с помощью Bootstrap, а затем и других альтернатив, я не увидел в этом необходимости. На мой взгляд, они пытались использовать громоздкое решение, чтобы обойти тривиальную проблему. К сожалению, тривиальный - понятие относительное. Сторонникам этих инструментов они предложили решения, которые казались серьезными проблемами.

Решения

Работа с фреймворками CSS

Чтобы начать сокращать вашу зависимость от фреймворков, таких как Bootstrap, я рекомендую прекратить применять классы, специфичные для фреймворка, непосредственно к вашему HTML. Вместо этого я бы посоветовал следующее:

%our-warning-button {
   @extend .btn;
   @extend .btn-warning;
}
.empty-shopping-cart-button {
  @extend %our-warning-button;
}

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

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

Наконец (и это самое главное), теперь у вас есть четкое разделение проблем между вашей структурой и стилем.

Работа с фреймворками SPA

Это может быть спорным и казаться невероятно долгим мошенничеством, но я рекомендую перейти с React на Vue.js, и вот почему:

<template>
    <!--Structure-->
</template>
<script>
    <!--Behaviour-->
</script>
<style>
    <!--Style-->
</style>

Здесь вы видите однофайловый компонент Vue, который способствует четкому разделению проблем. Мне очень нравится Vue за это (а также за их стремление к простоте).

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

Не поймите меня неправильно, у Vue есть все атрибуты фреймворка вроде React. Он очень гибкий, что позволяет создавать любой шар из грязи, который вам нравится. Точно так же React может быть реализован таким образом, что он начинает становиться немного более доступным (хотя и не приближается к степени Vue).

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

1. Никогда не помещайте в шаблон ничего, что не является прямой ссылкой на предварительно вычисленные данные, методы или компоненты.

2. Применяйте стили только через классы собственного дизайна и избегайте использования атрибутов стиля любой ценой.

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

Я оставлю вам одно последнее:

Выбранные нами инструменты влияют на нашу карьеру.
Клянусь, я хорошо разбираюсь в JavaScript. - jsday 2017, Jose J. Perez Aguinaga

Выбирай с умом!