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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    — Активно развивается верстка в целом. Специалисты становятся лучше, они больше углубляются в 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?

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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



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

    Конференции Олега Бунина (Онтико)

    376,00

    Конференции Олега Бунина

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

      А почему странно? Совсем не хочется джуниора — год вкладываешь в его развитие и машешь ручкой. И здесь можно понять джуна, ведь на рынке его стоимость чуть ли не удвоилась, а поднимать з/п вдвое на старом месте, после года вложений, никто не будет.
      Так и почему не пойти сразу на рынок за мидлом?
        +2
        А джуниор не вкладывается, что ли? Работы не делает?
          +6
          Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи. Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.

          Ошибочно считать вложениями в специалиста только его зарплату и «печеньки». Прежде всего это вложения времени других специалистов.
            +1
            Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи.
            Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит.

            Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.
            Срочные фичи джуниорам опять же не дают.
              +2
              > Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит

              Всё зависит от процессов. Уж ревью кодда джунов по нынешним временам практически везде. И на практике ревью джунов отнимает гораздо больше времени, чем «старых», с которыми обсуждаются рабочие вопросы как часть нормального рабочего процесса.
              0
              Неоплаченные затраты у большинства специалистов будут побольше, чем вложения фирм в них. Как финансовые, так и временные. Затраты на учебу по специальности, затраты на самообучение, на постоянное изучение технологий, которые через какое-то время оказываются невостребованными, затраты времени на дорогу на работу и обратно, затраты на поиск работы и подготовку к собеседованиям.

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

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

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

                Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
                  +1
                  Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
                  Больше верится, что возраст работодателей дает о себе знать. Давно ведь уже известно: image
                  Не знаю, насчет опускания планки соискателей. Зато замечаю повышение планки в вакансиях. Это касательно старых технологий. В новых областях первое время требования не завышенные.
            +6
            Очень интересно.
            То есть стоимость чуть ли не удвоилось а поднимать зп почему никто не будет?
            Это же супер логично, что он уйдет туда, где у него будет намного большая зарплата.
            Не в адекватной оплате труда ли секрет?
              0
              Удвоилась в текущем моменте, но перед этим были ещё месяцы, когда он работал в минус.
                0
                Рынок труда работает исключительно в текущем моменте (обещание участия в прибыли уже не совсем рынок труда). Работа в минус — это не инвестиции в будущую работу в плюс, а инвестиции в отсутствие работы в минус кучи других людей когда джун уйдёт туда, где его оценят по рынку. Незаменимых не должно быть, но любая замена — это затраты.
                  0
                  Про текущий момент всё понятно, но это ответ на тот исходный вопрос, почему многие не хотят связываться.
                  Работа в минус — подразумевается, что первое время от отнимает много времени и внимания других людей. То есть затраты на его обучение намного выше его номинальной з/п.
                    0
                    Да джуниор делает меньше задач и дольше чем мидл, но ведь зп ему платят в столько же раз меньше, но вот когда он начал делать задачи в два раза быстрее, то логично было бы поднять в столько же раз и зп, но дело в том что некоторым компаниям пихологически сложно поднять зп в два три раза, сам по тем же причинам уходил
                      0
                      Проблема том, что джун на зарплату в столько раз меньшую не идет. Поэтому миддлу платят не в N раз больше. И это проблема как со стороны джунов, которые много хотят, и со стороны работодателей, которые не готовы адекватно бустить ЗП. Собственно поэтому джуны и хотят много, и уходят часто.
                        +2
                        Видимо, им не хватает на жизнь, вот они и уходят. Джун обычно ест столько же, сколько и миддл.
                          0
                          Обычно просто уходят, где больше предложат.
                        0
                        но ведь зп ему платят в столько же раз меньше
                        Не в столько же.
                        Я понимаю, что ситуации могут быть разные, но по моему мнению, в пересчете на 1 условный рубль мидл делает намного больше. Потому что джун будет:
                        а) изначально тратить больше времени;
                        б) писать больше говнокода, который потом аукнется гораздо большим количеством багов и затратами на поддержку;
                        в) требовать внимания со стороны старших сотрудников, отнимая их время, которое к тому же дороже.
                        В итоге, имея (условно) номинальную зарплату вдвое меньше, количество пользы меньше вчетверо.
                          0
                          Сужу только по своему опыту, устроился в компанию джуниором, хотя уровенем уже был далеко не джун(с зп в 350 у.е., понравилась компания, и обещали быстрый рост) и в качестве работы не сильно уступал мидлам, у них зп там была около 1500 у.е.
                          В итоге проработав год, в зп поднялся до 700 у.е. а вот по скорости и качеству работы обогнал мидлов которые там работали, вот только поднять зп до их уровня мне отказали, т.к. я там проработал только год, а они уже более 3-х лет
                          Может у Вас и по другому было, но я столкнулся с этим на личном опыте
                            0
                            Тут возможны варианты:
                            1. Политический — руководство не захотело провоцировать волну требований о повышении от ряда других сотрудников.
                            2. Когнитивный — вам только кажется, что вы их во всём обогнали, а на самом деле есть ещё некие факторы, которые вам не видны, но видны руководству.
                            3. Сочетание обоих вышеперечисленных пунктов.
                  0
                  Всё правильно! Так и зачем нужны такие напряги, когда можно сразу взять мидла и работать с ним долго и счастливо?
                  Постоянная текучка джунов также сказывается и на моральном состоянии постоянных сотрудников: с первым повозятся, со вторым повозятся, третьему уже никто не будет уделять много внимания – всё равно уйдет.
                  Заключать с джуном контракт на минимальный срок — тоже рискованная мера. Хорошо, если человек добросовестный попадется. А если нет?
                    +1
                    Заключайте контракт не по негласному соглашению, а с трудовой. Конечно в этом случае вашей стороне (фирме) придется соблюдать ТК, но ведь и вы сможете на него подать в суд в случае чего.

                    А то получается — «мы его взяли на 5к белой зарплаты, остальное в конвертике, налоги не платим, требуем с него переработок, за которые не платим, а потом обижаемся, что он нас кинул»
                +1
                Про фулстек верно подмечено, только фулстеки обижаются на это.
                  0
                  А откуда браться людям способным спланировать архитектуру в целом, если «каждый спец только в свой области»?
                    0
                    что то полный раздрай, один человек если это проект не личный бложик такие вещи не планирует. Ну невозможно разбираться одному человеку качественно в современном fe и так же качественно в современном be, это все мифы. По верхам можно знать, или очень редкие единороги что автор расписал у которых по 10 лет опыта.
                      +1

                      Пользы от намеренного изучения рядовыми разработчиками fullstack'a нет.


                      • А: неоправданно тяжелее собеседоваться
                      • Б: им не платят больше
                      • В: чаще предлагают работу с просто катастрофической нагрузкой

                      Даже будучи фуллстеком, всегда выгодней искать вакансию Back/Front.
                      Только если лежит душа к позиции руководителя, fullstack как цель обретает смысл.

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

                    Очевидно что он не будет знать в совершенстве ничего из вышеперечисленного, и на конференции блеснуть будет нечем. Но многим заказчикам проще работать так, чем собирать команду. Фулстэк часто означает что человек может поднять веб-сервис целиком, качество этого решения остается за кадром.
                    +1
                    Про фулстеков — не согласен. Архитектор, key developer, или любой другой главный по технике — должен шарить и фронт, и бек. Руководить разработкой, зная только половину его стека — полный бред же. Так что если хочется расти выше мидла — надо как минимум поверхностно разбираться в обоих частях.
                      +2
                      надо как минимум поверхностно разбираться в обоих частях

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

                        0
                        «разбираться» не подразумевает «может выполнять задачи», «разрабатывать»? Пускай на подзадачи по фронту и бэку уйдёт больше времени и(или) они будут решены менее эффективным по вычресурсам способом, но разве разбирающийся человек не способен решать задачи?
                          +1
                          Так-то и абсолютно любой человек может разрабатывать прямо с улицы, но ему потребуется больше времени и качество пострадает =)
                          А если серьезно, да сможет, но в процессе ему придется учиться осваивая инструменты и наступая на грабли нюансов и таким образом превращаясь из «разбирающегося» в разработчика. Кроме того разрабатывать, т.е. выполнять задачи уже подразумевает сроки и качество (критерии за которые платит заказчик). Безусловно четкой границы нет, но все же специалист это в большей степени тот, кто может решить задачу, а на не научится это делать.
                      +2
                      В последние годы этот «зоопарк» уже достигает абсурда — люди начинают выбирать технологии просто потому, что у них больше звездочек на GitHub.

                      На бэкэнде такое творится уже давно.

                      В прошлом году имел печальный опыт работы с одним «Agnostic»-фреймворком для аутентификации (аутентификация «искаропки» для лары не устроила), который выбрали только потому, что…

                      … у него было много «лайков» на гитхабе.

                      То, что у него отвратительная документация, под капотом — дичайший говнокод, а работа с базой неоптмизирована совершенно (чего стоит поиск по varchar(255) без индекса?) — не являлось для техдира аргументом «против».

                      Ведь у него «много лайков на гитхабе!». Это главный аргумент «за».

                      P.S. простите, было больно.
                        0
                        В целом «количество звездочек» и «от него зависят ...» является косвенной метрикой длительности поддержки. Другой обычно просто нет.
                          0
                          «Качество проекта» — интегральная характеристика и формулу качества вывести вряд ли возможно.

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

                          А вовсе не количество «лайков».

                          Ну и конечно, историю закрытия ишью. Если ишью висит с 2013 года и к нему 0 комментариев — вряд ли проект можно считать «поддерживаемым».

                          Банальный пример: мой проект лайкнул какой-то чувак. Я заинтересовался… выяснилось, что он лайкнул каждый мой репозиторий, более того, он лайкает все репозитории подряд. Можно ли после этого считать, что мой репозиторий стал «лучше»?
                        +2
                        Многие боятся, что как только джуниор вырастет, он уйдет.
                        Видел то ли на каком-то форуме, то ли на баше:
                        — А вы не боитесь, что мы сейчас вложимся в джуниоров, они всему научатся, а потом уйдут?
                        — Это не страшно. Страшно, если они ничему не научатся и останутся.
                          –1
                          JS-разработчикам надо понимать, что они должны уметь верстать.


                          JS-разработчикам гораздо важнее быть хорошими программистами. Со всем входящим в этот перечень.
                            0
                            Вот эту часть не понял:
                            … мы в какой-то момент просто уперлись в производительность. Изначально все было написано на нативном JavaScript, но с выходом очередной фичи мы поняли, что дальше развивать продукт на этом ядре мы не можем.

                            Как такое возможно? Может быть есть конкретные примеры? Просто инетересно. Я всегда думал, что «голый» JS всегда будет производительнее и гибче, чем любой фреймворк.
                              0

                              Любое большое жизнеспособное решение на "голом JS" это тоже фреймворк, просто свой. А гибче он и производительнее ли — зависит от обстоятельств.

                                0
                                В популярных фреймворках обычно много усилий прилагают для оптимизаций. Успех React некоторые считают заслугой единственной оптимизации — инкрементный ререндинг DOM для достижения целевого состояния.

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

                              Самое читаемое