24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Здравствуйте, я бывший троечник и учусь (как-бы, очень фигово) на программиста. Почему браузерные движки настолько жирные? Любая часть этого сообщения может быть ложью, я не разбираюсь в том, о чём пишу. Нет, не так! Они необычайно, фантастически, нечеловечески расточительны и не производительны. Их задача - просто показывать некий текст с некими скриптами, но: Они потребляют больше ресурсов, чем иные игры, а десять вкладок Википедии занимают место настолько большее, по сравнению с текстом статей на этих страницах, что анализируя это можно поехать кукушкой. Особенно, если впомнить, что у всех страниц один и тот же стиль. Особенно, если вспомнить, что кажется во многих принтерах есть интерпретатор специального форта для форматирования документов и кажется ему хватает микроконтроллера принтера. Мне кажется, что программа просто отображающая текст сходный по форматированию займёт несколько мегабайт памяти и будет настолько простой, что её напишет троечник типа меня. По моему, даже многие графические тулкиты - уже почти что браузерные движки, по моему движок и превращает html/css в представление для тулкита. Троечнику только останется написать чуть-чуть кода, а основная работа будет у тулкита. Но браузерные движки просто нечеловечески сложные.
Почему? Всё дело в деклоративности веба? А если бы документы были императивными программами (очень не нравится это), то всё было бы проще или нет? Например msword и oowriter тоже сложные и они тоже обрабатывают деклоративные документы. PDF тоже говорят сложный. Что такого сложного всплывает в преобразователе деклоративного документа в картинку? Почему нельзя всё многоуровнево закешировать? Он же простой - видим тег - меняем текст (ну или его расположение), ну да, какое-то внутреннее представление там надо, но куда там гигабайты? И вообще веб - он какой-то переусложнённый.
Очевидный заговор очевиден. Иначе какого хуя теперь для браузеров уже нужно БОЛЬШЕ оперативы, НОВЫЙ процессор и УЖЕ видеокарта? Ну и плюс вебдизайнеры и фронтендеры решили, что писать через жопу и делать НИВЬЕБЕННЫЫЙ ДЕЗАЕН куда лучше, чем заботиться о пользователях, а из браузеров для них существует только Хром, который И ТАК СОЙДЕТ. Так что есть, то есть.
Это конечно бамп, а ещё я скажу честно: Я понятия не имею как работает огромная часть веба, вообще. По этому видимо такой культурный шок и возникает. Но сама задача выглядит простой в чём-то.
>>195060718 Ну если всё так плохо - ускорение на видеокарте и правда идея.. И похожие на браузер программы которые преобразуют деклоративные документы в "картинки" тоже часто жирные как свиньи и их стандарты сложные - Ворд, всякие офисы.
>>195060936 > Но сама задача выглядит простой в чём-то. Ну если все так просто, то возьми и напиши свой браузер, который не будет жрать столько памяти, заодно и кучу денег заработаешь.
>>195061075 Честно - я хочу, но что-то мне кажется, что я не прав по поводу сложности. Всё равно много тегов и частных случаев (закоулков)? А если сделать промежуточный язык, такой компилятор парсеров? Типа на входе список тегов и ожидаемый результат, а на выходе - код.
А ещё нужно открутить от лисы и хрома верхний слой и сделать такое промежуточное представление, и автоматически по тысячам сайтов проверять отличия в финальном рендеринге. Если их с лисохромом нет - спецификация верная.
>>195060504 (OP) Браузеры жирные потому, что там внутри уже практически своя ОС с кучей костылей для обратной совместимости. Ты охуеешь даже если попробуешь написать просто рендерер для HTML с CSS. Ехало несколько моделей лэйаута с полупрозрачностью через градиент с тенями, везде бордеры из картинок, бэкграунды из картинок, даже аллах из картинок, анимация, транзишны, селекторы, гроб кладбище пидор. Теперь добавь сюда JS, который может перехуячивать документ как угодно каждый фрейм, и получится такой же цикл рендеринга, как в игровом движке: выполняешь JS, смотришь на итоговую модель, вычисляешь стили, делаешь проход или два прохода лэйаута, рисуешь, композиционируешь. Серьёзно, попробуй написать свою рисовалку этого говна, сильно вырастешь, как программист.
>>195061311 А это уже на правах бреда! Особым шиком будет, если теги и опции css будут автоматически преобразовываться в формат для парсера на основе того, как распарсили документ эталонные хром с лисой. В таком случае БРАУЗЕР НАПИШЕТ САМ СЕБЯ!!!!!111 (жалко, что наверняка фигня получится, но идея же - огонь)
Ну или нейронную сеть обучить (типа той, которую используют для переводов, учитывающую предыдущие состояния) чтобы на входе html/css/ресурсы и на выходе - картинка. Тоже фигня получится, думаю, но результат будет прикольный и интересный.
>>195061581 Хорошо, но должен же быть способ к этому по человечески подойти, не пересчитывать там то что не нужно, использовать промежуточные результаты этих всех вычислений. Эти все пересечения друг с другом должны как-то "сами-собой" рисоваться что-ли.
И такой цикл рендеринга часто уже не нужен когда скрипты уже отработали.
>>195061840 А что ебанутого в промежуточном представлении? Это как раз и способ описать всё то сложное поведение для браузера более просто, ну и добавлять новые фичи будет куда проще. Генераторы парсеров уже есть. Там же можно будет описывать поведение, когда лейауты едут через градиент с тенями и что должно выйти при их комбинации. Только это всё - статически...
А идея свести состояние популярных браузеров и того велосипеда к одному знаменателю и проверять отличия на разных случаях автоматически - тоже кажется крутой. >>195062011 И уже это полезно само по себе.
>>195062275 Ну тогда нужно закэшировать больше всего. Не только картинки, но и результат парсинга на всех уровнях. И учиться больше использовать этот кэш... >JS не прекращает работу на страничке. Но ведь она уже не меняется. И если этот JS уже не пытается менять страничку, то пусть себе живёт внутри.
>>195062030 >Хорошо, но должен же быть способ к этому по человечески подойти, не пересчитывать там то что не нужно, использовать промежуточные результаты этих всех вычислений. Ага, только вот гарантию того, что что-то можно переиспользовать никто никогда тебе дать не может с html и css. Самому парсить и искать - еще больше ресурсов тратить, чем ты сэкономишь. В мобайл эпп деве именно поэтому всё переиспользование находится в руках разраба, он сам должен накодить так, чтобы не было лишних лейаут инфлейтов, даже помогают с этим например такой хуйней, как ресайкл вью в андроиде. Тут надо нахуй уходить от всего текущего html+css и делать совершенно новую структуру вебдева, чтобы реализовать то, что ты описал, только вот этого никогда не произойдет. Слишком зависимы мы от текущего веба, слишком много легаси. Так и будем клепать монстра с новыми фичами с каждым следующим стандартом, который при этом полностью совместим со старыми стандартами.
>>195062480 >Ну тогда нужно закэшировать больше всего. Не только картинки, но и результат парсинга на всех уровнях За чей счёт гулянка? >Но ведь она уже не меняется Меняется.
А мне расскажите, почему андроид-приложения вроде вк и инстаграма разжирели за пару лет с 50мб до 150мб, практически не прибавив функционала. Я не программист, но даже мне понятно, что 100мб кода - это очень много.
>>195063683 Но там полный минимализм с однотонными заголовками и микроиконками. А всякие говностикеры и прочая параша подгружаются с сервера при их использовании.
>>195062757 Ну я бы хотел заменить многое внутреннее представление как-бы кэшем. Если его не хватает - поднять кеш более детализированного уровня. Ну и каждой части кэша создать приоритет, который влияет на выгрузку его из памяти если лимит на неё кончается. И выгружать всё если можно. А если скрипт хочет что-то поменять на страничке, то он создаёт этакое событие которое приводит к тому, что мы проверяем можем ли мы сделать действие на этом этапе кэширования и если нет - поднимаем более глубинные слои. Но мы должны поднимать их точечно, по объектам, или это будет тормозить ещё хуже.
Или я придумал чушь. Ладно, пока я над этим думал..
>>195062543 А почему нельзя? Ох. Получается веб - архитектурный урод?
>>195063758 >там полный минимализм с однотонными заголовками и микроиконками Вот видишь. Значит надо 2018р 120 фпс завозить. Дизигнеры стараются, а юзеры из минимализмом обзывают.
>>195063906 Половина современных протоколов архитектурные уроды. Например, никому нахуй по сути не нужна возможность отправлять/принимать почту, вручную пихая команды через телнет клиент, но её до сих пор тянут для совместимости. Как и семибитную кодировку (UUE/B64/MIME/прочее издевательство, вместо того чтобы отправлять в хуюникоде текстом, а не абракадаброй из буквочек и цифирок).
>правильный движок Тебе надо менять весь подход. Нет таких понятий "правильный" и "неправильный" в той же разработке. Это что-то из разряда просто пример правильных пацанов и пидоров опущенных. Т.е. зависит исключительно от субъекта и его точки зрения. На деле же есть определённые качественные характеристики того же движка как то - лёгкость освоения, разработки, модификации, расширения и т.д. Минимально "правильный" движок должен просто решать свою задачу как угодно.
Почему браузерные движки настолько жирные?
Любая часть этого сообщения может быть ложью, я не разбираюсь в том, о чём пишу.
Нет, не так!
Они необычайно, фантастически, нечеловечески расточительны и не производительны. Их задача - просто показывать некий текст с некими скриптами, но:
Они потребляют больше ресурсов, чем иные игры, а десять вкладок Википедии занимают место настолько большее, по сравнению с текстом статей на этих страницах, что анализируя это можно поехать кукушкой.
Особенно, если впомнить, что у всех страниц один и тот же стиль. Особенно, если вспомнить, что кажется во многих принтерах есть интерпретатор специального форта для форматирования документов и кажется ему хватает микроконтроллера принтера.
Мне кажется, что программа просто отображающая текст сходный по форматированию займёт несколько мегабайт памяти и будет настолько простой, что её напишет троечник типа меня. По моему, даже многие графические тулкиты - уже почти что браузерные движки, по моему движок и превращает html/css в представление для тулкита. Троечнику только останется написать чуть-чуть кода, а основная работа будет у тулкита.
Но браузерные движки просто нечеловечески сложные.
Почему? Всё дело в деклоративности веба? А если бы документы были императивными программами (очень не нравится это), то всё было бы проще или нет?
Например msword и oowriter тоже сложные и они тоже обрабатывают деклоративные документы. PDF тоже говорят сложный.
Что такого сложного всплывает в преобразователе деклоративного документа в картинку?
Почему нельзя всё многоуровнево закешировать?
Он же простой - видим тег - меняем текст (ну или его расположение), ну да, какое-то внутреннее представление там надо, но куда там гигабайты?
И вообще веб - он какой-то переусложнённый.