UNFINISHED VERSION. NOT FOR PUBLISH!!!!!!11111

Поиск

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

Однажды на одном из форумов я нашел интересную концепцию алгоритма. Обсуждения не было, так что я быстро закрыл вкладку, но сама концепция осела у меня в голове. Поразмышляв над ней в фоновом режиме, я решил поделиться своими идеями… Но где? Быстро оглянув форумы, где я обычно обитал - я не нашел ничего подобного. В поисковиках тоже ничего, но это и не удивительно - форумы не мгновенно индексируются. Я начал рыться в хистори браузера - ничего не нашел, но это и не удивительно, так как она большая, ей неудобно пользоваться, я мог что-то пропустить. Я заново открывал почти все странички - ничего подобного не нашел. Я начал искать сообщения в почте, в мессенджерах, даже спрашивать людей - без результата. Я уже было начал думать, что мной управляют рептилоиды, внушающие концепты, как решился применить последнее средство: поиск по файлам браузерного кеша. И почти мгновенно нашел то место, которое искал. Оказалось, что поскольку никто не отвечал в тему форума, автор подумал, что он написал глупость, ему стало стыдно и он просто удалил тред. А я эту удаленную тему долго искал и не мог найти.

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

Снепшот страницы

Бывает так, что открыв какую-то незатейливую страничку с каким-то текстом, порой забываешь о ней и оставляешь висеть во вкладках, “на потом”, “чтобы не забыть”. Как правило, там нет ничего особенного. Например, там рассказывают как выращивать клубнику на даче и совсем ничего такого, что предвещает неприятности.

А придя к компьютеру через несколько часов замечаешь, что КУРСОР МЫШКИ ЕЛЕ ДВИГАЕТСЯ, ВСЕ В СВОПЕ РАБОТАТЬ ЗА КОМПЬЮТЕРОМ НЕВОЗМОЖНО В УЖАСЕ ОТКРЫВАЕШЬ СПИСОК ПРОЦЕССОВ И КИЛЯЕШЬ ГАДА (если сможешь дождаться отрисовки списка процессов). И тут закрывается вкладочка как раз с этим невинным сайтом.

Чтобы такого не было, я в свое время написал для Firefox плагин, который спустя 5 секунд после загрузки страницы (события onload) подменял setInterval/setTimeout/requestAnimationFrame на пустые вызовы, которые ничего не делали, а существующие отключал. В принципе, я радовался. Правда всякие интерактивные элементы, вроде разворачивающихся спойлеров, тоже перестали работать, так как таймеров больше не было, а открытие спойлера запускало таймер для анимации. Большая ли это цена? Мне пришлось отказаться от своего плагина, так как я не мог возвращать обработчики по какому-то событию, но если мы пишем свой браузер - почему нет?

Альтернативная реализация: спустя 10 секунд от события onload, мы останавливаем весь JS, выгружаем DOM и оставляем только те структурки в памяти, которые нужны для рендеринга прямоугольничков с текстом, таблицами и картинками. Все, пусть фоновая вкладка будет чем-то вроде картинки с текстом, не более того. Еще одна альтернатива: весь лейаут мы рендерим в отдельном процессе, а загружаем только координаты текста и картинок после рендеринга, как это было в Opera Mini, таким образом наш браузер будет еще чуток безопаснее.

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

Кеширование контента локально

Рассказываю идею на миллион баксов: загрузка за 0мс. Нет, даже если сайт полностью лежит в нашем кеше, то он не откроется, пока мы не пошлем запрос, не подождем Round Trip Time, не распарсим ответ, а потом не проделаем аналогичное со всеми оставшимися скриптами и стилями. А что мешает открывать его СРАЗУ из кеша и в фоне проводить валидацию контента, посылая сразу запросы ко ВСЕМ ресурсам в фоне, в фоне же, используя двойную буферизацию, обновлять данные в случае изменений, как просто перерисовывая картинки, так и блоки текста?

К сожалению, в современном вебе кеширование не просто плохо работает, а скорее не работает вообще. Но что мешает принудительно сохранять странички на диск? Это позволило бы не только открыть сайт в случае его смерти, спасти какой-то полезный контент, но и отслеживать, к примеру, динамику изменения цен на товары или ловить собеседников на том, что они изменили свои посты. Конечно, можно сохранять странички на диск вручную… Но как правило вспоминаешь об этом, когда уже надо вернуться к какой-то старой версии, а ее нету, а на веб-архив надежды мало. Иногда можно выковырять контент из поисковиков, но это работает не всегда, особенно если сразу не успел. Особенно это было бы полезно в тех случаях, когда контент легко разделяем на отдельные управляемые элементы, но об этом немного позже.

