Главная » Хабрахабр » Frontend 2018: многообразие фреймворков и недостаток миддлов

Frontend 2018: многообразие фреймворков и недостаток миддлов

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

Попутно мы поговорили про то, как происходит отбор докладов, и какие тут возникают трудности. О том, как выглядит и куда движется современный frontend, я расспросил Сергея Попова, члена программного комитета нашей FrontendConf, которая пройдет в конце мая в Москве в рамках РИТ++.


— Что для тебя frontend?

Ко всему, что не касается хардкорного программирования, зачастую формируется несколько снисходительное отношение. — Для меня frontend — это не только JavaScript, но и верстка интерфейсов. Я как раз в большей степени отвечаю за интерфейсную часть, в частности за верстку, а не за хардкорный JavaScript. Но без решения таких задач не будет никаких сайтов (как и без бэкенда).

— Что сейчас происходит в этом сегменте?

Существует огромное количество фреймворков и подходов к решению задач. — Все составляющие фронтенда сегодня очень активно развиваются. В решении технологических задач весомую роль начинает играть понятие моды (в первую очередь, на названия тех же фреймворков). В последние годы этот «зоопарк» уже достигает абсурда —  люди начинают выбирать технологии просто потому, что у них больше звездочек на GitHub. Во фронтенде только один язык — JavaScript. Но такова отрасль. И нам приходится разрабатывать надстройки — фреймворки, позволяющие писать на JavaScript проще и лучше. Мы, в отличие от бэкенда, не можем пользоваться другими языками (у них есть PHP, Python, Ruby; они могут использовать Node.js как серверный язык программирования и тому подобное).

— Многообразие фреймворков — одна из базовых особенностей фронтенда?

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

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

— А ты сам сталкивался с необходимостью перехода с одного фреймворка на другой?

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

— Заметны ли какие-нибудь тенденции в развитии фреймворков в целом?

Из крупных у нас были Angular и React; появился Vue. — Честно говоря, я не слежу за мелкими фреймворками. Если бы все, кто его изучал, сейчас писали бы именно на Vue, у этого фреймворка была бы самая большая доля на рынке. Поначалу к нему отнеслись скептически, но потом он начал набирать популярность.

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

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

— А какой фреймворк ты сам предпочитаешь?

Я писал только на React, поэтому не могу говорить объективно. — Высказывать личные предпочтения по поводу использования того или иного фреймворка можно, попробовав как минимум и Vue, и React, и Angular.

В какую сторону, условно говоря, ветер дует? — Как развивается сегмент с точки зрения кадров?

Специалисты становятся лучше, они больше углубляются в UI/UX — в этом смысле мы движемся в сторону Запада, где зачастую нет выделенного верстальщика, а есть дизайнер, который разрабатывает интерфейсы с точки зрения UI/UX, и есть frontend-разработчик, создающий логику. — Активно развивается верстка в целом.

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

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

И теперь, когда у меня есть свободное время, я продолжаю заниматься UI/UX — хоть на рынке пока мало компаний, которым нужен frontend, совмещенный с UX. Осознав это, я начал развиваться параллельно в нескольких направлениях. Откровенно говоря, развитием надо было заняться раньше.

Это так? — Считается, что квалифицированного frontend-разработчика искать чуть ли не сложнее, чем бэкендера.

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

Ребята, которые заканчивают обучение, не могут найти работу и получить опыт. Но источник проблемы — на первых ступенях. Но джуниора без опыта брать никто не хочет. Многие из них — потенциально хорошие разработчики, которые через два-четыре года могут дорасти до middle, а через 5-7 лет — до senior. А ни миддлов, ни сеньоров у нас не будет, пока мы не начнем выращивать джуниоров (самостоятельно они могут вырасти не совсем правильно). Всем нужны как минимум middle: из-за отсутствия доверия менее квалифицированным специалистам. В какой-то момент мы просто упремся в потолок — джуниоры не развиваются, новым миддлам взяться неоткуда, а все хорошие middle уже к тому моменту уже дорастут до сеньоров.

Наш рекрутинг постоянно сталкивается с этим при поиске разработчиков уровня middle и senior. Я считаю, что те, кто отрицает проблему, еще просто не прочувствовали ее на себе. И чем дальше, тем хуже. На позицию middle чаще приходят те, чьи навыки больше соответствуют junior.

— И что делать?

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

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

— Может, как-то использовать отраслевые мероприятия?

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

И мы даже нашли несколько людей, которые взяли джуниоров, запустив проект, помогающий новичкам в поиске работы. Я как-то выступал с докладом о новичках — о том, что им надо давать шанс. То есть получилось очень локальное решение — не масштабов отрасли. Но за год мы решили проблему для 30 — 40 специалистов.

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

— В чем причина такого «ужаса» перед джуниорами?

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

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

