Фронтенд-фреймворки: решения или раздутые проблемы?

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

Веб-разработка сегодня сильно изменилась с 90-х годов; мы можем создавать целые возможности, которые очень близки к тому, что может делать любое нативное приложение, и процесс разработки также изменился. Прошли те времена, когда для веб-разработчика переднего плана требовалось открыть Блокнот, ввести несколько строк кода, проверить его в браузере и загрузить в папку FTP.

Фронтенд-веб-разработка прошлого

Я должен начать с констатации очевидного: мир уже не тот, что был 10 лет назад. (Я знаю, это шокирует.) Единственное, что остается неизменным, — это перемены. Раньше у нас было очень мало браузеров, но было много проблем с совместимостью. Сегодня вы редко встретите такие вещи, как «лучше всего просматривать в Chrome 43.4.1», но тогда это было довольно распространенным явлением. Теперь у нас больше браузеров, но меньше проблем с совместимостью. Почему? Из-за jQuery . jQuery удовлетворил потребность в стандартной общей библиотеке, которая позволяла вам писать код JavaScript, который манипулирует DOM, не беспокоясь о том, как он будет работать в каждом браузере и в каждой версии каждого браузера — настоящий кошмар в 2000-х. .

Современные браузеры могут управлять DOM как стандартом, поэтому потребность в такой библиотеке значительно уменьшилась в последние годы. jQuery больше не нужен , но мы все еще можем найти ряд чрезвычайно полезных плагинов, зависящих от него. Другими словами, веб-фреймворки могут и не понадобиться, но они достаточно полезны, чтобы быть популярными и широко использоваться. Это общая черта большинства популярных веб-фреймворков, от React, Angular, Vue и Ember до моделей стилей и форматирования, таких как Bootstrap.

Почему люди используют фреймворки

В веб-разработке, как и в жизни, всегда удобно иметь быстрое решение. Вы когда-нибудь делали роутер на JavaScript? Зачем проходить болезненный процесс обучения, если можно решить проблему с помощью npm-install front-end framework? Время — это роскошь, когда клиент хочет, чтобы все было сделано вчера , или вы наследуете код от другого разработчика, предназначенный для определенного фреймворка, или если вы интегрируетесь с командой, уже использующей данный фреймворк. Посмотрим правде в глаза — фреймворки существуют не просто так. Если бы они не приносили пользы, ими бы никто не пользовался.

Итак, каковы преимущества и уникальные свойства использования фреймворка для веб-разработки?

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

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

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

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

Когда фреймворки терпят неудачу

Несколько лет назад сказать что-то вроде «Я не использую фреймворки — я не вижу в них реальной пользы» привело бы к вашей двери людей с факелами и вилами. Но сегодня все больше и больше людей задаются вопросом: «Зачем мне вообще использовать фреймворк? Они мне действительно нужны? Неужели так сложно кодировать без них?»

Я, безусловно, один из них — я никогда не был фанатом какой-либо конкретной среды и всю свою карьеру программировал без них. Если у меня есть выбор в этом вопросе, я всегда выбираю «Нет, спасибо». Я много лет занимался разработкой на JavaScript, а до этого — на ActionScript. Я программировал на Flash, когда большинство людей уже считали его мертвым. (Знаю, знаю… но я делал много анимаций, а анимация в простом HTML сложна.) Так что, если вы один из тех, кто никогда не думает о кодировании без фреймворков, позвольте мне показать вам несколько причин, по которым вы могли бы бороться.

«Один размер подходит всем» — ложь. Могли бы вы представить себе написание одной программы, которая может делать все, чего вы достигли в своей карьере? Это одна из основных проблем фреймворков веб-разработки. У вашего проекта очень специфические потребности, которые мы обычно решаем, добавляя библиотеки, плагины или надстройки для расширения возможностей фреймворка. Ни один фреймворк не предлагает 100% того, что вам нужно, и ни один фреймворк не состоит на 100% из вещей, которые вы найдете полезными.

Наличие слишком большого количества кода, который вы не используете, может привести к задержке загрузки вашего сайта, что становится все более важным с каждым дополнительным пользователем. Другая проблема заключается в том, что мышление «один размер подходит всем» приводит к неэффективному коду. Возьмем, к примеру, $('sku-product').html('SKU 909090'); , представляющий собой код jQuery, который, как мы все знаем, в конце концов будет переведен во что-то вроде document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Такая разница в одной строке может показаться неважной, но изменение содержимого определенного элемента страницы — это как раз и есть достоинство React. Теперь React выполняет процесс создания представления DOM и анализа различий в том, что вы пытаетесь отобразить. Не проще ли с самого начала просто настроить таргетинг на контент, который вы хотите изменить?

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

Не отставать от Джонсов - это вещь. Вы когда-нибудь работали над проектом на AngularJS только для того, чтобы узнать, что вам нужно что-то, чего не было до выхода Angular 4? Вы вообще знали, что вышел Angular 5? Это еще одна огромная проблема; даже если вы придерживаетесь одного внешнего фреймворка, когда выходит новый крупный релиз, все может измениться так сильно, что код, над созданием которого вы так усердно работали, даже не будет работать в новой версии. Это может привести к чему угодно: от раздражающих небольших изменений, которые необходимо внести во множество файлов, до полного переписывания вашего кода.

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

Когда у тебя есть только молоток, все выглядит как гвоздь. Если вы часто использовали фреймворки для веб-разработки, это, вероятно, случалось с вами, когда одна кодовая база определяет форму кода, который вы будете использовать в будущем, даже если он связан только периферийно. Допустим, вы собираетесь создать такую ​​платформу, как YouTube, и хотите использовать Framework X. Может быть момент, когда, даже если это звучит нелепо в наши дни, вы решите использовать Flash для видео, потому что это то, что приходит. встроенный в каркас.

