#фронтенд

5 постов
пост №1846Разработка и инженерия

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

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

Технически сейчас это программа на C#, которая в одну сторону торчит админкой для редакции, а в сторону читателей генерирует HTML-страницы сайта. Это популярный сетап из 2000-х. Техническую задачу я формулирую как облегчение процесса разработки без потери производительности сайта.

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

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

Но будет ли современное веб-приложение (SPA) так же производительно, как HTML-страницы из 90-х? Речь и о скорости первого открытия — можно ли загрузить JS после полной отрисовки страницы? — и о скорости перехода между страницами — быстрее ли JavaScript-логика, чем отдать готовый HTML с сервера?

Можно ли получить лучшее из обоих миров? На какие компромиссы придётся пойти?

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

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

P. S. Один из разработчиков McMaster пишет, что под капотом там VB.NET, хранимки и XSL-трансформации поверх XML для генерации веб-страниц. Хочется вот всё то же самое, только без VB, хранимок и XSLT. 🙈

пост №1558Разработка и инженерия

Наш ведущий фронтендер Миша Бурмистров сделал чеклист по веб-безопасности для фронтенд-разработчиков компании.

Хвастаюсь!

Опубликую ещё первый комментарий Миши к этому посту (не видны публично):

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

А чтобы почитать остальные комментарии — придется устроиться к нам на работу :)

Признаюсь, я и сам не знаю некоторых аббревиатур 🙈

Разработчики, которые думают о безопасности — единственный способ делать безопасные приложения. Никакие отделы безопасности не спасут, если разработчикам пофиг. Так же, как и с тестированием — о качестве должны думать все разработчики, а не только «специалисты»!

В общем, горжусь и хвастаюсь!

пост №916Интернет и платформы

Космическая история: фронтендеры Ютуба убили Internet Explorer 6, без согласования с руководством разместив баннер «мы скоро перестанем поддерживать этот браузер, поставьте что-нибудь посвежее» в июле 2009.

Чтобы вы понимали контекст, в июле 2009 года это был браузер четверти пользователей интернета. IE6 было уже 8 лет, он глючил, тормозил и решительно не подходил для современного интернета 2009го, но ни один крупный сайт не был готов сказать четверти пользователей интернета «сорян, ваш браузер — говно».

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

В 2009, IE6 ненавидили уже все фронтендеры без исключения. Практически сразу после запуска баннера на Youtube, фронтендеры Google Docs использовали пример Ютуб как обоснование для того, чтобы выкатить такой же баннер на Google Docs (все думали, «вряд ли Ютуб провернул такое без соответствующих согласований»). Иронично, но когда о баннере узнали в руководстве ютуба, они решили, что это просто копия баннера с Google Drive («и кто-то наверняка согласовал это ранее»).

Когда правда вскрылась — было уже поздно, баннер был практически на всех сайтах в интернете, а IE6 —обречен. Цель оправдывает средства.

Рассказывает один из участников заговора (там есть, как отреагировали юристы и PR-щики). 💎

пост №713Работа и карьера

Rawg.io ищет третьего фронтенд-разработчика. Ключевые слова: React, микрокоманды, Remote.

Мы делаем лучший сайт про видеоигры; у нас есть IMDb-часть со страницами игр и социальная часть, где можно собирать коллекции, писать обзоры и подписываться на похожих игроков. В ближайших планах дать возможность редактировать страницы игр обычным игрокам прямо на сайте (сейчас используется внутренняя админка) и прокачать SEO.

Под капотом это респонсив SPA React приложение с SSR. JS потребляет красивое REST API, которое готовится бэкендерами на Python (Django DRF) специально для сайта.

Мы работаем по модели Basecamp: в начале 2-4 недельного «цикла» микро-команда — фронт + бэк и дизайнер получают хорошо сформулированную бизнес-задачу с примерными макетами, а дальше мы минимально дергаем команду разработки, чтобы не отвлекать и не мешать. Коммуникация происходит в Basecamp и немного в Slack, все Remote.

Codebase свежий (первый коммит два года назад) и написан хорошими разработчиками, жесткого легаси или костылей там, пока, нет. Github, ci, рабочее окружение разворачивается одной npm-командой. Подключен линтер, в проекте настроен webpack, начали писать тесты, используется связка Redux + Recompose. Верстка: stylus, flexbox, css grids, bem. Дизайнеры и даже продакт раньше верстали, так что понимают ценность переиспользования компонент и естественные ограничения веба.

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

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

Пишите на frontend@rawg.io или @samatg в личку.