Я не раз вступал в диалог с сообществом на тему того, что джуниорам надо доверять, ведь с каждым годом специалистов становится все больше (объективно порог вхождения во frontend ниже, чем в тот же backend), и им всем надо развиваться.

— Что сегодня необходимо изучить frontend-разработчику, помимо JavaScript?

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

Сейчас появились отдельно React-, Angular- и Vue-разработчики и все меньше JS или frontend-разработчиков. На мой взгляд, для JS-разработчика важнее всего понять, что нельзя зацикливаться на одном фреймворке и или начинать изучать JS с фреймворка. Мы уже через это проходили — в свое время у нас множились JQuery-разработчики, способные написать 10 тыс. Но это тупиковый путь. строк кода на JQuery, но не готовые сделать то же самое на JavaScript (хотя по сути JQuery — это просто библиотека, которая помогает быстрее писать на JS).

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

— А как вы относитесь к развитию специалистов в направлении fullstack-разработки?

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

На данный момент знаю в этой сфере почти все (конечно, есть некоторые вещи, которые я не пробовал, но я знаю о том, что они есть и как их можно применить). Я занимаюсь версткой почти 10 лет. Квалификация тех, кто занимается этим 15 и более лет, вопросов не вызывает. И мне немного странно видеть, когда человек с трехлетним опытом работы причисляет себя к fullstack — вряд ли за три года можно изучить все технологии. Хотя на рынке есть те, кому больше нравится именно fullstack; и на таких специалистов есть спрос. Но я считаю, что лучше развиваться в чем-то одном, поскольку чем дальше ты движешься, тем ценнее ты как специалист в этой сфере.

— А что в последний год изменилось во фронтенде технологическом плане?

На прошлой конференции я только рассказывал про CSS Grid Layout, а сейчас он уже полностью принят. — Безусловно, появились новые технологии. Развивается CSS Houdini.

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

В начале года Microsoft «похоронила»  Windows Phone 8. Как мне кажется, в этом году важной тенденцией был еще больший отказ от поддержки старых браузеров. Теперь официально нет ОС, в которой не было бы, например, Edge. 1 — последнюю ОС, где единственным браузером был Internet Explorer. Однако это важный шаг к убийству старых браузеров, которые на самом деле тормозят отрасль.
Большинство возникающих проблем упираются именно в кросс-браузинг. Это не означает, что все перестали пользоваться IE и перешли на современные браузеры. Они решаемы, но использовать на 100% современные технологии мы не можем именно из-за поддержки старых систем.

— Как в условиях борьбы моды и технологий твой программный комитет отбирает доклады?

Мы пытаемся понять, что услышим в итоге: реальный опыт или абстрактные рассуждения. — Решению по каждому докладу предшествует достаточно долгое обсуждение темы — в первую очередь, с докладчиком. И причину, по которой проблема решалась именно так.

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

— У каких докладов больше шансов?

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

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

Можно ли по ним выявить вопросы, которые волнуют отрасль больше всего? — Многие доклады на конференцию уже поданы.

Все доклады рассказывают о чем-то новом. — Сложно выделить какие-то тенденции. Да, среди них много действительно хардкорных историй, но я сам ближе все-таки к интерфейсной части, чем к программированию, да и отрасль рассматриваю как взаимодействие всех элементов. Мне не очень понравилось численное превосходство докладов про JavaScript. Поэтому мне не нравится, что очень мало докладов про CSS, UI/UX, инструменты и т.п.

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

Об этом будут говорить и у нас. На западе сейчас очень популярна тема доступности интерфейсов. Прошел отбор доклад про то, как делать свой open source-проект — хотя в целом в нашей стране культура open source-проектов развита не сильно.

— Как вы думаете, в какую сторону FrontendConf следует развиваться дальше?

Хотелось бы иметь поток англоязычных докладов и приглашать туда спикеров с европейских конференций, чтобы наше сообщество развивалось в соответствии с мировыми стандартами. — Мне кажется, надо двигаться в сторону англоязычности. Но РИТ++ всегда был больше ориентирован на внутренний рынок, поэтому сложно сказать, нужно ли такое развитие самой конференции.

Друзья, очередной фестиваль конференций РИТ++ состоится уже совсем скоро — 28-29 мая в Сколково. В этом году он объединит в себе FrontendConf, BackendConf, RootConf, WhaleRider, Aletheia Business и съезд русскоязычных IT-сообществ. В общей сложности запланировано более сотни докладов и 35 митапов!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Наша книжная полка С#-программиста. А что у вас?

Привет! Обычно мы рекомендуем несколько источников, сопровождая их своими комментариями, почему именно они будут полезны. Будущие студенты Veeam Academy часто спрашивают нас о книгах, которые были бы полезны при подготовке к поступлению на наш курс по программированию на С#. Поэтому ...

[Из песочницы] Компрессия больших массивов простых чисел

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