JavaScript *

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

Так получилось, что некоторое время назад я принимал участие в проекте, разрабатывал браузерную игру с принципиально новым подходом в хранении данных - предполагалось создать некую вариацию на тему .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,
• развертывание приложения (деплой).

Привет, Хабр!

Хотим поделиться краткой историей о том, как мы на одном из проектов «Рексофт» пришли к написанию автотестов, и почему сделали акцент именно на e2e-тестах.

Подумайте о предварительно сконфигурированном dev-сервере + сборщик, но более компактном и быстром. Он использует встроенную в браузер поддержку ES модулей и инструменты, такие как esbuild, для быстрого и современного опыта разработки.

Чтобы понять, насколько быстро работает Vite, вот видео сравнение загрузки приложения React на Repl.it с использованием Vite и create-react-app (CRA):

Привет, это блог «Технократии». Обычно мы занимаемся цифровой трансформацией бизнеса, но сегодня у нас для вас история, как при помощи библиотеки three.js и шейдеров мы сделали лендинг для нашей промо-кампании. Главный рассказчик — разработчик Артем Ибатуллин.

Из чего состоит собеседование

• знакомство,
• технические вопросы и/или задание,
• ваши вопросы.

Привет, Хабр!

Как вы знаете при переходе с компонентов классов на функциональные, у нас отняли такую полезную вещь как this, которая указывает на текущий экземпляр компонента. И конечно у нас возник вопрос: “а где же тогда хранить timeoutId?”. И я видел как люди по разному выкручивались из этой проблемы (Данная статья, является расшифровкой видео)

Дисклеймер: я ни в коем случае не хочу сказать, что именно так и надо учиться. Но за плечами 13 лет опыта и не один год активности в сообществах, так что рассуждения будут не на пустом месте. Но если вы уже состоялись как программист, скорее всего вам будет не интересна данная публикация.