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

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

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

Front-end разработка в прошлом

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

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

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

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

Итак, в чем же преимущества и уникальность использования фреймворков?

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

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

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

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

Когда фреймворки умирают

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Следующий ниже код 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 составлял шесть строк, а решение Vanilla JS заняло двенадцать. Чтобы решить проблему, спрятать каждое изображение до его загрузки, требуется в два раза больше кода. Давайте посмотрим на альтернативу. Можно ли это решить и в jQuery? Проверьте это:

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

С парами дополнительных строк кода теперь существует только трехстрочное различие между jQuery и Vanila, но в 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"));

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

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

Вывод

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

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

Оригинал статьи Front-end Frameworks: Solutions or Bloated Problems?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *