Всем привет! Меня зовут Владимир и работаю джуниор фронтенд разработчиком в одной из лучших компаний :-)

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

При разработке веб-приложений не все задумываются о том, сколько памяти потребляет их код. О производительности наших сайтов мы вспоминаем гораздо чаще. К тому же не каждому разработчику интересно «экономить на спичках». Разве может наш код на языке JavaScript требовать много памяти? «Много» — это вообще сколько? 100 мегабайтов — это много?

Меня зовут Антон Непша. Я работаю в Сбере, разрабатываю сайт СберБанк Онлайн и веду Telegram-канал Антон Непша.js. Недавно я выступил на HolyJS с докладом о том, сколько ресурсов потребляют наши сайты, как эти ресурсы распределяются, где хранятся, и как связать информацию о них из снимка памяти с конкретным местом в своём коде.

Если смотреть видео вам удобнее, то доклад есть на YouTube и ВК Видео. В статье вас ждёт текстовый вариант и ссылки на используемые материалы:

▍ Навигация по вышедшим частям

• Часть 1
• Часть 2 < — вы здесь.
• Часть 3
• Часть 4
• Часть 5

▍ Навигация по частям

• Часть 1 < — вы здесь.
• Часть 2
• Часть 3
• Часть 4
• Часть 5

Узнайте, почему большие TypeScript-проекты начинают "захлёбываться" от рекурсивных типов и обилия импортов, и как с помощью правильной структуры монорепы, настройки tsconfig и диагностики ускорить время компиляции и работу IDE. Рассматриваем инструменты, параллельную сборку, оптимизацию рекурсивных типов и прочие техники, которые помогут сохранить ваш проект быстрым и удобным.

Симуляция данных о свете при попадании на сетчатку для левого глаза. В поле зрения видны ресницы, тень от носа справа. Участок чёткого и цветного зрения (макула), сосуды сетчатки, и тёмное пятно зрительного нерва. Желтый тон от ультрафиолетового фильтра хрусталика.

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

TLDR. Я примерно год создавал курс из 141 урока. Курс получился хороший, все кто проходят рады и пишут положительные отзывы. Я пытался его продавать, в лучшем случае у меня получалось отбивать рекламу в ноль. Короче, я хороший разработчик, я хорошо доношу материал, но я плохой маркетолог. Все эти таргреты, ретаргеты, воронки, шморонки — тоска унылая. Мне гораздо веселее и понятнее заработать на создании и запуске IT-продуктов, чему я и учу в этом учебнике. Так что пишу эту статью, чтобы сообщить вам о существовании моего курса и предложить всем желающим абсолютно бесплатно получить от него пользу 🙂

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

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

Сначала я удивился — откуда взялись такие идеи? Ведь мы много лет работали с большими объемами данных без всяких генераторов. Лучшая статья про генераторы в РНР, опубликованная ещё десять лет назад, Что генераторы могут для вас сделать Антонио Феррары тоже практически не упоминает экономию памяти. У меня и у самого всегда было чёткое ощущение, что хотя генераторы — это совершенно отличное изобретение, у которого есть множество разнообразных применений, но вот только экономии памяти среди них нет.

В итоге у меня разыгралось любопытство и я решил разобраться с этим вопросом.

А вы уже прятали что-то внутри PNG? Базовый способ надежно спрятать что-то внутри картинки. И все на вашем любимом JavaScript!

Привет! Меня зовут Никита, и я тружусь в команде фронтенда платформы в Ozon. Платформа поставляет инструменты для создания и поддержки JS-проектов. В компании в настоящее время более 500 таких проектов. Мы прилагаем максимум усилий, чтобы разработчикам всех проектов было одинаково приятно работать с нашими инструментами.

Также мы предоставляем инструменты для создания JS-библиотек. И в этой статье я расскажу о том, как мы советуем создавать npm-пакеты. Отмечу, что это не касается UIKit-пакетов, — для них требуется довольно специфичный инструментарий, который заслуживает отдельной статьи.

Недавно у нас проходила актуализация инструментов, которая включала обновление версий Node, TypeScript и прочего. И мы обнаружили, что сейчас правильно упаковать библиотеку ой как нелегко, особенно с началом активной фазы по отказу от CommonJS. В идеале очень хочется иметь инструмент, который бы просто работал. В open-source есть парочка вариантов (unbuild, pkgroll, dnt), но выбрать подходящий мы пока не смогли. А написать свой — довольно трудоёмкая задача. В будущем мы обязательно обзаведёмся таким инструментом, а пока просто погрузились в тему и подготовили для наших разработчиков рекомендованные сетапы, которыми сейчас поделимся и с вами.

