На чем написан фронтенд Youtube

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

Фреймворки, похожие на Bootstrap и Foundation изменили то, как люди строят свои сайты. Эти инструменты делают процесс разработки сайта намного проще, особенно для не-программистов, и позволяют создать полноценный сайт в минимально возможные сроки без особых усилий. Но такой «автоматический» подход построения сайта имеет серьёзные недостатки.

Таким образом возникает вопрос: Чем проще решение, тем лучше?

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

Как устроен Frontend в 2023. Про React, Angular, NodeJS и собеседования. Алексей Попков

Преимущества готовых к использованию решений

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

• Вам не нужно быть программистом. Необходимы лишь базовые знания HTML и CSS, которых в большинстве случаев достаточно, чтобы получить красивый и работающий сайт. Для вас всё уже сделано квалифицированными разработчиками.
• Как упоминалось ранее, фреймворк серьезно сокращает время и силы, расходуемые в процессе строительства сайта..
• Функция Plug-and-play (дословный перевод «включил и играй (работай)»). Нам нужно сделать только некоторую разметку, чтобы получить полностью функциональный кусок кода (хорошо приготовленный из HTML, CSS и JavaScript суп), при этом не беспокоясь о стилизации, динамическом поведении и так далее.
• При использовании фреймворка, мы можем быть уверены в том, что у нас есть стабильный и хорошо протестированный код.
• Мы получаем регулярные обновления с исправлениями ошибок и новыми функциями для фреймворка.
• Благодаря популярности готовых к использованию фреймворков, вы можете рассчитывать на помощь сообщества в виде статей, учебных пособий (в рамках вводного процесса), базу дополнений и расширений (для построения сайтов).

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

Что такое frontend?

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

Итак, простое решение — это хорошо, но.

Недостатки готовых решений

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

• Хотя Plug-and-play функциональность великолепно звучит, прежде чем воспользоваться всеми прелестями фреймворка вы должны потратить своё время на то, чтобы узнать, как использовать его.
• Если задуматься, то термин «готовые к использованию» подразумевает под собой «одно решение для всех», когда фреймворк пытается решить проблемы всех пользователей для каждой ситуации, может случиться так, что веб-разработчик столкнётся с огромным количеством ненужного ему кода.
• Так как готовые решения сделаны для массового потребителя, вы можете быть почти уверены в том, что вам придётся что-то настраивать под себя для удовлетворения потребностей вашего проекта, что занимает дополнительное время.
• Если не вносить никаких изменений в фреймворк то, ваш сайт будет выглядеть так же, как и все остальные, что может повредить имиджу вашего продукта или, по крайней мере, ничего не сделает для его улучшения.
• Во многих случаях, фреймворки не могут покрыть все потребности веб-разработчика, что приводит к дополнительной интеграции сторонних компонентов (например, в виде раздутых плагинов JQuery и т.п.).
• Практически, вы не имеете никакого контроля над кодом. При этом, если команда разработчиков решит удалить какой-то компонент фреймворка, то вы будете вынуждены признать это изменение. Иначе, если вы не хотите соглашаться с их мнением, придётся модифицировать фреймворк или использовать старую версию их продукта.

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

Получается, что «среднестатистическое» решение — это не разумное решение.

Преимущества собственных решений

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

• Создание собственного решения позволит вам сэкономить время и силы в будущем, потому что он был построен под ваши потребности в долгосрочной перспективе.
• Вам или вашей команде не нужно изучать, как использовать и настраивать его, потому что вы уже будете знать его до последней строки кода (хотя новым членам команды придётся изучить его).
• Он оптимизирован для удовлетворения всех ваших потребностей. Таким образом гораздо проще добиться высокой производительности.
• Вы включаете в него только то, что необходимо, и в том виде, как это нужно лично вам. Нет ненужных вам вещей — нет раздутого кода.
• Вы имеете полный контроль над кодом и его реализацией и можете быть уверены в том, что необходимые вам функции и компоненты не будут удалены в следующей версии, конечно, если в этом нет нужды.
• Полная модульность. Гибкость вашего решения зависит только от вас. Вы можете использовать только те части вашего фреймворка, которые вам нужны для конкретного проекта.
• Унифицированная кодовая база. Вы можете свести к минимуму использование сторонних компонентов.
• Уникальность вашего сайта гарантируется на 100%. По умолчанию, темы в большинстве фреймворков в какой-то степени однотипны, и вам придётся создавать свой стиль оформления. Однако, для вашего фреймворка можно создавать уникальные темы с самого начала разработки..
• Несмотря на время, затраченное на разработку фреймворка и дальнейшего его обслуживания, сам процесс разработки может многому научить вас, и, таким образом, улучшить ваши навыки веб-разработчика.

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

Недостатки собственных решений

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

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

Третье решение

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

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

Является ли «изобретение колеса» реальной проблемой?

На форумах, в блогах и подобных ресурсах, одним из основных аргументов против собственных решений, является вопрос: Зачем изобретать велосипед?

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

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

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

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

Избегать «изобретения колеса» не стоит. Его не стоит бояться или относиться к нему скептически. Это естественный процесс и это происходит очень часто. Просто не бойтесь изобретать велосипед.

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

Как сделать правильный выбор?

Чтобы принять правильное решение, необходимо задать правильный вопрос. И он не может звучать так: Какое решение правильное? Правильный вопрос будет звучать иначе: Какое решение правильное для меня?

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

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

• Смогу ли я сделать это?
• Достаточно ли у меня свободного/дополнительного времени?
• Разумно ли это делать самому?

Примечание

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

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

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

• Оригинальная статья: Front-end Frameworks: Custom vs. Ready-to-use Solutions
• Автор статьи: Ivaylo Gerchev

Делимся на оплату хостинга или кофе.
Чем чаще пью кофе, тем чаще пишу статьи.

Источник: canonium.com

Анатолий Островский. О работе фронтенд-разработчика

– Кто такой фронтенд-разработчик?
– Разработчик интерфейсов (также этого специалиста называют фронтенд-разработчик от английского front-end developer) занимается созданием клиентской части сайтов, а также программной части. Фронтенд-разработчик отвечает за то, что пользователь видит на сайте, и то, как он с ним взаимодействует.

Кроме того, фронтенд, так же как и бэкенд (от англ. back-end — «оборотная сторона» — программно-аппаратная часть — прим. сайта), включает в себя разработку серверного кода. Постараюсь объяснить разницу между фронтендом и бэкендом в классическом понимании.

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

– Чем фронтенд-разработчик отличается от дизайнера, который тоже работает над тем, как выглядит сайт?
– Дизайнер придумывает внешний вид интерфейса, а фронтенд пишет код и воплощает в жизнь макет. Однако разработчик и сам должен разбираться в дизайне. Художник может в чем-то ошибиться, пожертвовать удобством в пользу красоты. Дизайнер не обязан следить за каждым шагом разработчика. Его задача в первую очередь нарисовать идею.

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

– Как вы стали фронтенд-разработчиком?
– Мое образование не слишком связано с программированием. Я окончил Российский экономический университет имени Г.В. Плеханова по специальности «прикладная информатика в экономике». Еще во время учебы я решил, что хочу стать дизайнером сайтов. Планировал поступить на курсы в Британскую высшую школу дизайна, но, к сожалению, они совпали с моей сессией.

Тогда я начал самостоятельно изучать литературу — читал книги и статьи по веб-дизайну. Позже решил опробовать теоретические знания на практике. Создал свою домашнюю страницу, позже дополнил ее форумом. На третьем или четвертом курсе я устроился стажером в небольшую веб-студию.

После полугода работы в студии я приобрел неплохой опыт и поступил в Школу разработки интерфейсов «Яндекса». А после ее успешного окончания пошел работать в сам «Яндекс».

– Получается, фронтенд-разработчику не обязательно иметь специальное высшее образование? А где он может приобрести необходимые для работы навыки?
– Например, на курсах. Могу порекомендовать Школу разработки «Яндекса», в которой учился я сам. Насколько мне известно, такие Школы проводят не только в Москве, но и в Санкт-Петербурге, Минске, Екатеринбурге. Но обучают там не с нуля. Абитуриенты должны уметь создавать простенькие сайты, верстать, писать на языке программирования JavaScript.

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

