JavaScript *

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

Ознакомившись с этой статьей, вы поймете:

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

- как использовать редактор Visual Studio Code, чтобы обойтись без Babel.

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

Работая над своим стартовым шаблоном для Electron приложений я решил полностью отказаться от CommonJS модулей и использовать исключительно ECMAScript модули.

Спойлер: ничего хорошего из этого не вышло.

Проблемы поиска данных всегда отличались особенной сложностью и зачастую нестандартностью в подходах. Сегодня я бы хотел остановиться на одной интересной задаче, которую мне пришлось решать совсем недавно во время разработки платформы Интернета вещей. Впрочем, такая задача, может встретиться и на любом другом проекте, где есть динамическая подгрузка данных по REST API. Будь то подгрузка во время пагинации, или во время скроллинга, или как то иначе…

Одной из самых распространенных задач, которые встречались мне в работе, была динамичная расстановка титров в видеороликах. Видео сегодня, один из самых популярных форматов контента. Одно из ограничений накладываемых браузером, невозможность запустить в ролике звук без действия пользователя. Естественный выход из данной ситуации, заменить звук титрами. Если это 5 - 10 титров, то можно сделать их и руками. Ну, а что, если вам надо выпускать по пять роликов в день и в них не 10, а 50 - 70 титров? Да еще каждый ролик в 2 - 3 форматах. Да, плюс ко всему, еще и на нескольких языках? Если вам кажется такая ситуация необычной, то я сталкиваюсь с ней ежедневно.

Так давайте же упростим эту задачу на сколько это возможно. Мы сделаем более менее универсальный скрипт, который будет интерпретировать текст в титры на сцене After Effects. Хоть я и решал эту задачу уже много раз, буду писать свой скрипт прямо во время написания статьи, чтобы ничего не упустить и сделать свой рассказ максимально подробным. Приступим.

• Выбор комнаты
• Отправка сообщений
• Удаление сообщений отправителем
• Хранение сообщений в локальной базе данных в формате JSON
• Хранение имени и идентификатора пользователя в локальном хранилище браузера (local storage)
• Отображение количества активных пользователей
• Отображение списка пользователей с онлайн-индикатором

Здравствуйте, меня зовут Дмитрий Карловский и раньше я… ежедневно измерял свою пипирку, но у распространённых линеек никак не хватало точности для измерения столь малых размеров.

Поэтому я решил, что хватит это терпеть!… и выстругал свою с нанометровыми делениями, поддержкой прохладного и разгорячённого измерения, тестами, шарингом и прочими вольностями. Так что приглашаю и вас присоединиться к этой спец олимпиаде по измерению скорости своего JS кода.

Для начала разберём этот кейс:

Предпосылки / проблема

При работе над своим проектом вручную создавал стилизованную галерею проектов и понял, что бесконечно плодить громоздкие однотипные HTML-контейнеры – это очень сложный и долгий путь. Захотелось данную задачу автоматизировать и решить более элегантно через JS, описывая каждую картинку как объект на основе класса. Это вторая статья на эту тему, здесь я постарался исправить некоторые ошибки и поработал над логикой и структурой кода. Для удобства добавил возможность просмотра галереи и полного кода в песочнице.

Плюсы такого подхода:

* Более читабельно, чем гора HTML-контейнеров и их содержимого

* Написание одного шаблона впоследствии сэкономит кучу строчек кода и времени

* Короче и удобнее

Приветствую.

Так получилось, что некоторое время назад я принимал участие в проекте, разрабатывал браузерную игру с принципиально новым подходом в хранении данных - предполагалось создать некую вариацию на тему .krieger, игру, которая использовала бы экстремально мало памяти для хранения ресурсов, сохранив при этом высокополигональность моделей, пусть и жертвуя при этом производительностью. Ввиду комплекса причин - проект закрылся, не выпустив даже MVP - но у нас остался серьезный пласт наработок, которыми я, с дозволения остальных участников команды поделюсь тут. Само собой, с авторскими комментариями и рассмотрением идеи. Подробности под катом.

• MDN Web Docs
• «Современный учебник JavaScript» Ильи Кантора
• «Вы не знаете JS» Кайла Симпсона
• «JavaScript. Подробное руководство» Дэвида Флэнагана
• «Learning JavaScript Design Patterns» by Addy Osmani

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

Привет, в этой статье будут рассматриваться легальные способы получить преимущество перед противником с помощью таких простых средств, как NodeJS, Electron и React, при этом обходя бан стороной. На эксперименты меня вдохновила другая статья Визуализация времени возрождения Рошана и желание автоматизировать часть рутины. Стоит заметить что сейчас будут рассматриваться инструменты не модифицирующие каким либо нечестным способом игру - все API открыты, данные получены честным путём, никакого вмешательства в процесс игры не происходит. Под катом будет несколько картинок и немного кода.

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

Я уже показывал Хабру свою разработку, но так как она мало относится к тематике сайта, а исходников я не предоставил, статья не вызвала интерес аудитории.

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

У нас в TeamHood есть wiki. Там собралась коллекция рекомендаций, в том числе, по улучшению производительности тяжелого фронтенда на vue.js. Улучшать производительность понадобилось, потому что в силу специфики наши основные экраны не имеют пагинации. Есть клиенты, у которых на одной kanban/gantt доске больше тысячи вот таких вот карточек, все это должно работать без лагов.

В статье разобрано несколько редко упоминаемых техник из нашей wiki, которые помогут сократить излишний рендеринг компонентов и улучшить производительность.

Недавно наткнулся на это исследование pdf (по его мотивам уже была статья на хабре), после прочтения, решил поискать более интересные способы использования F-Cache. Объективно, схему с редиректами никто в здравом уме не будет ставить на свой сайт. Это утечка, но утечка представляющая больше теоретический интерес, чем практический(имхо).

Обозначил цель(найти способ проверить F-Cache через javascript) и начал поиски. В ходе экспериментов выделил несколько способов это сделать, но опишу самый интересный, на мой взгляд.

Ссылка на чекер под катом.

Предпосылки / проблема

При работе над своим проектом вручную создавал стилизованную галерею проектов и понял, что бесконечно плодить громоздкие однотипные HTML-контейнеры – это очень сложный и долгий путь. Захотелось данную задачу автоматизировать и решить более элегантно через JS, описывая каждую картинку как объект на основе класса.

Плюсы такого подхода:

* Более читабельно, чем гора HTML-контейнеров и их содержимого

* Написание одного шаблона впоследствии сэкономит кучу строчек кода и времени

* Короче и удобнее

• создание и конфигурация проекта,
• assets и static: стили, шрифты, изображения, посты,
• создание компонентов,
• создание страниц и layouts,
• развертывание приложения (деплой).