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

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



Мне не хотелось бы писать материал о том, почему я перешёл с Go на JavaScript, перечисляя минусы Go. Я полагаю, что подобные материалы оторваны от жизни и приносят читателям очень мало пользы. Поэтому я написал материал о том, что мне нравится в JavaScript, о том, что подвигло меня на переход.

Если вы JS-разработчик, то браузер для вас — дом родной, но можете ли вы описать пошагово все действия браузера для отрисовки вашей прекрасной страницы? И вы наверняка уже слышали про WebAssembly, но знаете ли, что «внутри» у этой технологии?



Углубиться в эти и многие другие JS-темы помогут доклады. В ноябре прошла HolyJS 2019 Moscow, а теперь её видеозаписи открыты для всех, и мы традиционно публикуем на Хабре подборку — в общем, есть чем занять выходные на самоизоляции.

Фридайвинг — ныряние на глубину без акваланга. Ныряльщик ощущает на себе закон Архимеда: он вытесняет некоторый объём воды, который выталкивает его обратно. Поэтому первые несколько метров даются тяжелее всего, но потом сила давления толщи воды над тобой начинает помогать двигаться глубже. Этот процесс напоминает изучение и погружение в системы типов TypeScript — по мере погружения становится немного легче. Но надо не забыть вовремя вынырнуть.


Фотография с сайта One Ocean One Breath.

Михаил Башуров (saitonakamura) — Senior Frontend Engineer в компании WiseBits, фанат TypeScript и фридайвер-любитель. Аналогии изучения TypeScript и ныряния на глубину не случайны. Михаил расскажет, что такое discriminated unions, как использовать вывод типов, зачем нужна номинальная совместимость и брендирование. Задержите дыхание и погружайтесь.

В детстве я редко ходил в залы аркадных автоматов, потому что особо в них не нуждался, ведь дома у меня были потрясающие игры для C64… но есть три аркадные игры, на которые у меня всегда находились деньги — Donkey Kong, Dragons Lair и Outrun…

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


Поэтому я решил попробовать написать олдскульную псевдотрёхмерную гоночную игру в стиле Outrun, Pitstop или Pole position. Я не планирую собрать полную и завершённую игру, но мне кажется, будет интересно заново изучить механики, при помощи которых эти игры реализовывали свои трюки. Кривые, холмы, спрайты и ощущение скорости…

Итак, вот мой «проект на выходные», который в итоге занял пять или шесть недель по выходным

• Сыграть в игру
• Посмотреть исходный код

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

Она не отшлифована, немного уродлива, но полностью функциональна. Я покажу, как реализовать её самостоятельно за четыре простых шага.

Можно также поиграть

• в демо с прямой дорогой
• в демо с кривыми
• в демо с холмами
• в готовую версию

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

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

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

• Загрузка файла по сети.
• Парсинг и компиляция распакованного исходного кода после загрузки.
• Выполнение JavaScript-кода.
• Потребление памяти.

Эта комбинация оказывается очень дорогой.



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

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

Выяснить это мне помог проект HTTP Archive.

Для телеграма разработали SIP-коннектор (@siptg). Voximplant – это платформа телефонии. Правильно, они могут прекрасно работать в паре и сегодня мы покажем, как. Добро пожаловать под кат!

Привет. Сегодня покажу вам цветовую схему, которой пользуюсь последние 2 года. Она была придумана, чтобы на проблемном проекте избавиться от огромного количества переменных в CSS. А потом оказалось, что эти принципы можно применить почти к любому проекту.

В общем, попробую объяснить, как дизайнеры используют цвет в UI и как всё это можно «типизировать», не вгоняя дизайнеров в жёсткие рамки. Приведу примеры реализации на React JS (для разработчика) и в Figma (для дизайнера). Привязки к React и Figma у схемы нет, просто мне в них привычнее.

В схеме нет ничего хитрого и уникального (может, только название). Все идеи висят в воздухе. Можно воспринимать её как мой best practice по работе с цветом в приложениях. Opium.Fill — это общие принципы, совмещённые с любовью давать всему подряд имена.

Систему можно использовать совместно с Material Design.

Статья написана для front-end разработчика и немного для дизайнера.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Если вы пользуетесь блокировщиками рекламы, то могли встречать BlockAdBlock. Этот скрипт обнаруживает ваш блокировщик и не пускает на сайт, пока вы его не отключите. Но мне стало интересно, как он работает. Как антиблокировщик обнаруживает блокировщики? А как на это реагируют блокировщики и как они блокируют антиблокировщики?

