Новий хаб «Chrome Extensions»

  У класифікаторі хабів сталося зміна . Всі численні статті про розширення Хрому тепер можна помітити цим хабом , що закликаю зробити авторів раніше написаних статей. Крім цього, з нагоди свята, хотів би написати огляд про історію розширень і юзерскріптов Хрому, про те, як вони сформувалися і до якого виду прийшли.
 
 
 Запекла, але сумнівна поросль: різальники реклами
Спочатку, багато років тому, в роках 2000-2005-х, розширень браузерів в тому вигляді, в якому ми бачимо їх зараз, не було. Скрипти в браузері малися на увазі написаними неодмінно авторами сайту і сторінки, що спостерігається в браузері. Здавалося б, нічого дивного в цьому немає — автори сайту мають повне і безроздільне право користуватися ресурсами браузера… стоп. Найшла коса на камінь. Чому автори сторінки повинні користуватися ресурсами мого браузера? Писати свої довільні скрипти, що не дають показати зміст своєї ж сторінки? Відволікати невдалими стилями від змісту своєї сторінки? А реклама на ній?
 
І заробила допитлива думка користувача. Мій браузер — він за визначенням має приносити зручності мені, а не просувати інтереси власника сайту, який я зараз розглядаю. Ні, є, звичайно, і мазохісти, які відстоюватимуть право автора сайту, не будучи авторами, але не всі будуть згодні з ними. Приклад — надлишкова або не дуже, реклама, що не відноситься до змісту, заради якого прийшов читач. Або недосконалості або помилки в оформленні сторінок. Або бажання читача бачити додаткову інформацію на тій же сторінці. Все це призводить до бажання мати поруч із браузером механізм, переробний деякі частини сторінок.
 
 Наприклад, найраніші приклади переробки сторінок реалізовувалися як локальний проксі-сервер, через який пропускалися сторінки для фільтрації її вмісту, в основному, для видалення реклами. Історія пам'ятає спроби позовів власників сайтів проти творців цих програм. Наприклад, був легендарний представник цього класу програм, Proxomitron , автор якого в червні 2003 р. відмовився від підтримки і розвитку своєї програми з причини тиску на нього, що загрожував вилитися в судові переслідування. Таких прикладів було кілька, але вже через пару років програм-проксі була така кількість, що боротися з ними стало безглуздо, а реальних прикладів боротьби практично не було — існували тільки деякі програми, які припинили розвиток.
 
При цьому зовсім не обов'язково мова, на якому писався парсер рекламних вставок, був Javascript. Мова адблокеров був і є декларативний і спеціалізований, він таким залишився і в найвідомішому AdBlock Plus — Блокери, який сформувався вже в еру Javascript-розширень браузерів. Водночас, парсити вхідні сторінки в проксі-сервері програма-блокер могла і на Python, наприклад. Основне призначення блокерів — різати частині сторінки, максимально ефективно відшукуючи непотрібні, не порушуючи при цьому каркас (розкладку) сторінки.
 
Детальніше про сучасних взаєминах блокерів і рекламодавців (англ.) www.computerworld.com/s/article/9245190/Ad_blockers_A_solution_or_a_problem_ .
 
 Користувальницькі стилі
Інший клас ідей по впливу на сторінки — модифікація сторінок. оскільки у великій мірі на відображення впливають правила CSS, виникла наступна ідея — наточити в безліч правил CSS свої правила користувача. До речі, вони можуть частково виконувати завдання за переховування непотрібних блоків, хоча не так ефективно, як різальники HTML. Але у них є плюс в тому, що правила стилів продовжують впливати на сторінку і при динамічній модифікації DOM (структури елементів сторінки), що все більш типово в останні роки, починаючи приблизно з рубежів 2008-2009 років. До того ж, модифікатори стилів виконують не тільки руйнівну, але й оформлювальну роль, можуть покращувати або просто змінювати вихідний стиль сторінок. Можливість установки користувача стилів введена навіть в браузер IE6 («Accessibility — Format documents using my style sheet» в настройках) і в Windows Mobile 3003 (через реєстр).
 
Примішування стилів нескладно провести і через включення правил CSS в HTML методом роботи з проксі-сервером.
 
 Користувальницькі скрипти
 Проксі-сервером можна не допустити впровадження скриптів Javascript у сторінку сайту, але не можна модифікувати подальші зміни DOM (якщо не рахувати випадку впровадження власноруч написаних скриптів замість або на додаток скриптів сайту). Для полегшення доступу скриптам в простір сторінки з плином еволюції браузерів винайшли користувальницькі скрипти. Перша версія аддона Greasemonkey браузера Firefox з'явилася в березні 2005 року і дозволяла писати короткі й прості користувальницькі скрипти. Точніше, модифікувати поведінку браузера (плагіни Internet Explorer, аддони і плагіни Firefox) можна було і раніше, але все питання був у трудомісткості втручання, у підтримці способу втручання з появою нових версій браузерів і в сумісності користувальницького плагіна з іншими. Коло технологій і поріг входження методично зменшувалися, щоб невеликий вплив на сайт за допомогою свого скрипта було простим і щоб воно не конфліктувало по можливості з процесом розвитку браузера.
 
Знову ж, немає причин відмовлятися від проксі-серверів для впровадження скриптів. Адже юзерскріпти фактично запускалися спочатку в момент закінчення завантаження вебсторінки, і це було гірше, ніж впровадження тегів з включеннями скриптів, тому що всі інші теги з скриптами сайту встигали запуститися і виконатися. При бажанні, скрипт сайту міг би протидіяти юзерскріптам успішніше, ніж вони — скриптам сторінки. Але жоден скрипт при цьому не пригнічувався повністю, тому що кожен має власне локальне оточення змінних скрипта для свого виконання. (Конкурувати за загальні ресурси типу Global Scope і DOM, переписувати їх — так, можуть будь-які з цих скриптів.)
 
Ще один аргумент на користь включень проксі-сервера проти юзерскріптов — універсальність для різних браузерів. Будь браузер легко привчити працювати з проксі-сервером, але не всі браузери спочатку мали механізм впровадження юзерскріптов в своєму арсеналі. Цікаво, що досить скоро все нові браузери порахували своїм обов'язком мати схожі механізми впровадження і підтримували стали стандартом де-факто функції Greasemonkey, крім браузерів сімейства IE, але й вони одержали б способи впровадження юзерскріптов за допомогою сторонніх програм. Правда, IE довгий час, до версії IE9 мав сильно відрізняється спосіб роботи з DOM на рівні Javascript, що визначило його ізольованість від основного потоку розвитку браузерів. У версії IE11 розробники браузера ці відмінності постаралися звести до мінімуму. Але проблема залишається в охопленні користувачів по платформах (операційним системам). IE11 може бути встановлений або постачається спочатку лише з системами windows 8 (з червня 2013) і Windows 7 (з листопада 2013). Користувачі інших ОС навіть не можуть встановити цей браузер, якщо не вважати використання віртуальних машин. Тому число потенційних користувачів браузера і юзерскріптов в ньому сильно обмежена політикою розповсюдження.
 
Схожа ситуація з обмеженістю поширення склалася і з браузером Safari з травня 2012 року, коли було випущено останнє оновлення Safari 5.1 для Windows і далі він на цій системі та інших, крім Mac OS, не розвивався. Але до цього моменту розробники могли розраховувати на досить велике охоплення користувачів юзерскріптов на платформах Windows і Mac OS.
 
У Опері 8.0 в квітні 2005 року теж з'явилася підтримка юзерскріптов , одночасно з Firefox. На відміну від нього, у Опери механізму аддонов ще довго не було, і встановлювати скрипти доводилося вручну (створювати файл зі скриптом) і через настройки браузера.
 
До всього, треба сказати, що користувачів юзерскріптов, юзерстілей і проксі-серверів було досить мало щодо загального числа відвідувачів сайтів. Здебільшого, ці технології зроблені гиками для гиків, а відносна простота установки скриптів через Greasemonkey — саме по собі велике і нетипове досягнення.
 
Проблема не тільки в тому, що скрипти приносять додаткову небезпеку доступу до даних користувача. Перша проблема — в тому, що переконати користувача зробити зайвий рух і встановити програму-надбудову — складне завдання, здійсненне приблизно для 1-5% від загального числа користувачів якого сайту. В основному адже власники сайтів намагалися робити їх зручними для користувачів, тому не часто була сильна необхідність у зміні функцій і оформлення.
 
Навіть аддони, про які мова нижче, які змогли зменшити дистанцію установки до 2 кліків, не змогли і не зможуть вирішити проблему довіри користувачів до сторонніх надбудовам. Всі надбудови залишаться маргінальними, поки є що викликає довіру власник сайту. А якщо довіри не буде — в інтернеті швидше з'явиться інший сайт з іншим власником, викликає довіру, ніж хтось буде масово «рятувати» перший сайт, цілком залежачи при цьому від сайту-донора.
 
 Аддони браузерів
