JavaScript *

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

Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. Сегодня мы поговорим о методах массивов. Если коротко, вы узнаете, как легко и элегантно работать со списками данных, не используя громоздкие циклы. Детали внутри.

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

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

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

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

Веб-разработчики нередко воспринимают браузер как «черный ящик», который каким-то чудом превращает HTML, CSS и JS в интерактивные веб-приложения. На самом деле современный браузер — будь то Chrome (на базе Chromium), Firefox (Gecko) или Safari (WebKit) — представляет собой чрезвычайно сложное программное решение. Он управляет сетевыми запросами, разбирает (парсит) и выполняет код, рендерит графику с ускорением на графическом процессоре (GPU) и изолирует контент в отдельных процессах для обеспечения безопасности.

В этой серии статей мы подробно рассмотрим, как устроены современные браузеры, сделав акцент на архитектуре и внутреннем устройстве Chromium, но также отметим ключевые отличия в других браузерах. Мы рассмотрим весь цикл: от сетевого стека и конвейера парсинга до рендеринга с помощью Blink, выполнения JS с помощью движка V8, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".

Реверс-инжиниринг — это трудоемкая и интересная задача, которая поддается не всем. Любой может «скормить» программу декомпилятору, но не у всех хватит выдержки разобраться в хитросплетениях машинных команд. Процесс становится сложнее, если исследование проводится над программой для другого устройства, например телефона с ОС Android.

Звучит сложно. Долгое время и мне так казалось, особенно при создании модов для приложений. Байт-код smali неплох, но писать на нем сложную логику вручную — неблагодарное занятие. Но недавно мне попался на глаза решение для динамического реверс-инжиниринга — Frida.

Frida — это инструмент, который позволяет вживлять небольшой кусок JavaScript-кода прямо в запущенное приложение и менять его поведение. Под катом я расскажу, как работать с Frida, исследовать приложения на телефоне без root-доступа и создавать свои моды.

Недавно UI-библиотека Nuxt UI получила серьёзное обновление — версию Nuxt UI 4. Это принесло два больших изменения. Во-первых, теперь можно использовать Nuxt UI не только с Nuxt, но и с Vue напрямую. Во-вторых, все ранее платные возможности (Pro-компоненты, стартовые шаблоны и Figma UI Kit) теперь полностью бесплатны.

Всё это хороший повод разобраться, как же устроена Nuxt UI, в чём её преимущества и как начать с ней работать.

Первая в мире библиотека Web Components в духе shadcn/ui

Насколько я проверил — это первая подобная библиотека для Web Components. Если ошибаюсь — поправьте в комментах! 🤓

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

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

Видео стало неотъемлемой частью нашей жизни: мы смотрим его на смартфонах, ноутбуках и всё чаще — на телевизорах. Несмотря на то, что видеосервисы традиционно ориентировались на мобильные устройства, за длинным контентом пользователи идут именно на большие экраны, и это подтверждается ростом времени просмотра. Сегодня среднее дневное время смотрения VK Видео на Smart TV достигает 216 минут.

И тут начинается самое интересное: телевизоры — это особый мир со своими капризами и законами. Официальные спецификации обещают поддержку HLS, DASH, 4K, 60 FPS. На практике поддержка функций зависит не столько от новизны модели, сколько от того, как это реализовано у конкретного производителя. В одних устройствах всё работает корректно, в других — частично или вовсе не запускается. Новая модель при этом не всегда гарантирует лучшее воспроизведение видео.

Меня зовут Игорь Горяйнов, я программист в команде веб-технологий Единой видеоплатформы VK. Ниже расскажу, как команда прошла путь от нативных плееров к собственному веб-решению для ТВ, какие задачи пришлось решать и что это дало пользователям.

Привет, Хабр. Я Саша, разработчик, пишу на JS. Ранее я рассказывал о callback-функциях, деструктуризации, операторах и многом другом. Если вы уже успели познакомиться с основами JavaScript, то наверняка вам знакомы такие понятия, как объекты и функции.

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