У фреймворков есть мнения, и они сильны; Например, React заставляет вас использовать JSX определенным образом. Вы можете видеть, что код используется таким образом повсюду. Есть ли альтернатива? да. Но кто его использует? Это не всегда плохо, но если вам нужно выполнять сложную анимацию, вам может понадобиться только фреймворк для анимации, а не весь React. Я видел, как люди делают сумасшедшие вещи, например добавляют jQuery на страницу только для того, чтобы добавить узел к элементу, что-то, что можно было бы сделать в ванильном JS с помощью document.getElementById('id_of_node').appendChild(node); .

Eval — зло, но .innerHTML — макиавеллистский

Я хочу уделить время отдельному изучению этого момента, потому что я думаю, что это одна из причин, по которой все больше людей не пишут код без фреймворков. Когда вы увидите, как работает большая часть кода при попытке добавить что-то в DOM, вы обнаружите кучу HTML-кода, введенного свойством .innerHTML . Кажется, мы все согласны с тем, что eval плохо запускает код JavaScript, но я хочу обратить внимание на .innerHTML . Когда вы вставляете HTML-код в виде простой строки, вы теряете все ссылки, которые у вас могли быть на любой из созданных вами узлов. Это правда, что вы можете получить их обратно, используя getElementsByClassName или назначив им id , но это менее чем практично. При попытке изменить значение одного из узлов вы обнаружите, что снова отображаете весь HTML.

Это хорошо, когда вы начинаете кодировать. Вы можете легко сделать много простых вещей без особого опыта. Проблема возникает из-за сложности современных веб-сайтов, которые, как правило, больше похожи на приложения — это означает, что нам нужно постоянно менять значения наших узлов, что является дорогостоящей операцией, если вы делаете это, повторно присоединяя всю структуру. через .innerHTML . React эффективно решает эту проблему с помощью теневого DOM, а Angular решает ее, используя привязку как простой способ изменить значение, отображаемое на странице. Однако эту проблему также можно довольно легко решить, отслеживая создаваемые вами узлы и сохраняя те, которые будут повторно использоваться или обновляться в переменных. Есть и другие причины держаться подальше от .innerHTML в целом.

Самые большие мифы о программировании без фреймворков

Время - деньги. Да, я возвращаю эту концепцию из более ранней. Многим людям кажется, что если они перестанут использовать популярную веб-инфраструктуру, мы мгновенно перейдем к Интернету 90-х, когда <marquee> был всеми любимым тегом, вращающиеся GIF-файлы на сайте Geocities были модными и острыми, а Alta Vista была впереди. для веб-поиска, и счетчики посещений были повсеместны.

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

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

Полезен ли посредник? Конечно. Но обычно в этом нет необходимости . Каждая написанная вами строка кода имеет большее значение, поскольку вам не нужно адаптироваться к требованиям фреймворка. Может показаться, что вы пишете больше кода на чистом JavaScript, потому что способ создания элементов DOM требует строк для создания элемента, присоединения его к DOM и, возможно, добавления класса для стиля, в отличие от вызова одной строки код в JSX. Но если вы сравните код, использующий такую ​​библиотеку, как jQuery или React, ванильный JS может быть очень похожим по длине. Иногда он длиннее, но иногда и короче.

Нет необходимости изобретать велосипед. Мантра профессоров компьютерных наук во всем мире. И это правда — просто это не обязательно означает конкретно фреймворки. Например, отправка Ajax-запроса для загрузки или сохранения данных требуется почти в каждом веб-приложении, но отсутствие фреймворка не означает, что вам нужно каждый раз писать код заново. Вы можете создать свою собственную библиотеку или кодовую базу или извлечь код из других источников. Чем он меньше, тем проще его изменить или настроить по мере необходимости, поэтому он пригодится, когда вам нужно что-то конкретное для проекта. Легче изменить 100-200 строк кода, чем перемещаться по горе файлов, которые могут содержаться в сторонней библиотеке или фреймворке.

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

Я ХОЧУ ДОКАЗАТЕЛЬСТВА

Хорошо. Давайте перестанем говорить о теории и перейдем к реальному примеру. Несколько дней назад мне нужно было показать список брендов с логотипами для магазина. Первоначальный код использовал jQuery, но у него была проблема, когда при загрузке в Mozilla он показывал значок сломанного изображения для брендов, у которых еще не были загружены логотипы. Мы не можем допустить, чтобы магазин выглядел незавершенным только потому, что компания X еще не закончила свою часть работы, но функция должна была быть запущена.

В следующем коде используется jQuery-эквивалент .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

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

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Первоначальный код jQuery состоял из шести строк, а ванильное JS-решение занимало двенадцать. Чтобы решить эту проблему, скрытие каждого изображения до его загрузки требует в два раза больше времени для кода. Итак, давайте рассмотрим альтернативу. Можно ли это решить и в jQuery? Проверьте это:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

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

Давайте посмотрим на React:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

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

Для каждого примера результаты будут разными. Иногда jQuery будет короче. Иногда React побеждает. Бывают случаи, когда ванильный JS может быть короче, чем они оба. В любом случае, цель здесь заключалась не в том, чтобы доказать, что одно по своей сути превосходит другое, а в том, чтобы продемонстрировать, что нет существенной разницы между использованием vanilla JS и использованием фреймворка, когда речь идет о длине кода.

Заключение

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

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