Юзерскріпти, що запускаються після запуску скриптів сторінки не завжди влаштовували (їх нечисленних) користувачів. Скрипт сторінки встигав щось зробити непотрібне, попсувати зовнішній вигляд, майнути банером і взагалі — витратити час процесора на своє виконання. Тому у Firefox, починаючи з версій 0.Х був початковий підхід в ідеї побудови системи плагінів, простіших в написанні, ніж плагіни IE і чим нікуди не зниклі плагіни самого Firefox. Якщо завдання дозволяє обмежитися меншим колом технологій, ніж знання всього будови браузера, то вона вирішувалася в рамках побудови аддона (add-on) на базі технології XUL (XML User Interface Language), зробленої спеціально для роботи з Firefox, движком Gecko і заснованих на ньому продуктах.
 
З часом і цей підхід переглядався, і для аддонов Chrome, які отримали назву «extensions», вже не винаходили нову мову і технологію (аналогічно і Safari extensions). Все побудовано на HTML і Javascript API. З часом знадобилося створювати багато схожих надбудов, API множаться, частково дублюючись, в Chrome Apps, Chrome OS, але підхід не виглядає неповоротким і не створює специфічного порога входження. Поріг є, але він визначається будовою додатків як фреймворків (наприклад, потрібно знати призначення елементів файлу manifest.json) і кількістю функцій API.
 
 У підсумку
В результаті, в зоопарку браузерів отримали не дуже різноманітний, що вже добре, зоопарк аддонов, розширень і скриптів.
 
* Greasemonkey і Scriptish в Firefox — addons.mozilla.org / en-US / firefox /
* Юззерскріпти в Firefox, Chrome, Опері і Safari (з NinjaKit) — userscripts.org /
* Розширення старої Опери; нової Опери — addons.opera.com / en / extensions /
* Розширення Хрому — chrome.google.com / webstore / category / extensions
* Додатка Хрому — chrome.google.com / webstore / category / apps
* Розширення Safari — extensions.apple.com /
 
Можна згадати, вже в минулому часі, про розширення старої Опери, яких було відносно небагато, але вони були досить прості на рівні складності розширень Safari і Chrome. Нові розширення для нової Опери, побудованої на тому ж движку, що і Chrome, мають мінімум відмінностей за функціями від розширень Chrome. Швидше за все, там присутні обмеження через нереалізації специфічних особливостей браузера Chrome, але не відмінності в двигунах і API.
 
У відсотковому відношенні, найбільш активно розвивається гілка розширень Хрому. Це — і найбільш популярний і швидкий браузер, що працює скрізь, і добре развиваемое і гнучке API, і простота доступу до нього.
 
Як приклади, можна навести багато розширень, деякі з яких зроблені спеціалізовано для сайту Habrahabr і орієнтованих за останні 2 роки в першу чергу на Chrome.
 
Теорія:
 
     
Переводимо Chrome extension на manifest_version 2 , utf , 21 серпня 2012
 
 Userscripts. Пакуємо юзерскріпт для Chrome , MrMig , 14 жовтня 2011
 
 Доступ до JavaScript веб-сторінки з розширення для Chrome , Houston , 16 липня 2013
 
 Пишемо розширення для Google Chrome (і публікуємо його) , paththeir , 26 лютого 2013
 
За темою Хабра:
 
     
Chrome HabraMail Extension (і favicon method) , donnerjack13589 , 24 лютого 2010
 
 Google Chrome Extension Habrahabr.ru-Tools-PATCHED , Goder , 13 жовтня 2011 (і ще два, але автор — read-only)
 
 Google Chrome Extension: Друкуємо статті з habrahabr , Bookin 5 березня 2012
 
 Карма-розширення для Google Chrome , 404tesla , 23 вересня 2012
 
Інші:
 
     
Chrome extension за вихідні , brukva , 10 січня 2014
 
 Працюємо з API вконтакте з розширення для Google Chrome , crea7or , 27 лютого 2013
 
 Розширення Google Chrome: робимо гарячі клавіші , UZER2006 , 5 березня 2013
 
 Історія одного Google Chrome розширення , mamchyts , 26 жовтня 2013
 
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.