Само собой, кеширование должно быть в виде инкрементальных diff-ов (иначе места не хватит на все), с интеллектуальным парсингом неотображаемой информации (незачем хранить изменяющийся код счетчиков), с подсветкой изменений, с выбором старых версий прямо из адресной строки. Хранить можно уже распаршенные странички, как набор прямоугольников и их координат на экране, таким образом можно ускорить рендеринг, а изображения можно даунскейлить и хранить в виде h265, который гораздо лучше jpeg-картинок - мы экономим место. И если уж мы столько сил потратили на принудительный кеш и его облагораживание, то почему бы не поделиться им с кем-то еще? Юзер-интерфейс тут главное. Фича не только должна быть, но ей должно быть удобно пользоваться: открывать разные версии страницы, удалять или сохранять версии страниц, анонсировать их как публичный кеш, делать выборку страниц и выгружать локальные версии сайта (страниц, по которым ходили), делать что-то вроде mht с рабочими ссылками, чтобы их можно было открывать на других устройствах, а не только они оседали где-то во внутренних хранилищах браузера, как происходит в некоторых мобильных браузерах.

Чтобы ускорить загрузку страниц и застраховать себя от нежданных инъекций кода, то различные скрипты, такие как jquery и ему подобные, хранящиеся на разных CDN, можно подгружать прямо с локального диска, как это делает расширение Decentraleyes. Загрузка шрифтов и икон-паков станет мгновенной. Узнать больше о том, что уже есть: https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/. Разумеется, неплохо бы сделать инъекции своего кода, по аналогии с browser.js или Grease Monkey, чтобы можно было изменять/исправлять код сайтов. Нет, не костыли в виде плагина, а нативную поддержку, которая не будет тормозить, как это когда-то было в Опере. Но увы, сейчас удобных средств для патчинга кода сайтов просто нет. Ричард Столлман называет это “тивоизацией” сайтов, но об этом будет написано в разделе о подписях кода.

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

Распределенное хранилище

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

У самой же CloudFlare есть интересная технология RailGun: https://www.cloudflare.com/website-optimization/railgun/ - это крутой костыль, который позволяет кешировать не кешируемое, при помощи которого они не просто кешируют старые версии страниц, а еще делают diff-ы с ними и отсылают разницу на основной сервер. Таким образом получается, что обновлять страничку всего 1 пакетом данных в 400 байт (число взято из описания), а оригинальный сервер может хоститься хоть на телефоне (на самом деле это не так). Но за такую штуку надо платить, от $200 в месяц, что очень существенные деньги для небольших сайтов.

Эх, а если бы можно было разделить контент на небольшие управляемые элементы… Но да, об этом позже. Пока есть костыли вроде diff и cloudflare с его Railgun.

А вот разделенная файловая система ipfs уже существует. А еще существует zeronet, который уже прямо сейчас, из коробки, позволяет хостить вебсайты распределенно. <вставить рекламу="" тута="">

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

Улучшенная работа с сетью

Вы можете себе представить, что иногда люди выходят сеть через разные GSM-модемы, где и без того невысокая скорость дорезается плохими условиями приема сигнала / плохими условиями договора? И существуют сайты вроде https://imgur.com/a/XJmb7, где лежат ну очень красивые вещи, но и вес самой странички, включая всю графику, превышает ____. Вот только проблема - такие странички невозможно посмотреть при таком соединении.

Сегодня браузер пытается грузить все картинки одновременно, замедляя загрузку каждой из них (для этого еще делают кучу суб-доменов, чтобы обойти лимиты на количество соединений). Через какое-то время наступает таймаут и сервер просто закрывает соединение, оставляя нас с битыми картинками, которые хорошо если вообще как-то откроются. Если нажать F5, то на мгновение произойдет отрисовка (отмена загрузки и отображение того, что успело прогрузится), а потом загрузка пойдет с самого начала, без докачки индивидуальных изображений. А еще вы ведь часто замечали, что браузер “загружает” страничку или файл сначала со скоростью в 50кб/сек, потом в 20кб/сек, а потом 3кб/сек? Это значит, что реальная скорость загрузки по какой-то причине стала равна 0 байт/сек, а оборвать соединение и начать заново черевато большими сложностями, даже если технически докачать файл возможно.

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

И раз уж мы выдаем клиенту метаданные о файлах, то можно оформлять всю страницу как “одну большую раздачу” в виде одного пакета с данными, внутри которого будет указана как информация о странице, так и о файлах-картинках, стилях, связанных страницах и прочих референсах (в том числе на другие “раздачи”), эдакий маленький бинарный sitemap. Это позволит лучше кешировать/прекешировать сайты, быстрее загружать все ресурсы, не дожидаясь полной прогрузки страницы или скриптов и даже оптимизировать сайта для людей с ограниченными возможностями, предлагая им расширенную навигацию по страницам. Или не загружать какие-то элементы сразу, к примеру Эппловые иконки на половину экрана или множество видео.

