JavaScript переживает сейчас вторую молодость, среди причин которой AJAX-бум и рост высокоскоростного доступа к интернету.

Банально, на JavaScriptе стали писать больше, чем писали раньше. И выяснили, что на чистом JavaScript много не напишешь: тяжёлое наследие Web 1.0, громоздкая Document Object Model, да и требования кросс-браузерности никто не отменял.

А кодить надо много и быстро, ведь на дворе уже Web 2.0 с его user-generated content, который эти юзеры хотят генерировать не с помощью стандартных кастрированных элементов управления родом из прошлого века, а с помощью нормальных графических интерфейсов, не хуже десктопных.

В результате для убыстрения разработки появились javascript библиотеки, количество которых наверняка перевалило за сотню. Называются они по-вебдванольски модно — “frameworkами”. Их главная цель — снять с кодера всю работу по обеспечению кросс-браузерности, обеспечив удобный доступ к DOM/AJAX и другие приятности, которых не хватает в чистом javascript. Выглядят эти фреймворки именно как библиотеками, подключаемые в документ с помощью тега <script>

Чем универсальнее фреймворк, тем он тяжелее. С одной стороны, это не проблема: есть GZIP, да и средняя скорость доступа к интернету растёт с каждым днём. С другой стороны, зачем грузить больше?

“Стандартом” отрасли ни один фреймворк не стал — все выбирают то решение, которое кажется удобней, и грузят пользователю именно его.

Рассмотрим гипотетическую ситуацию — существование стандартного javascript фреймворка. Стандартность означает поддержку браузерами.

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

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

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

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

Я уже высказывал идею хранения ресурсов, доступных “сайтам из интернета”, в локальной зоне браузера: прошлый раз я предлагал с её помощью реализовать браузерный клипарт. Вообще, идея богатая: в браузер можно напихать много стандартных вещей, и не грузить ими канал, который не резиновый.

Правда, браузеры относятся скорее к консервативному классу ПО (тяжёлое наследие HTML, ага), так что рассчитывать на внедрение такой революционной идеи больше чем одним браузером не приходится. Ведь даже нормальный индикатор аплоада никто до сих пор так и не сделал.