Комментарии 11
Мы прошли весь путь жизни веб-страницы внутри современного браузера — от ввода URL до сетевого взаимодействия и навигации, парсинга HTML, применения стилей, формирования макета, отрисовки и выполнения JS, вплоть до вывода пикселей на экран с помощью GPU. Мы убедились, что браузеры по сути представляют собой миниатюрные ОС: они управляют процессами, потоками, памятью и множеством сложных подсистем, обеспечивая быструю загрузку и безопасное выполнение кода. Понимание этих внутренних механизмов помогает веб-разработчику осознать, почему те или иные рекомендации действительно важны: например, минимизация перерисовок или использование асинхронных скриптов — критичны для производительности; а политики безопасности, такие как запрет смешивания источников во фреймах, существуют не случайно, а ради защиты пользователя
Удивительно! Но!! Всего этого могло не быть. Мы могли до сих пор пользоваться обыкновенными настольными ("нативными") приложениями, использующими родные для ОС компоненты пользовательского интерфейса и общение при помощи сокетов (например). Возможно, был бы предложены каике-то новые протоколы сетевого обмена. Не было бы этого чудовищного нагромаждения технологий и фреймворков. Отладка и тестирование были бы встроенной функцией. (Не надо было бы "тянуть" Selemnium и Playwrite.) Я и не говорю про существенно большую безопасность для пользователя и прозрачность управления.
Но тогда мы были бы залочены на ОСи, на которых эти приложения были бы. А браузер дает нам немного чего-то вроде реальной кроссплатформенности. Не так ли?
Фреймворк Qt, к примеру. Нативные приложения на С++ и/или питоне, поддержка (местами кривоватая, но неплохая) нативного внешнего вида ОС. На мобильных не знаю, но на десктопе очень даже неплохо. Одна кодовая база, просто перекомпилируете под другую платформу (есть оговорки, но в целом так)
... реальной кроссплатформенности. Не так ли?
Тут ещё вопрос возникает: а что такое кроссплатформенность? Откуда она берётся?
Эти меры значительно усложняют эксплуатацию уязвимостей: злоумышленнику теперь нужно использовать цепочку нескольких эксплойтов (например, один для взлома рендерера, другой для выхода из песочницы), чтобы нанести серьезный ущерб.
На этом месте очень хотелось бы привести примеры этого самого ущерба. Что можно сделать? Как только мы это всё тщательно опишем, то мы сможем задать главный вопрос: какова должна быть архитектура системы, которая исключает появление такого ущерба (или, в крайнем случае, существенным образом минимизирует его).
Следите за выполнением JS: несмотря на высокую скорость работы движков JS, длительные задачи блокируют основной поток. Разбивайте тяжелые операции на части, чтобы интерфейс оставался отзывчивым. В некоторых случаях стоит использовать веб-воркеры (Web Workers) для выполнения фоновых задач. Также помните, что интенсивное выполнение JS может вызывать паузы при сборке мусора (в наше время они редки и недолговременны, но могут возникать при значительном увеличении объема используемой памяти).
Главный вопрос: зачем нужен JavaScript?
Для автоматизации действий в браузере - например, валидация вводимых пользователем данных. С этого всё и началось, в общем-то - с кастомизации реакции веб-страницы на действия пользователя. Без какого-либо ЯП этого достичь невозможно в принципе. Предложили LiveScript, который затем стал JavaScript. И понеслось...
Все "странности" JS, начиная с EventLoop, они отсюда - из веб-страницы. Ну и в nodejs перекочевали.
Хорошая публикация (y) Браузер уже достаточно давно стоит рассматривать, как интернет-ОС. Пытались делать ChromeOS, но по факту любой браузер уже является операционной системой для выполнения распределённых приложений. Только мы его по инерции воспринимаем, как просмотрщик веб-страничек, хотя AJAX (SPA) появился 20 лет назад, а PWA - десять. Но всё равно - "открыть страничку". Хотя сейчас на "страничке" иногда кода больше, чем текста.
никогда не думал, что с таким интересом будут читать такую техническую статью за браузер) все доступно и понятно расписали) спасибо
И снова не могу не спросить.
Всегда интересовало. по какому критерию браузеры выбирают сколько процессов открыть. соответсвуют ли они количеству вкладок. В большинстве случаев не соответсвуют. Может можно где то это настраивать или наоборот отключать чтобы был один?
Что касается что если одно зависло или жрет память то можно и закрыть одно. по моим наблюддениям это не так. даже если ты видишь что один процесс не отвечает и закрываешь валится и браузер следом. Можно это все как то контролировать? опятьже настройки или конкертный браузер который это лучше делает?)
И совсем глупый. Есть ПРОСТО старые добрые браузеры или что-то на них похожее? или уже невозможно будет работать с таким? Получается что из за усложнения сайтов уже браузеры не справляются.
Как думаете Есть ли шнас что сайты начнут всетаки сдуваться и вернемся к классическим страницам? пусть не на чистом легковесном HTML но хотябы не таким монструозном как сегодня. Неужели разработчикам до этого дела нет?
Как работают современные браузеры. Часть 2