К сожалению, современные разработчики пытаются бороться с этими проблемами по-своему, не предоставляя настроек и реализуя все это собственными руками, т.е. “как получится”. К примеру, подгрузка картинок/видео через кучу JS, множество доменов и обработку скроллинга страницы, из-за чего быстро промотать страницу до “десятой страницы” уже нельзя, что меня очень сильно бесит. К счастью, некоторые крупные вендоры, такие как Сяоми начали с этим бороться, спрашивая каждый раз «Вы хотите воспроизвести видео? За это можеть сниматься дополнительный трафик!», но пока нельзя настроить автоматический запрет подобные безобразия, да и способов обхода со стороны разработчика все еще много.

Скачивание сайтов

Допустим, я нашел сайт с мануалами по выращиванию клубники. Восхитился, загорелся идеей, поехал на дачу и… И столкнувшись с проблемами понял, что надо было каждую страничку сконвертить в PDF, а только потом ехать на дачу. Почему в PDF? Да потому, что современные странички даже поштучно не хотят сохраняться корректно, а что будет отображено при открытии локального HTML и куда оно напихает Cookie остается только гадать.

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

Но что будет сегодня, если я попытаюсь сделать так? Меня ждет открытие, что в современных сайтах странички динамические, у каждой страницы есть тысяча URL-ов и я легко выкачаю три странички 10000 раз, тщательно их перелинкую, а при просмотре до нужной странички так и не дойду, даже если она будет скачана (по пути из 50 ссылок, который я должен буду пройти точно так же, как это сделала качалка).

А если очень хочется? В таком случае мы сегодня берем и пишем парсер сайта, выковыриваем контент (регулярками или xpath), как-то это перелинковываем, приделываем индекс, может быть даже простейший поисковик. Все это занимает от 1 дня, до тех пор, пока не надоест. Можно просто накопипастить текст в Ворд. Можно включить записывалку видео и листать странички - менее затратный вариант по времени, хоть и весить такая запись будет много.

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

И не надо думать, что современные сайты в принципе невозможно выкачать. Наоборот, в моду снова входит статика, есть даже интересные и популярные проекты вроде https://github.com/jekyll/jekyll для генерации статики. Так почему бы не раздавать “исходники” сайта?

Дисклеймер: Teleport Pro тут используется лишь как наиболее известная софтина для выкачивания сайтов, это ни разу не реклама или ностальгия, лично я его недолюбливал из-за кучи временных файлов и неумение корректно парсить javascript. Моим выбором были другие качалки, не так широко известные, вроде webzip, которые хоть и требовали кучу ресурсов, вставляли рекламу в странички, но выкачивали контент корректно и полностью.

Летающие корабли

Очень долгое время MSIE не поддерживал position:float, за что его ругали. И как показывает практика - хорошо, что не поддерживал. Правда людей это не останавливало и они эмулировали его через JS с прыгающими менюшками, которые сохранились и по сей день.

Сегодня перекрытие элементов используется для всякого полезного: окна логина на весь экран, вылезающие во время просмотра страниц и которые нельзя убрать (facebook), всплывающие ассистенты, оказывающиеся чат-ботами, сообщения на весь экран о акциях и подарках, как я что-то выиграл, иногда просто мне показывают рекламу (само собой без рекламы, но и без кнопки закрытия), прозрачные попапы, которые не дают кликать по странице (pornhub), ну и апофеоз: мне рассказывают, что я должен отключить Адблок, которого у меня нет.

А вы пробовали распечатать любую страницу? А я вот достаточно часто “печатаю” PDF и мне хочется бить тех, кто делают всплывающие растяжки вида “мы используем кукисы” или “вот тут брейкин-ньюз” где-то вверху или снизу экрана. Не, ну на экране это выглядит еще ничего, можно страничку поскроллить и как-то прочитать то, что они загораживают. А вы знаете, что эта гадость печатается на каждой странице? И что бумагу не поскроллить, что эта гадость загораживает часть контента, который никак не прочитать? Пока что я вынужден через инспектор элементов отламывать стили и только после этого я могу “распечатать” страницу. А вот если бы были простые управляемые элементы, то такого бы даже не случилось!

