К началу 2010-х годов фронтенд-разработка оказалась в состоянии постоянного усложнения. Рост одностраничных приложений, насыщенных интерактивностью, привёл к появлению массивных JavaScript-фреймворков, которые брали на себя управление состоянием, рендеринг, маршрутизацию и бизнес-логику. AngularJS, затем Angular, React, Vue и им подобные стали де-факто стандартом, но вместе с удобством они принесли существенные издержки: увеличение объёма кода, сложность сборки, жёсткую привязку к экосистеме и высокий порог входа.
Параллельно с этим браузеры эволюционировали и начали предоставлять нативные механизмы для решения многих задач, которые ранее приходилось закрывать библиотеками. Однако эти возможности долгое время оставались недооценёнными или использовались фрагментарно.
Одной из ключевых предпосылок создания Lit стала стандартизация Web Components. Этот набор спецификаций включал:
Web Components предлагали универсальный, фреймворк-независимый подход к созданию компонентов интерфейса. Компоненты можно было использовать в любом проекте, независимо от выбранной библиотеки или фреймворка. Несмотря на это, работа с чистыми Web Components оставалась низкоуровневой и требовала значительного объёма шаблонного кода.
Хотя Web Components решали проблему стандартизации и переиспользования, они не обеспечивали удобного декларативного рендеринга. Основные сложности заключались в следующем:
Без дополнительного уровня абстракции код быстро терял читаемость и масштабируемость. Это создавало нишу для библиотеки, которая могла бы упростить работу с Web Components, не превращаясь при этом в полноценный фреймворк.
Google ранее предпринимал попытку популяризировать Web Components через библиотеку Polymer. Она предоставляла удобный синтаксис, систему биндингов и инструменты для создания компонентов. Однако Polymer оказался тяжеловесным, имел сложный API и со временем утратил актуальность на фоне более лёгких решений.
В процессе развития Polymer стало ясно, что:
Эти выводы легли в основу нового подхода, результатом которого стал Lit.
Ключевым трендом фронтенд-разработки стала декларативность. React продемонстрировал эффективность описания интерфейса как функции от состояния. Однако его реализация основывалась на виртуальном DOM, который добавлял дополнительный слой абстракции и накладные расходы.
Возникла идея совместить декларативный подход с нативным DOM, избегая виртуализации. Для этого требовался механизм:
ES6 привнёс в язык шаблонные строки и механизм tagged templates, позволивший интерпретировать шаблон как структуру данных, а не просто строку. Это открыло путь к созданию высокоэффективных шаблонизаторов без парсинга HTML-строк на каждом обновлении.
Именно этот механизм стал фундаментом для рендеринга в Lit. Шаблон анализируется один раз, после чего библиотека обновляет только динамические части, опираясь на прямые ссылки на DOM-узлы.
Одной из важнейших предпосылок появления Lit стала потребность в минималистичной библиотеке. Основные принципы включали:
Lit не стремился заменить фреймворки, а предлагал строительный блок, который можно было использовать как самостоятельно, так и внутри более сложных архитектур.
С ростом сложности интерфейсов всё большее значение приобретала производительность. Lit проектировался с учётом следующих факторов:
Такой подход позволял создавать быстрые компоненты, особенно эффективные в сценариях с большим количеством элементов или частыми обновлениями состояния.
Использование стандартных Web Components означало, что компоненты, созданные с помощью Lit, не привязаны к конкретному фреймворку или версии библиотеки. Это снижало риски устаревания и упрощало поддержку в долгосрочной перспективе.
Компоненты можно было:
Lit возник как ответ на совокупность факторов:
Эти предпосылки сформировали библиотеку, ориентированную не на замену экосистемы, а на эффективное использование возможностей платформы веба.