Почему вы должны прекратить использовать UI-фреймворки Перевод

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

«Боже мой! Все крутые используют его!», не означает, что вы должны использовать его тоже.

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

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

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

Любые изменения, даже обновления, стоят дорого.

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

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

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

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

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

UI печально известен современными библиотеками и фреймворками пользовательского интерфейса. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, а теперь, черт возьми, 8. Все в течение чего — 6 лет? Я уверен, что есть куча других, о которых я даже не слышал.

— Angular — это не причуда, Бо. Извините, это так. На предприятии вы не можете так быстро менять библиотеки и обновлять всякое дерьмо. У вас не будет ни бюджета, ни ресурсов («ресурсы» — это корпоративный термин для людей, которые теперь будут вас ненавидеть).

Каждый раз, когда какая-то библиотека или фреймворк «обновляется» или меняет версии, это стоит вам денег.

Затраты по сравнению с фактическими выгодами.

Подумайте, какую структуру пользовательского интерфейса вы планируете использовать в своем или следующем проекте. Что фреймворк действительно делает для вас? Это экономит ваше время или просто дает вашему приложению некоторые крутые «умные» функции?

«Это дает нам привязку модели и DOM! Огромная экономия времени». Хорошо, вы можете сделать это с помощью плагина jQuery, который вам не нужно компилировать. Далее?

«Это дает нам MVC на внешнем интерфейсе с привязанными к модели шаблонами для SPA (одностраничное приложение)». Хорошо, но это не экономит ваше время; на самом деле, это отнимает у вас больше времени на создание страниц, компиляцию, а SPA ужасны, если вам нужна настоящая SEO и точная аналитика.

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

Да, мы делаем это; но НЕ проще. Я видел, как корпоративные разработчики, обремененные новой технологией wiz-bang, тратили буквально недели на исправление ошибок в своих средах разработки, потому что кто-то решил установить новую «инфраструктуру».

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

Просто скажите нет компиляторам пользовательского интерфейса.

Выбирая любую UI-библиотеку, первое, на что я смотрю, это нужно ли ее компилировать? Если ответ какой-то да или «вроде как», то это дерьмо не включается в исходный код.

Сейчас я не говорю об использовании Gulp или Grunt для управления библиотеками компонентов пользовательского интерфейса; я говорю о необходимости предварительной компиляции файлов JS и CSS в «читаемый браузером» код. Если браузер изначально не может прочитать то, что вы кодируете, выбросьте его.

Да, я люблю Sass (и в меньшей степени Less); но я ими не пользуюсь. Почему? Потому что, несмотря на то, что они могут сэкономить ваше время и отлично справляются с организацией CSS, мне они действительно не нужны. Я могу организовать свой CSS без них. Чего мне не нужно, так это добавления дополнительных ненужных шагов в процесс разработки и конвейер CI/CD.

Знаете ли вы, что на самом деле вы можете писать нативный CSS и нативный JavaScript без предварительной компиляции?! ДА! Какая отличная концепция!

Однажды я брал интервью у очень крупной компании, занимающейся видеоиграми. Вы знаете, во что менялась их политика развития? Обычный ECMA (JavaScript) и CSS. Никаких компиляторов. Кофескрипта нет. Нет машинописного текста. Они даже выдрали jQuery. Я был впечатлен.

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

Я прекрасно понимаю, почему они все это испортили. Теперь я лично не стал бы выбрасывать jQuery или Bootstrap, но их не нужно компилировать для запуска; и jQuery также не обновляется каждые 5 минут. Обычно вы можете обновляться, не вызывая огромных регрессий, если они вообще есть.

Вывод

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

Why You Should Stop Using UI Frameworks (Beau Beauchamp)