Зато внутри движка браузера можно детектировать, когда элемент перекрывает собой текстовую информацию и… Ну, к примеру, убирать его куда-то в сторону. Или вообще отламывать стили, объявляя их опасными. Вариантов масса. Можно представить страницу как слои и дать пользователю пару кнопок, чтобы “срезать” верхние слои или возвращать обратно - я джва года хочу такую функцию!

Забавно, но когда-то IE отказался от рендеринга тега blink, но он позволял из JS подвигать окно браузера и сделать незакрываемые попамы. Нынче даже отобразить текст в статусной строке уже сложно, проще ее эмулировать. Теперь я предлагаю что-то сделать с перекрывающими текст блоками, возможно как-то отломать эту функцию. И приходиться отламывать все больше фич, чтобы их нельзя было использовать во вред. Да, ради этого можно написать свой браузер.

Медиаконтент

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

Нет, когда-то давно я тоже хвалился, что могу написать крутой веб-плеер на флеше, причем сделаю это всего в 20 строк! Я крутой, я все могу! С возрастом же я начал задаваться вопросами:

1. Как бы покрутить яркость/контрастность в этом? А динамическую нормализацию?
2. Как бы переключиться в фулскрин? А если кнопки нет, так как ее забыли?
3. Как бы ускорить скучную лекцию на 3 часа?
4. Как бы покрутить эквалайзер? Лектора еле слышно, даже если выкрутить колонки
5. Как бы вырезать вооон тот кусочек и отправить его другу?
6. Как бы быстро вернуться назад, на пару секунд, не прицеливаясь мышкой в маленькую полосочку?
7. Как бы сделать так, чтобы оно выдавало более 15 fps?

Некоторые вендоры уже пытаются решить эту проблему. Проблему примитивных самодельных плееров с только базовыми фичами. К примеру, в Опере можно “отслоить” плеер от странички и управлять им отдельно. Есть youtube-dl, который позволяет не только выкачать видео из кучи сервисов, но и получить ссылку, чтобы ее можно было засунуть в нормальный плеер, хотя бы в VLC. <дописать чо="" еще="" есть="">

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

Для того, чтобы коннект к источнику видео не РВАЛСЯ и видео заново не скачивалось, мы можем открыть локальный прокси-сервер, как это делают торрент-клиенты, с перепаковкой видеопотока на лету, который используем для раздачи видео во внешнее приложение, а когда запрос придет - часть отсервим из кеша, а часть будем в реальном времени скармливать, согласно запросам приложения и возможностям сайта. Аналогично, любое видео/аудио можно будет легко сохранить в виде файла, даже если изначально оно представляло собой живую трансляцию или динамически генерируемый скриптами медиасорс и файлов как таковых даже не существовало. И не надо где-то в кишках страниц искать прямые ссылки, воевать с редиректами или включать тяжелую артилерию в виде записи видео с экрана - браузер должен быть для пользователя, а уж пользователь своего добьется, тут ему никто не помешает. Самое сложное тут, это пожалуй, инъекция в процесс Флеша. Но его жизненный цикл заканчивается, потому слишком часто он обновляться не должен.

Подпись кода

Многие из нас не задумываются, но в браузере может исполняться код разных людей, написанный под различными, в том числе и несвободными лицензиями. И не факт, что пользователь согласен с этими лицензиями. Это как вступать в сексуальные отношения без предварительного согласия. В принципе, в большинстве случаев ничего плохого не произойдет, но могут быть нюансы. Ричард Столлман написал отличную статью “Ловушка Javascript”, по мотивам которой было написано расширение LibreJS: https://en.wikipedia.org/wiki/GNU_LibreJS - это то, что должно стать отправной точкой в деле интерпретации Javascript в нашем браузере

Если бы указание лицензии было частью стандарта, жизнь была бы чуточку легче, но этого нет. Если бы авторы кода его подписывали своим публичным ключем, то я мог бы хотя бы доверять различным авторам, но нет и этого. Остается только хешировать скрипты, включая самые мелкие, вшитые в страницу и спрашивать пользователя “разрешить ли это?” для запуска каждого из них, ведя базу разрешенных или запрещенных скриптов. Что-то уровня антивируса. Тоже поиск “вирусни” по сигнатурам, но вместо эвристического анализатора - указание лицензии и вопросы к пользователю. На основе таких хешей можно не только обезапасить себя от вредоносного кода, но и построить систему версионирования. Создать инфраструктуру, где будет запускаться только тот код, которому вы доверяете!

Если вы еще не знакомы с замечательным трудом Ричарда Столлмана, то рекомендую почитать: https://www.gnu.org/philosophy/javascript-trap.ru.html (на русском языке).

Оценка сайтов / антирейтинг