Также я наслышан о курсах от портала javascript.ru, но сам на них не ходил.

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

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

Например, два года назад Facebook презентовал свою библиотеку для разработки фронтенда React . Сегодня у нее уже почти 1000 контрибьютеров (то есть 1000 человек поучаствовали в написании ее кода). Это огромные масштабы. В том же бекенде такого практически не бывает, все решения закрытые и делаются определенной группой людей.

Через год после запуска эта библиотека эволюционировала, и с помощью нее можно делать приложения для iOS и Android. То есть умея делать сайты на React, человек автоматически может быть и мобильным разработчиком. По-моему, это очень здорово. И, думаю, это только начало.

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

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

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

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

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

– Сколько получает фронтенд-разработчик?
– Зависит от знаний и умений специалиста. Я не очень хорошо знаю рынок сейчас, но, думаю, стажер или младший разработчик получает от 60 тысяч в месяц. Конечно, если под фронтендом понимается только верстка страничек без JavaScript, оплата будет меньше.

Верхней же зарплатной границы нет — все зависит от способностей специалиста.

– Будут ли фронтенд-разработчики востребованы в ближайшие 10–15 лет?
– Уверен, что будут. Уже сегодня фронтенд-разработчик может создавать не только сайты и веб-приложения, но и приложения для мобильных устройств. Приложения для телевизоров и некоторые операционные системы, например, Firefox OS, тоже сделаны на технологиях фронтенда. Я думаю, что в будущем возможности использования технологий, которыми пользуются фронтенд-разработчики, будут только расти.

– Чем может заняться фронтенд-разработчик, решивший попробовать себя в чем-то новом?
– Он может заняться разработкой мобильных приложений. Многие решения в мобильной разработке и разработке интерфейсов весьма похожи.

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

– Кто для вас является ролевой моделью в профессии?
– Думаю, каждый находит своих «гуру» в определенных сферах. Например, в мире CSS (верстки) для меня это Роман Комаров. У него есть много хороших докладов и замечательный сайт с настоящей «магией» верстки.

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

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

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

– Что вы могли бы посоветовать почитать и посмотреть подросткам, которые хотят больше узнать о фронтенд-разработке?
– Для старта я бы порекомендовал платформу Codecademy. Там можно изучить популярные языки программирования, пройти уроки по фронтенд-разработке, а потом попробовать что-нибудь сделать самому. Обязательно нужно много раз перечитать курс по JavaScript. Еще один полезный сайт — HTMLBook. На нем есть много примеров верстки. И вообще это большая энциклопедия для разработчика интерфейсов.

Сам я периодически пересматриваю лекции на youtube-канале «Фронтенд», где выступают ребята из «Яндекса».

Источник: intalent.pro

5 трендов фронтенд разработки, которые останутся с нами в 2023 году

Программные фреймворки облегчают разработчикам жизнь, позволяя контролировать процесс разработки с помощью единой платформы. Вместе с разработчиками Purrweb разбираемся, как и на чем писать код, и почему стоит использовать такие фреймворки как React, Vue.js, AngularTypeScript, GraphQL, Toolkit и Svelte.

Популярные фреймворки

Фреймворки — наше все. Звучит смело, но это так. Без них сегодня не напишешь ни один проект. Фреймворк — это программное обеспечение, которое упрощает процесс фронтенд разработки и сборки различных модулей одного проекта.

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

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

Тем более, когда существуют три кита фронтенда с мощным IT-комьюнити — фреймворки React, Vue и Angular.

React

React создал Джордан Валке, разработчик из Facebook. Впервые библиотеку использовали в 2011 году в новостной ленте Facebook, через год — в Instagram, а в 2013 открыли код для всех. Сегодня React — лидер в области инфраструктуры JavaScript UI. На React написаны такие приложения-гиганты, как Skype, UberEats, Airbnb.

READ MORE Топ-20 приложений на React Native в 2023 году. UPD