Лето уже давно позади, зима на носу, а значит — самое время начинать подготовку к следующему лету. Для многих это означает одно: попытку выбраться из состояния «тюленя» хотя бы в состояние «тюленя, который слегка похудел».

Чтобы совместить полезное с полезным, заодно соберём небольшое приложение — простой трекер веса и тренировок — и посмотрим, как на практике работает мультиплатформенная разработка на React с Expo. Спойлер: почти то же самое, что и обычная разработка на React — и, похоже, именно она окончательно забивает гвоздь в гроб Dart/Flutter и прочих попыток конкурентов сделать вид, что React — это страшный сон, который можно забыть.

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

Привет! Я Полина, фронтенд-разработчик в Selectel. В этой статье я решила залезть в темные уголки React и Angular, чтобы лично посмотреть, что же там происходит. Для чистоты эксперимента я выбрала шесть типовых несложных задач, для решения которых подойдет и фреймворк, и библиотека. Подробности под катом.

API.

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

Так что сегодня объясню, что такое API, так, что ты точно поймешь: на простых примерах, интересно, да еще и с крутой графикой. Уже через несколько минут ты будешь великолепно знать, что такое API и как создать свой собственный.

Микросервисы тут, микросервисы там… Из каждого утюга доносится дивный сказ про прекрасный мир микросервисов. А ведь это всего лишь один вид из десятка архитектурных стилей, который имеет свои достоинства и недостатки.

В этом эксперименте мы внедрим микросервисы в личный сайт, нарушив ключевые принципы DDD. Я создам антипаттерн «бедных сервисов» (Anemic Domain Model) и покажу, чем опасен прямой доступ к данным между микросервисами.

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

Недавно мы переделали наши внутренние инструменты, визуализирующие компиляцию JavaScript и WebAssembly. При работе оптимизирующего компилятора Ion мы теперь можем генерировать интерактивные графы, демонстрирующие, как конкретно обрабатываются и оптимизируются функции.

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

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

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

Привет, Хабр! Я — Александр Дудукало, автор одноименного YouTube-канала. В прошлой статье мы разобрали ссылочный тип данных, который хранит не само значение, а ссылку на него в памяти. Сегодня используем полученные знания на практике и познакомимся с одной из самых важных концепций в JavaScript — callback-функциями. Подробности — под катом!

Пару недель назад, когда я писал пост The Hidden Cost of URL Design, мне нужно было добавить подсветку синтаксиса SQL. Я направился на веб-сайт PrismJS, пытаясь вспомнить, можно ли добавить его в качестве плагина. Меня утомило количество вариантов на странице скачивания, поэтому я вернулся к своему коду. Поискав в файле PrismJS, я нашёл в его начале комментарий, содержащий URL:

/* https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript+bash+css-extras+markdown+scss+sql&plugins=line-highlight+line-numbers+autolinker */

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

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

Я задумался: как часто мы, фронтенд-разработчики, забываем об URL как об инструменте управления состоянием? Мы пытаемся использовать для этого всевозможные абстракции: глобальные хранилища, контексты, кэши, забывая при этом одну из самых древних и изящных фич веба: скромный URL.

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

Ниже я приведу примеры, как пустить пыль в глаза юзерам можно улучшить ситуацию с ощущением чужеродности приложения среди других, написанных на честном Gtk, китами из XCode, Windows UWP и прочим с 0% вайбкодинга

Мне часто доводится вести странные споры с фанатами фреймворков о том, действительно ли <div> «столь же хорош», как и <button>.

Спойлер: нет. И давайте выясним, почему.

Да, я его действительно ненавижу. Мне кажется, что команда React'а презирает разработчиков, и я презираю их в ответ. Все их решения направлены на то, чтобы сделать разработку сложнее, медленнее и непредсказуемее. На сегодняшний день они даже умудрились сломать работу JavaScript. Уму непостижимо, почему им это сходит с рук.