Некоторые браузеры, такие как Опера, зачем-то пытались исправить каждый сайт руками, делая патчи через инъекцию кастомного кода. И однажды им это надоело, итог мы все знаем. Хотя они вполне заслуженно гордились своими достижениями, которые подтверждались в разных пузомерках, выполняя тесты на соответствие стандарту.

Но можно было пойти другим путем: вместо того, чтобы что-то патчить, писать кому-то на емейл, использовать личные связи и все такое, можно было бы выводить текст патча прямо поверх страницы со словами “автор этого сайта не придерживается стандарта, следующий код мог бы починить этот сайт”. Дернул вызов IE-only? Никакой эмуляции, вместо неё большой красный попап о профпригодности автора.

Можно пойти дальше: картинка на странице отображается как 100х100, а на самом деле 500х500? Красный попап с сообщением о том, что автор не умеет ресайзить картинки. Картинка с фотореалистичной графикой пожата в PNG? Красный попап о том, что автор не разбирается в форматах файлов. На странице нету ссылки на главную страницу? Красный попап с сообщением о том, что автор сайта не сделал нормальную навигацию

Конечно, красный попап выводить можно не всегда. К примеру, если PNG изображение можно лучше оптимизировать через optipng, то можно выводить просто красненький варнинг, как выводят их блокировщики рекламы. Нечто подобное уже делают различные CDN-оптимизаторы, которые и картинки пережимают, и код минифицируют, а на входе даже SQL-инъекции пытаются фильтровать. Но вся эта радость будет только в том случае, если автор заплатил денег и подключил соответствующие услуги, а что делать простому пользователю? А простой пользователь может просто отказаться от использования некачественного сайта, и его браузер должен ему в этом помочь.

Уже сейчас отчет блокировщиков рекламы, который выводит цифирки, можно считать неким антирейтингом сайта. Чем больше антирейтинг - тем хуже сайт и автору надо бы что-то с этим сделать. При некоторых значениях можно просто выводить варнинги о том, что посещение этого сайта может быть нежелательным. Причем я считаю, что браузер должен делиться своими находками с сообществом. Можно создать глобальный рейтинг каждого сайта, цепляя заветные цифирки к каждой ссылке, чтобы случайно не перейти куда-то туда, где пользователя ждет “плохой опыт”. Конечно, автоматизировать все нельзя. Поэтому можно создать несколько рейтингов, часть из которых будут вести живые люди, вручную проверяя код, проверяя их лицензии и качество кода, качество сайта в целом.

Копирование и вставка

Казалось бы, что может быть самой основной фунцией в программах, которые отображают текст? Работа с выделением/копированием/вставкой текста конечно же!

Увы, но даже с простым выделением уже начинаются проблемы. Вы пробовали выделить ссылку? В браузере, в почте, в ИМ? И как оно? Где-то ссылка начинает перетаскиваться, где-то осуществляется переход по ней, даже если вы не отпускали кнопку, а где-то надо целиться в миллиметровый зазор, чтобы иметь возможность выделить ее. Выделение картинок - отдельная лотерея, порой этого вообще нельзя сделать. Шаг вправо-влево - и у нас выделена вся страница, а не тот абзац, в который мы целились.

Со вставкой еще хуже. Будет ли сохранено форматирование или нет? Иногда это зависит от того, используете ли вы хоткей, или пользуетесь “колесиком” - разное поведение, для вроде бы одного действия. Будут ли пробелы в том, что вставляется в сторонние приложения, если между блоками не было пробелов? А иногда от форматирования не избавишься: вставляешь скопированный текст в пределах страницы, как правило в пределах набираемого письма, а набираемый абзац вдруго становится жирным или превращается в цитату.

Маленькие управляемые элементы

Так что же это за такие маленькие и управляемые элементы сайта, упоминавшиеся ранее? Чтобы было проще понять, давайте представим статичный json-файл с какой-либо информацией.

Маленькие потому, что представляют собой неделимые логические единицы. Это может быть ссылка в панели навигации, сниппет на описание товара, сам товар со всеми свойствами, комментарий пользователя, а то и целая статья. Это могут быть и какие-то отдельные виджеты сайта: поле поиска, корзина заказов, поле логина/разлогина.

Управляемые потому, что в отличии от цельнослепленного монолита, мы можем управлять такими данными: сортировать, выводить в прямом и обратном порядке, фильтровать или декорировать своими данными, создавая мешапы, которые в свое время наделали много шума. Почти за каждым сайтом стоит база данных, для управления которой используется SQL. За SQL стоит реляционная теория, реляционная алгебра и много-много методов управления информацией. И чуть ниже я покажу как можно было бы управлять информацией, и как мало нам дают авторы сайтов, если вообще дают.