История реверс-инжиниринга

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

Это натолкнуло меня на мысль о версиях. А что, если мог посмотреть не на одну версию, а на все сразу? Так я и сделал. Я вернулся назад во времени с помощью Wayback Machine. После этого скачал все версии BlockAdBlock и хэшировал их.

В этой статье хотел бы рассказать немного про библиотеку, первую версию которой я создал еще в конце прошлого года. Суть очень простая — расширить возможности языка HTML, чтобы можно было без JavaScript'а писать простые и рутинные вещи: отправка формы в json формате, загрузка HTML тимплейтов на определенную страницу(по сути модульная система для HTML через http/s запросы), турболинки(привет пользователям RoR), простая шаблонизация на основе ответов ajax запросов и немного еще.

Библиотека называется EHTML или Extended HTML. Основана она на небезызвестной идее веб компонентов. Она доступна на гитхабе, там довольно таки структурированная документация с примерами. В этой статье я просто опишу основные идеи, возможно кому-то это зайдет.

Когда на днях в наш уютный чатик @sveltejs в телеграм запостили ссылку на очередную «разоблачающую» статью про Svelte, я очень обрадовался, предвосхищая интересный технический батл или хотя бы увлекательное чтиво чужого практического опыта. Кроме того, что это всегда интересно и полезно, определенное стечение обстоятельств — плановый отпуск и карантин — заставляют меня скучать дома, а подобная статья могла бы несколько разнообразить мой день. Каково же было мое разочарование, вы даже представить себе не можете… но давайте по делу.

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

Всем привет! Меня зовут Артур, я работаю frontend-разработчиком в Exness. Не так давно мы перевели один из наших проектов на веб-компоненты. Расскажу, с какими проблемами пришлось столкнуться, и о том, как многие концепции, к которым мы привыкли при работе с фреймворками, легко перекладываются на веб-компоненты.

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

Когда я вижу очередную статью о Svelte:

RE: Боль и слёзы в Svelte 3
Svelte 3: Переосмысление реактивности
Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков
Легенда о Фреймворке Всевластия
Re: «Сравнение JS-фреймворков: React, Vue и Hyperapp»
Исчезающие фреймворки

Меня переполняет восхищение от наглости писавших её. С серьёзнейшим видом эти люди приходят и начинают рассказывать что их фреймворк в принципе может рассматриваться как альтернатива большой тройке: Angular, React, Vue. Первый раз я подумал, что автор из-за своей неопытности на полном серьёзе рассматривает Svelte как вменяемую production-ready альтернативу устоявшимся фреймворкам. Второй раз я подумал, что автор испытывает творческий кризис и его так тошнит от большой тройки, что ему хочется писать на чём угодно, но только не на ней. В последующие разы меня преследовало чувство, что кто-то просто строчит заказные посты.

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

Привет, Хабр! В не такие уж далёкие годы, на первом курсе «программистского» факультета, мне нравилось задавать товарищам по учёбе вопрос: «Зачем вы вообще пошли сюда учиться?» Точной статистики ответов я, конечно, не вёл, но доподлинно помню: больше половины хотели делать игры. Большинство тех, кто так отвечал, оказались не готовы к обилию разных видов «математик» и «физик», которыми нас завалили в первые два года учёбы. Выдерживали не все — уже к концу второго курса из пяти переполненных групп осталось три неполных.

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

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

Привет, Хабр! Завтра, 23 апреля, PiterJS проведёт онлайн-митап — а мы (организаторы HolyJS) поможем им с технической частью трансляции.

На митапе поговорим про разработку сложных UI-компонентов, производительность и CSS-in-TS со спикерами из Lamoda, SEMrush и 1С.

Когда: 23 апреля, 19:00–21:30
Где: YouTube-канал PiterJS

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

Сегодня поговорим об измерении производительности рендеринга React-компонентов с использованием API React Profiler. Ещё мы будем оценивать взаимодействия с компонентом, применяя новый экспериментальный API Interaction Tracing. Кроме того, мы воспользуемся API User Timing для проведения собственных измерений.

В качестве площадки для экспериментов воспользуемся приложением React Movies Queue.

Приложение React Movies Queue

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.