Що таке сучасний Front-end і як він зміниться у майбутньому. Дискусія на DOU
Днями ми зібрались на YouTube-каналі DOU і поговорили про Front-end з Андрієм Лісточкіним, Юрієм Артюхом та Юрою Федоренком. А тепер публікуємо короткі тези розмови. Та ви завжди можете обрати: слухати повний запис чи прочитати текст.
І не забудьте підписатись на YouTube-канал DOU!
Що таке Front-end
Побутує думка, що можна розділити Front-end на front of the front-end i back of the front-end. Тобто на тих, хто займається версткою, анімаціями, дизайном, доступністю сайтів, і тих, хто пише бізнес-логіку, більше працює з фреймворками, але не має великого досвіду у верстці. Чи погоджуєтесь ви з таким розподілом? Чи варто розділяти Front-end, щоб компанії, наприклад, могли прицільніше наймати спеціалістів на позиції, а спеціалісти могли розвиватися в більш чіткому векторі? (02:17)
Андрій Лісточкін: Многое зависит от размеров компании, команды, проекта. Легко быть узким специалистом, когда вокруг люди, которые могут закрыть другие ниши. Вот аналогия с бэкендом: есть много людей, которые плохо умеют пользоваться SQL, есть много людей, которые не очень умеют делать запросы в базы данных или разбираться с проблемами скорости этих запросов.
То есть в небольшой команде, где есть
Юрій Артюх: В наше время часто один человек делает верстку, а другой — бизнес-логику. Мне это нравится, потому что это способ предоставить результат быстрее. Ведь тяжелее будет найти на проекте того, кто будет делать это всё вместе. Это будет стоить дороже. Как СТО, я понимаю, что дешевле и проще найти двух людей: один сделает все на React, а второй займется вёрсткой. И вместе это будет быстрее и эффективнее, чем искать по отдельности.
Юра Федоренко: Мне кажется, такое разделение проявилось лет 10 назад, когда на рынке возник дефицит фронтендщиков и начали появляться свитчеры: логику написать я ещё могу, а как сделать так, чтобы оно не расползлось в Internet Explorer, не знаю. Но я, наверное, слишком молод, чтобы знать это точно.
Нравится ли это мне? Не очень, мне кажется, что Front-end при том, что он становится всё больше, обширнее, сложнее, может помещаться в голову одному человеку.
Конструктор сайту — загроза для верстальника?
Чи не бачите ви у візуальних конструкторах сайтів типу Wix, Tilda загрозу для професії фронтендера-верстальника? (07:57)
Юрій Артюх: Я начал верстать в
Но верстка была востребована 17 лет, значит так будет и завтра. Конструктор — это совершенно не угроза, скорее дополнение. Профессия трансформируется: появились люди, которые делают сайты на Tilda, Wix, теперь фронтенд ещё и такими специализациями богат. Но верстальщики все равно остались и не менее востребованы.
Андрій Лісточкін: В принципе, нет какой-то проблемы в том, что появляются новые инструменты. Они делают нас более продуктивными.
Юра Федоренко: Это действительно помогает, меньше приходится делать эти бесконечные маркетинговые лендинги. С другой стороны, это повышает порог входа в профессию. Потому что если раньше было много работы, например сделать простенькую страничку, то сейчас её становится меньше и нужно уметь ещё что-то. Но это в целом в программировании так.
Про бар’єр входження в професію
Як впоратися з високим бар’єром входження в професію і чи справді він такий високий? (10:50)
Юра Федоренко: Когда-то я преподавал на курсах фронтенда, и у меня в презентации был слайд с одной надписью сверху «Порог входа», то есть он был пустой, мол настолько низкий, что ниже экрана.. Я говорил: ты только создал HTML-файл — и вот уже практически на работе.
Но порог входа повышается. Я смотрю на список всего, что надо знать Junior, и мне становится страшно. Думаю, меня бы не взяли в своё время. Правда, изучить это сейчас намного проще, чем раньше.
Юрій Артюх: Начинающие переживают, что перед ними какой-то высокий порог, а у меня ощущение, что я застыл в бесконечной позе преодоления этого порога, потому что фронтенд развивается постоянно. Сейчас я сконцентрировался на WebGL и анимациях, и даже здесь постоянно требуется столько новых знаний, что я как будто бы всё время преодолеваю этот порог. И поэтому нужно смириться, что надо бесконечно учиться.
Андрій Лісточкін: Хочется посоветовать всем принять тот факт, что вы не будете никогда знать всё. Количество вашего незнания будет только расти. То есть нужно не только не бояться того, что ты чего-то не знаешь, но уметь работать в условиях, когда ты чего-то не знаешь.
Со временем приходит больше понимания, опыта, интуиции о том, как инструмент должен работать. Потому что этот инструмент появился не на пустом месте, это наследие эволюций других инструментов.
И да, вначале кажется страшно, но, например, если вы изучаете, как работать в web-фомах, можно сперва не обращать внимания на анимацию. Потом, когда занимаешься анимацией, уже имея понимание, как работают формы, как нарисовать поле красиво, нужно учиться тому, чтобы поле красиво выезжало. В каждый момент твой когнитивный load — это небольшая доля общих знаний, которые нужны.
А що там PWA?
Чи помер Progressive Web Application? (15:50)
Андрій Лісточкін: У меня на этот счет есть нестандартное мнение. Progressive Web Application пушится Google как альтернативный способ создания приложений на телефонах. И одна из причин — у Google нет хорошего АРI для Android.
У меня ощущение, что много команд внутри Google просто пытаются создать свое решение, как делать приложение на Android. У одних получается одно, у других — другое, но все они независимо пушат свои решения. И во многом успех Progressive Web Applications говорит не о том, что команда, которая занимается PWA в Google, лучше знает, как делать мобильные АРI, а что Google удобно иметь свое решение. И на фоне сложных АРI Android оказывается, что делать что-то на Web проще.
Но я не согласен с тем, что браузер должен иметь уникальный доступ к каким-то частям моего устройства. Слова о том, что веб-приложение безопасно — не правдоподобны, и я не уверен, что PWA — хорошая идея. Я очень рад, что iOS, Safari, Apple не торопятся вводить какие-то АРI, потому что есть подозрение, что это плохая идея.
Я не против, чтобы АРI стандартизировались, появлялись дополнительные гарантии безопасности, но по умолчанию лезть из браузера в serial-порт и подключать к нему ЕКГ-устройство или какой-нибудь другой медицинский прибор — не лучшее решение.
Юра Федоренко: Мне кажется, что нет никаких проблем с АРI в Android — это раз, и думаю, что Progressive Web Application продвигают для другого: легковесных, простых приложений, которые дёшево поставить и которые будут неплохо работать и покрывать много юзкейсов.
Мне нравится, что теоретически на десктопе можно выбирать браузер, которым это всё будет рендерить.
Мы видим, что платформодержатели саботируют эту идею. Apple и iOS не очень любят пускать сторонних разработчиков на свою платформу, но все равно пускают, контролируют, хотят модерировать содержание AppStore. Это скорее плохо, но Google я не считаю рыцарем на белом коне, потому что компания следует своим интересам и хочет контролировать среду.
Андрій Лісточкін: Думаю, что если Apple внедрит буквально одну АРI, а именно делать Push notifications из браузера, то большая часть людей, которые гласят, что PWA не сильно развиты, просто замолчат, потому что только из-за Web Push-ей все и вякают, откровенно говоря. Это звучит цинично, но иметь возможность пушить что-то пользователю — это святой Грааль вовлеченности для маркетологов. И все хотят именно вот этого: Push notification.
Юра Федоренко: Ты ещё говорил о security-причинах, из-за которых хорошо, что PWA не взлетает. Мне кажется, что с security в PWA всё было бы лучше, потому что это открытый стандарт и там бы это рано или поздно вычистили. И в браузерах, может, не идеально, но лучше, чем на нативных платформах.
И Apple, конечно, тут «все в белом», но если помониторить трафик, то оказывается, что сама по себе iOS около 10 мегабайт в час да шлёт какой-то инфы куда-то.
Андрій Лісточкін: Речь не столько о том, что кто-то кому-то что-то шлёт, а больше о том, что АРI используются только для таргетинга и фингерпринтинга. Нам достаточно таких АРI.
Думаю, хорошее PWA можно завернуть в WebView, сделать какой-то bridge с нативными приложениями и создать обёртку, которая будет повторять Web АРI для Web на IOS.
Юра Федоренко: С коммерческой точки зрения количество клиентов, которые хотят сделать PWA, минимальное и стремится к нулю.
Юрій Артюх:
Мне это напоминает технологию микроформатов. Мертва ли она, непонятно. Это была прикольная технология, дополнительные разметки в HTML разных данных типа отзывов, адресов и так далее, чтобы можно было как-то лучше их индексировать. И вроде бы она до сих пор доступна и действительно помогла бы проиндексировать кучу информацию, но она не сильно нужна. Может быть, и PWA не так сильно нужен. Это брешь между нативными приложениями и сайтами, возможно, она не такая привлекательная, чтобы туда вливать деньги и делать приложение.
Тот факт, что приложение нужно паблишить в App Store, это, с одной стороны, баг, а с другой — фича, потому что пользователи за 10 с лишним лет привыкли к тому, что приложение находится там. Они идут App Store и там его ищут. Даже мысли не возникает пойти на сайт и там нажать какую-то кнопку. И мне кажется, что вот этот канал из серии «Давайте покажем пользователю какую-то ссылку на загрузку приложения» не такой действенный, как канал людей, которые заходят и ищут сами.
Я боюсь, что Apple не пускает не только из-за того, что не хочет потерять контроль, а потому что боится, что приложения на
Про мікрофронтенд
Чи має мікрофронтенд право на життя? Чи ви використовували? І чи бачите за цим підходом майбутнє? (30:23)
Андрій Лісточкін: Предположим, у нас есть приложение и нужно обновить какой-то кусок. Например, мы решили сменить технологию или этот кусок пишет другая команда с другим стеком. Эта проблема существует с незапамятных времен, решений есть много. Можно из порталов собрать какую-то страницу, и она будет вести себя почти как iFrame. Но в результате это будет не iFrame, а одна страница, которая собиралась из разных сервисов.
То есть микрофронтенд — очередной виток этого движения: а зачем мы делаем большие приложения? Давайте попробуем сделать много маленьких. Я не особенно верю в микрофронтенд в рамках одного проекта, одной команды. Мне кажется, это ерунда полнейшая: лишние административные нагрузки.
У нас сейчас не микрофронтенд, а макрофронтенд: есть большое приложение, внутри него — два больших куска. И они одновременно деплоятся, но в рамках одного условного приложения. Просто физически на диске файлы расположены в разных местах, и что-то выделено в общие компоненты.
Юрій Артюх: В тех проектах, с которыми я имею дело, микрофронтенд не используется. Но я также понимаю, что это один из способов решения проблемы, которым люди пользовались давно. Сейчас это называется микрофронтенд, мы можем об этом говорить, раньше это была просто проблема в большом проекте, которую кто-то решал.
Розвиток фронтенд-розробника
Реалії ринку
Чи є якийсь roadmap навчання для новачка, адаптований під наші реалії? (36:57)
Андрій Лісточкін: У нас очень большой процент вакансий для новичков, который не предполагает широкого спектра ответственности. Почему существуют такие узкие специализации? Потому что специализации можно небольшими порциями продавать заказчику. То есть если у вас бизнес построен на аутсорсе, то вам нужно 5 красных шаров, 7 синих и 8 белых.
И это не только о больших проектах. Может быть, вам нужен синий шар на две недели, а в остальное время он находится в другом проекте. Для маленьких проектов это тоже может работать, хотя не так эффективно, как для больших. Но далеко не каждый маленький проект может позволить себе нанимать джуниор-разработчиков. Ведь, чтобы выращивать разработчика, должны быть какие-то мощности. И в таких условиях часто бывает, что узкая специализация позволит тебе, с одной стороны, сфокусироваться на изучении чего-то одного, а с другой — быстро дойти до состояния, когда можешь сделать что-то полезное для проекта.
Юрій Артюх: Говоря о наших реалиях: в силу большого рынка аутсорсеров в большинстве Junior-вакансий уже что-то требуют от человека. Если раньше вакансии были для реально Junior-специалиста, который после курсов, то теперь это уже какой-то разработчик, который должен что-то знать и уметь.
Знання Back-end
Як ви вважаєте, чи потрібні фронтенд-розробнику знання Back-end і наскільки глибокі? Чи краще не змішувати сфери відповідальності? (39:39)
Андрій Лісточкін: Если ты находишься в тесном контакте с заказчиком, то способность сделать задачу в одиночку и целиком — это жирный плюс. С другой стороны, если коммуникация опосредованная, план и условия работы будут меняться редко, то можно вести работу с командой более автономно. Тогда команда чаще предоставлена самой себе и не дёргает продуктового менеджера по пустякам. В этом случае команде выгоднее иметь нескольких узких специалистов, которые быстро сделают свою часть и потом соединят это вместе. Поэтому я вижу место и для фулстек-специалистов, и для узких специалистов.
Юра Федоренко: Теоретически можно делать неплохо и фронтенд, и бэкенд, особенно если на одном и том же языке типа JavaScript. На практике я не видел людей, которые были бы гармонично развиты в этих двух направлениях. Мне кажется, что человека всегда сносит в какую-то одну сторону больше.
Юрій Артюх: Для фронтендера критически важно понимать работу бэкенда, потому что это дает возможность более эффективно взаимодействовать. Но прямо писать бэкенд...
Если говорить о стартапе или продукте, то там нужны люди, которые могут сделать всё: закрыть задачу, понять её в целом, выбрать технологию и так далее. В аутсорсе тебе в любом случае найдется место, потому что тут 100 проектов и в каком-то из них точно нужна именно твоя специализация.
Патерни і алгоритми
Наскільки важливо знати патерни і алгоритми? (45:22)
Андрій Лісточкін: Знания на уровне «это сложно, а это, наверное, может тормозить, давайте мы напишем по-другому» — нужны, а доскональные знания — что такое CRDT или что-то в этом роде — не особо.
Многие алгоритмы типа обход графов, обход деревьев к фронтенду очень даже применимы, потому что HTML — это дерево, DOM — это граф.
Юра Федоренко: Сейчас это не так важно, потому что это мало спрашивают на собеседованиях, ведь есть куча всего другого, что нужно спросить. Процитирую сообщение от моего коллеги Саши Ковпашко из нашего внутреннего рабочего чата: «Після сьогодні я знаю, що відповідати, коли мене питають, нащо на фронті знати складність алгоритмів. Якщо в Google-диску зайти в папку с кількома сотнями файлів і натиснути Ctrl+А, то вкладка зависне секунд на 20, а потім ще настільки ж, коли захочете виділити тільки один елемент».
Юрій Артюх: В шахматах есть много теории, это то, что мы назвали бы паттернами и алгоритмами. И все знают, что вот этот ход приводит к поражению, а этот — к победе. Можешь ли ты играть в шахматы, не зная этого? Можешь, просто чуть хуже. Так же и в разработке: базу надо знать, потому что это опыт поколений, который накоплен и сэкономит время. Сможешь ли ты работать без этого? Сможешь, просто медленнее и не так эффективно.
Тренди дизайну
Які тренди зараз є в дизайні тренди і хто їх задає? Яким ви віддаєте перевагу? (48:46)
Юра Федоренко: Каких-то явных переходов, как было раньше, когда все отказались от скевоморфизма и начали делать плоско, нет. Плоскость тоже становится сложнее, чем раньше. Сейчас мы хотим, чтобы что-то снизу просвечивалось, размывалось и так далее. И есть еще вопрос о том, нужно ли фронтендщику знать дизайн. Я лично его не знаю, но при этом у меня есть коллеги, которые могут подизайнить.
Андрій Лісточкін: Ключевое слово — «смешивание». Мобильные дизайны приходят на десктоп, какие-то десктопные элементы дизайна возвращаются на телефоны, планшеты и так далее. И общий язык еще не устоялся.
Есть ощущение, что в какой-то момент мы придем к тому, что будет визуальный язык, который будет понятен всем и везде. Сейчас переход от Windows к MacOS или наоборот — болезненный. Вроде бы тут шестерёнки для сеттингов и там шестерёнки для сеттингов, но шаг вправо, шаг влево — и есть какие-то мелочи, которые дезориентируют.
Мне кажется, мы уходим от системных дизайнов и приходим к тому, что у нас просто есть визуальный язык отдельных приложений. То есть Facebook выглядит вот так, а Google выглядит вот так.
Сложность современного дизайна — отличиться. Ты не можешь просто взять и сделать синие кнопки и белый фон. В теории можешь, но ты будешь похож на 100500 других продуктов на рынке. Может быть, тебе и надо быть похожим, чтобы у всех было ощущение знакомости. Но в целом большой вызов для дизайнеров сегодня — это сделать дизайн своего продукта таким, чтобы, с одной стороны, он не контрастировал сильно с дизайном каких-то операционных систем, браузеров, а с другой стороны, был уникальным для этого продукта.
Мобільна розробка
Чи є сенс фронтенд-розробнику час від часу займатися мобільною розробкою, чи краще повністю туди перейти? (54:49)
Юрій Артюх: Я руководствуюсь таким принципом: делаю то, что мне нравится. Если мне нравится WebGL, я это делаю. Если человеку нравится создавать мобильное приложение больше, чем писать код для JavaScript, пусть этим и занимается. На данном этапе развития индустрии любовь к профессии принесёт больше денег, чем то, что ты пытаешься выбрать исходя из того, что должно принести больше денег. Нужно делать то, что тебе приносит кайф, тогда за этим придёт всё остальное.
Юра Федоренко: До мобильной разработки начали доходить идеи реактивно-компонентных подходов, очень интересно за этим наблюдать.
Андрій Лісточкін: Сейчас мы приходим к тому, что мобильные клиенты становятся именно клиентами. Есть очень много мобильной разработки, но мы не создаем полноценных приложений, мы делаем какие-то окошки для того, чтобы «достучаться до большого мира». Сейчас ожидания от любого приложения — что оно просто будет работать на телефоне: если я открыл JIRA на телефоне, то JIRA должна работать.
Чтобы писать под телефон, необязательно бросаться в мобильные платформы, потому что в вашей работе фронтендера явно будут задачи типа «на телефоне это плохо выглядит/работает» или «на телефоне это нужно вообще как-то передумать и переизобрести». То есть для того, чтобы почувствовать сложность работы с мобильными устройствами, необязательно бросать любимый веб.
Что есть у Web и чего нет у многих мобильных платформ — это отдельный язык для визуального дизайна типа CSS (именно >Cascading< styles) для HTML. Можно декларативно описать, как АРI должен выглядеть, и он будет адаптивным: на большом экране, на маленьком, горизонтальном и вертикальном, неважно. И многим нативным платформам этого не хватает. А успех React Native или Flutter во многом обусловлен тем, что, кроме реактивности, они приносят такой визуальный язык, который бы позволил описывать приложение не в терминах пикселей, а в терминах адаптивной верстки.
Фриланс
Які переваги та недоліки фрилансу для верстальника або фронтендера? Що, на вашу думку, краще: компанія чи фриланс? (1:09:27)
Андрій Лісточкін: И компания, и фриланс — это способ делать что-то практическое, поэтому и то и другое работает. Сегодня разница немного сглаживается, потому что многие компании работают удаленно. Поэтому этот эффект «я пришёл в офис, и мне тут кто-то поможет» или, наоборот, «они увидят, как я плохо работаю или что я трачу на задачу слишком много времени» — исчезает.
Если вы не очень опытный, то лучше работать в паре или в команде с кем-то более опытным. Неопытному человеку делать что-то с нуля в одиночку сложно. Можно оценить задачу, например, в две недели, а окажется, что нужно четыре месяца.
Юра Федоренко: Педагогика гласит, что знания, которые мы применяем в повседневной жизни, дольше остаются в голове. Была когда-то история про девушку, которая делала 300 сайтов за год: каждый день — маленький web-проект. Это же тоже способ, как быстро прокачаться, придумать себе какие-то задания, чтобы использовать побольше знаний.
Юрій Артюх: Лучший способ чему-то научиться — делать что-то. Пока ты будешь читать про градиенты, ты их узнаешь, но это будут пассивные знания. Они станут активными, когда попытаешься сделать какой-то проект. И благодаря таким проектам, когда будешь искать заказы, тебе как фрилансеру будет что показать. Также если ты будешь вести блог, добавлять статьи, пока учишься, то ты найдёшь себе клиентов.
Я в 2003 году начал учить вёрстку, и мне хотелось делиться с кем-то этими знаниями. Я завел блог. Таким образом стал фрилансером, потому что кто-то нашел мой блог.
Про сертифікації
Чи потрібні сертифікації для фронтенд-розробника? (1:17:01)
Юра Федоренко: Во фронтенде, насколько я видел и знаю, сертификации не особо популярны. И точно я не смотрю на какие-то сертификаты, когда нанимаю людей.
Юрій Артюх: Лет 12 назад были тесты по CSS. Нужно было ответить на
Андрій Лісточкін: В своё время был потрясающий сайт для Java-разработчиков, который назвался Java Black Belt, там можно было получить чёрный пояс по Java.
Сертификация нужна, когда, например, приходишь к официальному партнеру Oracle и заказываешь проект, где используется база данных Oracle, и получаешь её со скидкой. В этом случае для того, чтобы показать, что компания умеет работать с продуктом, она проходит сертификацию.
Как понять, что человек хороший, если ты с ним ещё не работал? Можно провести собеседования, технический аудит.
TypeScript
Що можете сказати про TypeScript? Негативні сторони, недоліки? (1:28:39)
Андрій Лісточкін: TypeScript — это хороший, приятный инструмент, который позволил мне легче ориентироваться по коду. Этот язык скорее gradual typing. То есть типы нужно добавлять там, где они нужны. И не надо беспокоиться о том, что если у нас нет типов, то значит, наше приложение развалится. Потому что есть куча приложений, которые пишутся на обычном JavaScript без типов, и ничего не разваливается, у всех всё работает. Так что не пользуйтесь, если вам не нравится, нравится — пользуйтесь.
Юрій Артюх: TypeScript — прекрасная технология. Есть ощущение, что она становится стандартом в индустрии для написания серьёзных приложений. И у меня только позитивные впечатления. Я был на проектах, в которых возникали проблемы с JavaScript из-за того, что там были очень сложные ESLint правила.
Rust і WebAssembly
Що ви думаєте про Rust? Які перспективи у цієї мови? (1:31:38)
Андрій Лісточкін: Это явно ко мне, потому что я периодически организовываю митапы по Rust. В 2017 году даже сделал в Киеве конференцию на эту тему. Это хороший, интересный язык, который требует большого инвестирования времени, чтобы на нём хорошо писать. Если до этого вы, например, изучали JavaScript, Python, PHP, Java, то для Rust нужно много времени, чтобы овладеть языком. Если сегодня изучаете тот же TypeScript и вам прям сильно тяжело, то Rust вам покажется еще более сложным языком.
Но люди, которым этот язык очень интересен, будут иметь проекты на Rust. Сегодня у языка уже есть история, поэтому порог входа становится чуть выше, чем раньше.
Язык низкоуровневый, а это значит, что если вам не нужны фичи, связанные с производительностью, управлением памяти, то брать Rust неоправданно. Но одновременно с этим есть UI-фреймворки. Пишешь код на Rust, он компилируется в WebAssembly, и результат выполнения транслируется обратно и рендерится как React. Это требует какого-то времени и затрат ресурсов. Писать на Rust с точки зрения производительности софта, а не с точки зрения производительности программиста — не очень просто. Но это хороший вариант для тех, кто пишет бекенды на Rust, чтобы быстренько наваять какой-то фронтенд.
Почти весь код в блокчейне пишется на Rust. Но во фронтенд он не прорвался, и нужно просто внимательно следить за технологией, которая называется WebAssembly. Потому что она позволяет писать работающий код, но интегрироваться с внешним миром (JavaScript, HTML, CSS) будет всё ещё сложно. Но я думаю, года через два всё будет гораздо легче. Поэтому в свободное время я бы его учил, ведь с точки зрения количества нового в дизайне языков программирования этот самый интересный.
Нет, через год фронтенд не перейдёт на Rust. Этого не будет никогда, ведь для большей части задач фронтенда есть JavaScript.
Юрій Артюх: Именно в контексте WebAssembly может быть очень хорошое применение Rust, потому что в сфере WebGL в тренде анимация, а она связана с распознаванием лиц, поверхностей, здесь присутствует дополненная реальность, где происходят большие вычисления. Поэтому WebAssembly очень сильно спасает.
Майбутнє Front-end
Як зміниться фронтенд через 5 років? До чого готуватися? Які тренди прогнозують? (1:40:56)
Юрій Артюх: В контексте вёрстки CSS сильно развивается. В твиттере я читаю очень многих, кто занимается развитием CSS и удивляюсь, что уже сделали спецификацию для Nested-селекторов. Если раньше об этом просто говорили как о фантазии, то сейчас уже обсуждают применение и реализацию в браузере Nested-селекторов.
Мне кажется, что CSS остается важным игроком. Также Web сильно развивается и наверняка будет это делать ближайшие 5 лет.
Андрій Лісточкін: Произошел большой скачок в сторону утяжеления страниц, хоть и говорят о том, что они должны становится легче. Мне кажется, это удастся сделать, потому что появляются инструменты, которые реактивно апгрейдят бэкенд декларативными способами. Это значит, что код писать или не нужно, или нужно писать очень мало: повесил на теги, дал атрибуты, сложил магический скрипт — и твой back-end умеет отдавать фрагменты вместо того, чтобы заниматься виртуальным тесплейтингом, который жрёт ресурсы.
Микрофронтенд с одной стороны, а с другой — желание уйти от больших фреймворков приведет к тому, что фронтенд пять лет спустя будет выглядеть как отдельные большие куски на больших фреймворках, а вокруг них так же, как вокруг большого монолита, появлятся микрофронтенды, куски, сделаные на чём-то более легком.
Хочу добавить, что Web-компоненты не победили и не победят, к сожалению. Потому что у больших фреймворков нет стимула создавать веб-компоненты, они делают своё АРІ, которое лучше интегрируется в тот движок, который у этих фреймворках уже есть.
Юра Федоренко: Я жду, что в ближайшие пять лет выстрелит Houdini — возможность описывать рендеринг. Нас ждет улучшение вебов: понаписывают скруглений для уголочков на кривых второго порядка и так делее. Это будет не в ущерб семантике и девелопер-экспириенсу. И можно будет делать более сложные графические штуки.
Запрошуємо на вебінар DOU #3 про тестування 20 квітня о 19:00.