К примеру, я пытаюсь найти работу на hh.ru и мне зачем-то выводятся десятки вакансий от Элитного Сочи. Я не знаю зачем, я очень далеко от этих ваших Сочи, да и продажами уж точно не занимаюсь. Но этих вакансий очень много, я вынужден скроллить их все дальше и дальше. Я не знаю зачем это было сделано. Специально ли люди занялись спамом, или просто малограмотные люди не разобрались и по ошибке опубликовали одну вакансию 100 раз. Ну, бывает такое, что люди свою глупость компенсируют усидчивостью. В любом случае, я вынужден все это скроллить. Если перейти сразу на несколько страниц вперед, то можно что-то пропустить - надо возвращаться назад. Это неудобно. К счастью, администрация ресурса взялась за ум и теперь такие “умные компании” можно поблеклистить. Спасибо им за это. А что делать, если бы не взялась? В том случае, если бы сервер возвращал такие сущности как “множество”, “схема множества” и сами данные, то браузер мог бы рендерить это локально, фильтруя надоедливых спаммеров.

Другой пример: мы все знаем, что лучше поиска чем у Google просто не существует. Но иногда он считает себя настолько умным, что выбрасывает из поискового запроса целые фразы, переводит их на разные языки и показывает то, что считает более полезным. Мне это не надо. Где галочка “перестань умничать, я тут главный”? А находится она по адресу https://bing.com/ - сразу включается более примитивный поиск, зато ищет ровно то, что мне надо и не умничает, не игнорирует мои ключевые слова, не игнорирует условия запроса. Если вообще найдет что-то, а если не найдет - честно об этом скажет, не пытаясь придумать что-то от себя. В том случае, если бы нам выдавали множества сущностей, то мы легко бы смогли соединить результаты поиска от обоих поисковиков в единую поисковую ленту.

При поиске товара в онлайн-магазинах зачастую интересуют несколько параметров, но отсортировать результаты выборки можно только по какому-то одному. Если вообще можно. Этим страдают даже крупнейшие торговые площадки. Если бы они возвращали сырые данные, то ими было бы очень легко манипулировать. На практике, надо открывать по 50 страниц и вручную сравнивать описания, подбрасывать монетки и надеяться, что покупка будет успешной. Есть и более интересные методы. Когда я покупал свой первый планшет, я выкачал описания 15000 товаров и парсил их регулярками в поисках нужных мне ключевых слов - было очень медленно, но я нашел свою любовь.

Но давайте вернемся к нашей клубнике. А точнее, к сайту с мануалами.

Представим себе, что инструкция по выращиванию клубники - это ресурс (пока еще в виде json-файла, для простоты), который можно запросить отдельно, внутри которого есть семантическая разметка, она расскажет нам на какие страницы оно ссылается и о типе связей. Никакой навигации, топов лучших советов или комментов других пользователей - только чистый контент. Конечно, сюда наверняка добавят рекламу и скрипты, но об этом позднее. Пока считаем, что у нас есть чистый контент, прямиком из базы данных (или даже из редактора контента). Такое легко выкачать, сложить, проиндексировать, не говоря уже о легкости кеширования и доставки контента. Такие элементы можно использовать для пре-кеширования как на CDN, так и в браузере, создания bulk-пакетов с контентом для эффективного сжатия и загрузки (чтобы не дергать отдельно каждую кнопку по 50 байт), для версионирования и архивации. Такие данные можно долго крутить-вертеть в браузере без какой-либо нагрузки на сервер, долго играться с сортировками и разными выборками. Самое смешное, что это все уже именно так и хранится в базах данных, внутри управляющих CMS. Но наружу все это подается через “монолитизатор”, который впечатывает данные в монолитный HTML, с которым потом очень сложно работать.

И все это не фантастика, все это сегодня уже существует! Первой ласточкой был RSS, который отлично справляется с ролью доставки сниппетов. Яндекс.маркет требует от магазинов выгрузки в специальном XML-формате, который содержит цены, картинки, данные о производителе и даже доставке. У других площадок свои форматы выгрузки, к примеру, Google Merchant использует немного модифицированный RSS2.0, но в целом эти форматы можно читать и делать рендерер уже сегодня.

Где брать счастье?

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

Баннеры и трекеры

