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

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

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

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

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

С точки зрения разработчика, объекты в JavaScript довольно гибкие и понятные. Мы можем добавлять, удалять и изменять свойства объекта по своему усмотрению. Однако мало кто задумывается о том, как объекты хранятся в памяти и обрабатываются JS-движками. Могут ли действия разработчика, прямо или косвенно, оказать влияние на производительность и потребление памяти? Попробуем разобраться во всем этом в этой статье.

В этой статье мы детально разберем процесс сборки мусора движком V8. Познакомимся с понятиями поколений, Minor и Major Garbage Collection, посмотрим, как аллоцируются, трассируются и маркируются объекты в памяти. Что происходит с пустыми областями после очистки, и как выполняется сборка мусора в фоновом режиме. 

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

По поводу строго режима существует множество информации. Но, к сожалению, очень мало статьей, покрывающих весь спектр особенностей строго режима. Поэтому, я решил составить свой справочник всех ограничений, исключений и отличий в исполнении "строгого" кода от "не строгого", в полном соответствии со спецификацией ECMA-262.

В сети есть довольно большое количество публикаций про Event loop и как он работает. Новые статьи появляются на популярных ресурсах и по сей день, в том числе на Хабре. Однако, к сожалению, далеко не вся информация, представленная в этих материалах является проверенной или достоверной. В связи с чем, само понятие обросло рядом мифов и догадок. Порой, даже опытному разработчику требуется немало внимания и опыта, чтобы понять, где истина, а где, чистой воды, вымысел.

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

Минули те времена, когда разработчики писали Frontend на «чистом» JavaScript (вплоть до ECMAScript 5). Все изменилось с выходом в свет версии ECMAScript 6 в 2015-м году. Это событие стало, по истине значимым в мировой Frontend разработке. Предыдущие 6 лет до этого, язык практически не менялся. Годом ранее, в 2014-м, компания Microsoft опубликовала TypeScript 1.0 и предоставила встроенную поддержку языка в своей IDE VisualStudio 2013. На самом деле, официально, TypeScript был выпущен еще в 2012 (версия 0.8), однако, популярностью он не пользовался в виду практически полного отсутствия поддержки со стороны существующих, на тот момент, IDE.

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

Типизацию TypeScript рассматривать в этой статье не будем, т.к. очевидно, что в ECMAScript её нет, и сравнивать тут нечего.

Для чистоты эксперимента код будем транспилировать в старый добрый ECMAScript 5. TypeScript, для удобства, возьмем версии 4.8.4 (этой версии, для целей статьи достаточно) и будем компилировать его родным tsc компилятором. Для ECMAScript воспользуемся инструментарием Babel.

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

На момент написания статьи, последняя стабильная версия React 18.2.0. За 10 лет разработчики Facebook проделали колосальный объем работы, было реализовано много фич и сделано не мало оптимизаций. За эти годы, так же, происходили и кардинальные архитектурные изменения. Очевидно, одной статьи мало, чтобы покрыть всю механику React, поэтому, данная публикация станет первой в серии статей о внутреннем устройстве React. Здесь мы познакомимся с основными сущностями и архитектурными решениями.

Задача унарного оператор typeof возвращать строковое представление типа операнда. Другими словами, typeof 1 вернет строку "number", а typeof "" вернет "string". Все возможные значения типов, возвращаемых оператором typeof изложены в спецификации ECMA-262 - 13.5.1. По задумке, возвращаемое, оператором, значение должно соответствовать принятым в той же спецификации типам данных. Однако, при детальном рассмотрении, можно заметить, что typeof null должен возвращать "object", не смотря на то, что Null - это вполне себе самостоятельный тип, он описан в разделе 6.1.2. Причина тому - обычный человеческий фактор, или, попросту, невинная ошибка в коде. Как эта ошибка могла случиться, попробуем разобраться в этой статьей.

В статье Глубокий JS. В память и типах и данных мы говорили о том, как выглядит структура переменной каждого конкретного типа в памяти движка V8. В этой статье предлагаю теперь рассмотреть, где именно эти переменные хранятся и каким образом попадают в память.

Речь пойдет об Абстрактном Синтаксическом Дереве (AST), типах переменных, областях видимости и выделении памяти в стэке и куче.

Каждый Frontend-разработчик знает, что такое объект Window. С самими объектом, вроде бы, все понятно. Но при детальном рассмотрении оказывается, что браузер никогда не отдает этот важнейший глобальный объект напрямую. В этой статье я предлагаю разобраться в спецификации HTML и в том, как именно ведет себя браузер в части глобального контекста.

Появления языка HTML, обычно датируют концом 80-х - началом 90-х годов двадцатого века. В этот период свет увидели первые идеи связывания удаленных ресурсов посредством гипертекстовых ссылок, и, как следствие, появилась необходимость удобного и простого способа такие ссылки создавать и добавлять в документ. Но как вообще возникли понятие "гипертекст" и "гипермедиа"? В этом статье мы заглянем еще дальше в прошлое и попробуем проследить путь становления этих терминов от самого их зарождения.

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

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