section .data
  msg db "Hello, World!"

section .text
  global _start

_start:
  mov rax, 1
  mov rdi, 1
  mov rsi, msg
  mov rdx, 13
  syscall

  mov rax, 60
  mov rdi, 0
  syscall

О том, как сделать прозрачную синхронизацию заметок Obsidian между устройствами (Desktop, Android, iOS) через GitHub:

1. Без сторонних приложений (вроде iCloud, SyncThing, Termux и пр)
2. Бесплатно
3. Бонусом — резервная копия: как самих заметок, так и истории изменений.

В результате получается полноценная замена Notion: структурированные заметки с автоматической синхронизацией между устройствами.

Данный текст является ответом на опубликованную накануне «Оду бесполезности споров» с целью рассказать о проекте, который намерен принципиально решить проблему анализа достоверности информации в Интернете и оценки репутации ее авторов. Я считаю, что новые никогда ранее не существовавшие децентрализованные технологии дают нам возможность наконец найти ответ на извечный вопрос «Что есть истина?», которым уже почти две тысячи лет задается человечество.

Какую игру ни делай, а в итоге все равно получится ГТА. Каждый школьник мечтает создать свой клон ГТА. ГТА всему голова. Без труда не пройдешь и ГТА. Ой, что это я? Короче говоря, я делал игры и в какой-то момент осознал, что достиг дзена, и теперь настала пора и мне тоже написать свой вариант той самой исходной игры, игры-прародительницы всех игр, игры-протовселенной, канонической игры, а именно игры про езду на тачке в открытом мире. Каждый мужчина должен посадить дом, родить дерево и создать свой клон ГТА. Э-э... Ладно. Нет, конечно, GTA - это не только про тачку. Позже добавим и ходьбу, и копов, и плоские шуточки, хотя, последнее я, кажется - уже. Похоже, что сейчас моя игра, скорее, ближе к Need For Speed: в ней уже можно гонять по городу, но еще нельзя выходить из машины, да и пешеходов пока нет. Зато есть открытый мир. Ничего, скоро доведем этот NFS до состояния полного GTA. Тут мне подумалось, что все игры - это одна и та же игра, но с разными урезанными возможностями. Это как в случае со скульптором, который просто отсекает все лишнее... Короче, вы поняли, я философ.

Я расскажу вам о том, как я создал довольно большую локацию, содержащую более 20 000 объектов (это еще не предел), с физической моделью, при этом сохраняющую неплохую производительность в браузерах, в том числе мобильных. Будет интересно, не переключайтесь.

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

Я бросил себе вызов: симулировать 1000000 (миллион) частиц на чистом Javascript на телефоне, используя только CPU и добившись 60 FPS.

Поехали.

Задача не особо сложна, если выполнять всю работу на GPU, но правило гласит, что нужно пользоваться только CPU, при этом работая на JS, так что никакого WASM.

Хабр, привет! Я частенько пишу про работу CSS, его неизвестные возможности и влияние на доступность. Кажется, этих направлений мало для меня. Теперь я хочу показать техники вёрстки, используемые мной постоянно.

Цель — поделиться опытом с вами. Я использую не только трюки известных экспертов, есть лично мои придумки. Но, пожалуйста, относитесь к этому контенту, как просто альтернативному мнению. Мои техники не являются единственными правильными решениями.

Сегодня я расскажу:

• как избавиться от соседнего родственного комбинатора + при реализации нестандартных чекбоксов и радиокнопок;
• про свойство inset, сокращающее код на целых три строки;
• мой сниппет для расширения интерактивной области у кнопок и ссылок;
• стиль написания медиа-запросов, позволяющий сократить количество правил;
• альтернативный способ центрирования элемента без свойства transform.

Думаю, ни для кого не секрет, что все популярные JavaScript движки имеют схожий пайплайн выполнения кода. Выглядит он примерно следующим образом. Интерпретатор быстро компилирует JS-код в байт "на лету". Полученный байт код начинает исполняться и параллельно обрабатывается оптимизатором. Оптимизатору требуется время на такую обработку, но в итоге может получиться высоко-оптимизированный код, который будет работать в разы быстрее. В движке V8 роль интерпретатора выполняет Ignition, а оптимизатором является Turbofan. В движке Chakra, который используется в Edge, вместо одного оптимизатора целых два, SimpleJIT и FullJIT. А в JSC (Safari), аж три Baseline, DFG и FTL. Конкретная реализация в разных движка может отличаться, но принципиальная схема, в целом одинакова.

Сегодня мы будем говорить об одном из множества механизмов оптимизации, который называется Inline Caches.