Нет, сама реклама меня уже не раздражает: за годы сетевого присутствия у меня выработалась баннерная слепота, которая заключается в том, что я просто не вижу блоков на “видных местах”, равно как и блоков, которые написаны каким-то нестандартным шрифтом или просто большими буквами. Иногда доходит до смешного - я долго ищу кнопки “регистрация”, “скачать” или “новая тема”, так как их делают большими и заметными, а я их просто не замечаю. Порой до тех пор, пока мне не пришлют скриншот с обведенной кнопкой. Да и не вопрос трафика или скорости это. На сегодняшний день это вопрос безопасности, так как во-первых, баннерная реклама представляет из себя исполняемый код, а значит это не только утечка персональных данных для так называемого “таргетинга” и отслеживание всего, а фактически просто дыра в безопасности, через которую можно залить сплойт или просто майнер. Если раньше можно было сказать “не ходи по порносайтам и все будет хорошо”, то теперь “порносайт” встроен почти в каждый сайт, в каждую страницу.

Но особую боль мне доставляют трекеры, причем активные, работающие на странице постоянно. Примером такой гадости я могу считать Яндекс.метрику, от нее невыносимо тормозило всё. Стоило забанить домены Яндекса и моя жизнь наполнилась счастьем, так как сайты вдруг перестали тормозить и я даже перестал думать о апгрейде.

Решение очень простое: возможность указания “дружеских доменов” для сайта и отключение запросов ко всему остальному. Так можно резать рекламу при помощи Request Policy или аналога, что в отличии от AdBlock-образных резалок будет работать на практически каждом сайте, не потребует подписок и поможет даже в том случае, если сайт был взломан и на нем размещена связка.

Реклама (таргет-профиль)

Осуждаешь? Предлагай! Да, я осуждаю практику сбора таргетированных данных, особенно при помощи слежки и тому подобных нехороших (для меня) приемов. Почему бы не указать таргетинговые данные прямо в браузере? Я сам все о себе расскажу, не надо никакой слежки и вирусов:

Пол: мужской Возраст: 55 лет Образование: среднее-специальное Увлечения: fisting, bdsm, shemale, chastity devices, gasmask breath control Место жительства: Klyuchi (a settlement) in Ust-Kamchatsky District of Kamchatka Krai Последний чек в магазине: 28 рублей (батон хлеба) Финансовое состояние: денег нет, живу на пособие и личным огородом Отношение к фримиум-продуктам: пишу негативные отзывы о них, ставлю колы Профиль в социальных сетях: нет и не будет Кредитная карта: нет и не будет

С нетерпением жду предложений, которыми я смогу воспользоваться, с учетом своего профиля.

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

Встроенная поддержка прокси-листов/VPN

К сожалению, некоторые глупые люди решают за меня, могу ли я пользоваться тем или иным сервисом, причем делают это на основе того, в какой стране я родился/живу. К примеру, использовать Spotify я могу только в том случае, если живу в USA, а вот сервис Advcash я могу использовать в том случает, если я НЕ живу в USA. Конечно, если тебе не повезло при рождении, то не обязятельно прозябать в отсталой стране, в теории можно уехать в нужную страну, а вот как жить в 2-х странах одновременно - я пока не знаю.

Решение: встроенный механизм VPN, причем он должен настраиваться для каждого сайта отдельно. Для кого-то я буду только немцем, для кого-то американцем, а покупки я буду делать из той страны, для которой предлагают более низкие цены.

Всякое разное:

Иногда попадается контент, нарезанный на тайлы. К примеру, это могут быть спутниковые карты или фотографии. В принципе, это можно выковырять из браузера уже сегодня, но что дальше? Смотреть в виде отдельных тайликов это неудобно. Склеивать? Чем и как? Конечно, я могу написать брутфорсилку, которая будет сравнивать края тайлов и искать варианты для бесшовной склейки, но тут можно ошибиться, а если браузер будет дополнительно сохранять в кеше информацию о том, где и какой тайл находился относительно других тайлов, то склейка будет быстра и безошибочна! Можно приделать удобный экспорт тайлов прямо из кеша или текущей страницы.

Браузерные части как сервисы

Практически в каждом браузере есть утилита для скачивания файлов. Эта та штука с кривым интерфейсом, что качает файлы в какую-то непонятную директорию, не умеет в докачку, а потом еще говорит, что внутри файла обнаружены вирусы. Но эта штука есть, и что самое главное, она часть браузера, а значит использует кукисы и прочие аттрибуты сессии. Это значит, что авторизовавшись на каком-либо сайте, нам более не надо будет выковыривать кукисы для того, чтобы их засунуть в wget или curl. Браузер сам может выступать как такая утилита, полностью поддерживая текущую сессию. А это значит, что мы можем изначально вести разработку как сетевой подсистемы, так и вот такого самодельного curl-а с единой кодовой базой и слабой связностью с основным кодом браузера, но об этом позже.

Почти в каждый браузер встроен примитивный листер файлов, который умеет отображать содержимое директорий локального диска. Делает оно это криво, но это зачастую гораздо лучше, чем совсем ничего. А вот старая опера умела шарить……………………………..дописать про просраную оперу

В браузере может быть почтовый клиент, который было бы неплохо использовать из командной строки, с ведением подробной истории. Это бы позволило автоматизировать массу задач, начиная от разгребания спама, до рассылки напоминаний. Напоминания же можно брать из встроенного сервиса RSS.

Браузер по частям

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

Работу с сетью тоже можно вынести в отдельный демон. Рядом можно вынести днс-ресолвер со встроенным блеклистом доменов и автообновлением списков блеклистов, подсистему кеширования контента и кучу всего еще. Даже рендеринг можно вынести в отдельный процесс, как это было в Opera Mini (и что можно провернуть, использовав слитые исходники, так как напрямую этот код в проект даже не попадет, а будет сторонним “плагином”, то и лицензионная чистота тоже сохраняется).

На первых порах все это можно реализовать как независимые микросервисы, причем один разработчик может писать на java, другой на python, а третий на Ruby и им не надо ссориться, выбирая стек технологий. Ведь всем знакома ситуация, что кто-то не может представить браузер на Java из-за тормозов, кто-то боиться Сишку из-за боязни уязвимостей, а кто-то хочет попробовать модный Go и агитирует за него? Здесь каждый сможет выбрать для себя небольшую часть и отвечать строго за нее, договариваться надо будет только о коммуникационном протоколе.

Само собой, предполагается написание огромного количества плагинов. Букмарки, в том числе синхронизирующиеся через облака или сервисы рекомендаций, многоуровневые вкладки с превью и автозаполнение форм на основе нейросетей - все, что душе угодно. Быть может, у кого-то есть под рукой исходники многопоточной качалки файлов (или кто-то что-то такое видел на гитхабе), кто может начать портировать этот код под новую платформу прямо сейчас?

И конечно же, здесь можно следовать старому принципу: пусть каждая программа делает 1 своё дело, но делает его хорошо. Браузер - это очень сложный комплекс программ, работающих с сетью, а отсюда и сложность всей системы в целом. Так может быть просто разделить наш браузер на максимальное количество частей, обеспечивая качество и надежность каждой из них?

Плагины как гарантированные функции

Часть плагинов можно сделать дефольными в инсталляции. Например, плагины для обеспечения работы вкладок, скачивания файлов, плагин для адресной строки с автозаполнениями, помпонами и драконами, и тому подобных вещей, которые и так есть в любом браузере. Но я предлагаю пойти немного дальше и включать в дефолтную поставку немного больше. Конечно, это скользкий путь, который может привести нас к Bloatware, но по моему мнению, надо не бояться экспериментировать (конечно, не как это делает Mozilla, включающая дырявые расширения от разных партнерок без возможности отключения).

К примеру, вы помните в IE6 такую непонятнкую кнопочку как Discuss? Она появлялась после установки MS-офиса, практически никогда не работала, так как для ее работы был нужен серверный SharePoint. А ведь штука была отличная: при ее нажатии открывался тулбарчик, через который можно было добавлять комментарии к странице, был еще какой-то древовидный чатик (хотя я уже плохо помню все это, а нагуглить не смог), причем работало это с любой страницей. Только представте: комментарии на любом сайте, без модерации авторов, где смело и прямо в лицо можно высказать о любом сайте все то, что ты думаешь. Я считаю, что такой плагин просто обязан был в комплекте нашего браузера.

Другой пример: многие сайты открывают на страничке “схема проезда” карты гугла или яндекса, причем это считается хорошей практикой, никто даже не задается вопросами приватности и уж тем более не спрашивает пользователя? Хочу ли я, чтобы сторонняя организация знала, какие объекты в городе меня интересуют? Такие элементы можно вырезать и заменять на карты OSM или даже карты локального репозитория.

Деньги

Я думаю, что можно привлекать пожерствования на развитие браузера. Причем делать это не вслепую, как это делает Mozilla, а с указанием, на какую именно часть проекта пойдут средства. У нас получился неудобный интерфейс для вкладок? Давайте соберем деньги на новый бюджет и наймем разработчиков, которые сделают этот интерфейс более удобным. Само собой, плагинов для отображения вкладок может быть великое множество, и если кто-то написал неудобный и даже получил за это деньги, то это не значит, что браузер будет обречен.

В качестве эксперимента я хочу оставить тут эти кошельки, на которые буду принимать пожертвования ………………………………………

Но на данном этапе самое главное - это люди. Пишите свои идеи, мысли, а если можете помочь проекту кодом или макетами - смело предлагайте свою помощь.

Частичная репликация

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