Вот поэтому браузеры и жирнеют всё время, из-за вот такой парадигмы
Ну то что они стали весить больше — не страшно. Зато они быстрее. Проблема в том, что сайты сильно потяжелели. Старомодные сайты на ноуте 13-летней давности в современном браузере работают не хуже, чем раньше. JS выполняется сильно быстрее. Проблема в том, что требования у среднего сайта сильно выросли. Запихнуть целое видео в фон — сегодня в порядке вещей. Мегабайты кода на JS для одной страницы — как нечего делать. Когда 13 лет назад даже 50 килобайт jQuery казалось, что уже «много».
А если бы оно было модульным
То пользователь запарился бы всё это обновлять, плюс никакая кроссплатформенность, плюс проприетарность таких расширений, плюс плохая интеграция. ActiveX и NPAPI для своего времени были OK, но показали себя они плохо, сейчас они не нужны, все необходимые фичи в вебе нужно обсуждать и принимать в виде открытых стандартов, а не «мы тут подумали и сделали для вас вот этот бинарник, установите, и надейтесь что оно не скомпрометирует всю вашу систему, а как оно работает мы вам не расскажем и не покажем».
Когда я говорил про «плагины», я имел в виду «расширения». Я ещё ни разу не видел людей, которые тосковали бы по ActiveX и NPAPI плагинам. Обычно тоскуют по старым расширениям, которые модифицировали интерфейс Firefox.
То что от ActiveX и NPAPI отказались — это однозначно хорошо, тут даже обсуждать нечего. Не нужны в вебе эти нестандартные примочки. Всё что нужно для веба должно быть прописано в открытых стандартах и встроено в браузер, а не приклеено кое-как к браузеру сбоку в виде какого-то бинарника, который ещё и не везде доступен.
Единственное, что в идеале следовало бы перед отказом как-то договриться с Adobe, чтобы она сделала WebAssembly-версию Flash, но это уже энтузиасты делают.
Потому, что нормальный софт не должен ломать обратную совместимость при обновлениях.
Для этого они и отказались от старых плагинов. Старые плагины постоянно ломались, так как для них не было какого-то специального API, все плагины просто работали с потрохами браузера напрямую. Сейчас ввели специальные API для расширений. Больше ограничений (невозможно придумать стабильные API на все случаи жизни), но зато при обновлениях браузера риск поломок минимален.
Ну эту идею и пытаются реализовать через WebExtensions. Просто взять и сделать задокументированные и поддерживаемые стабильные API на все случаи жизни невозможно.
Я вот делал расширение Advanced Locationbar, которое внедрялось в стандартную адресную строку и сильно меняло её поведение. Для таких трюков нужен полный доступ к внутренностям, какого-то стабильного API тут не придумаешь.
На самом деле, в Firefox Developer Edition всё ещё можно запускать «экспериментальные» расширения с полным доступом к потрохам, но этой возможностью почти не пользуются.
Нет, сохранить былую гибкость, не давая полный доступ ко всем потрохам браузера, было невозможно. А с полным доступом к потрохам браузера никуда не девается проблема, что расширения опираются на детали реализации браузера, так как в нём всё «public» и любой код имеет доступ вообще ко всему. По сути, любое невинное изменение в коде Firefox типа переименования переменной, которая вообще никогда не предназначалась для использования в расширениях, могла вдруг ломать какие-то расширения, так как их разработчики сами её нашли и начали для чего-то использовать.
XUL был просто языком разметки, как и HTML. На одном только языке разметки полезного расширения не сделаешь. Когда пользователи говорят про XUL, они обычно имеют в виду XUL+CSS+JS. На самом деле, в Firefox 57 был только отключён полный доступ к потрохам браузера из расширения, а XUL из него ещё до сих пор не вырезали целиком. Все эти годы XUL постепенно заменяют на HTML5.
Ну PHP стал слишком немодным. Наверное, из-за того, что слишком много людей «входило в IT» именно через этот язык, и они писали не самый лучший код. Появилась даже соответствующая стигма, мол PHP-шник — это уже приговор. Сейчас, кстати, я заметил, что изначально очень далёкие от IT люди пытаются попасть в IT уже через Python. До стигмы осталось 3, 2…
Плюс появился Node.JS (который тоже быстрый), много кому удобнее на одном языке писать как frontend, так и backend. Python во многом набрал популярности за счёт новых областей типа Data Science, где для этого первее всего появились удобные библиотечки. Ну и одобрение Google наверное сказалось. Первые лет 15 Python ведь не особо пользовался спросом (Python старше PHP), а потом вдруг пошёл вверх.
Ниша скриптовых языков не такая большая чтобы уместить всех, питон растёт, остальные стагнируют или падают.
Вряд ли Python сможет заменить JavaScript, который уже много лет держит первоеместопо популярности. Всё же веб слишком важен, и JavaScript (в паре с TypeScript) достаточно хорош, чтобы не было необходимости в браузеры добавлять поддержку других скриптовых языков.
Производительность тоже важна. Я как-то свои сайты перевёл с PHP 5.4 на PHP 7.4, где как раз заметно подняли производительность. Результат был заметен как на глаз (страницы изначально загружались с небольшой задержкой, а стали загружаться мгновенно), так и по нагрузке на сервер.
Сайты у меня маленькие, поэтому снижение нагрузки никак не сказалось на моих расходах, всё в пределах тарифа было изначально (но видимый невооружённым глазом прирост производительности порадовал). А вот если сайт очень популярен, то это позволило бы заметно экономить деньги.
Судя по тестам, PHP 7 гораздо быстрее Python 3. При этом, сложность разработки на Python и PHP примерно одинаковая, то есть не получится сказать, что разработка «более быстрого» сайта на PHP будет дороже, что нивелировало бы экономию на серверах.
Поэтому музыка и играет с плавающей скоростью, ведь она завязана на это прерывание. И да, для запуска игр эмулировать эту эмулировать совсем не нужно, вот эмулятор fceux и не учитывает её.
С аналогичной проблемой я столкнулся, когда делал Unchained Nostalgia, и FCEUX меня тоже подвёл, из-за чего в одном из релизов скорость музыки плавала на реальном железе.
На замену FCEUX нашёлся эмулятор Mesen, у которого тоже крутой отладчик, а главное — точная эмуляция, то есть проблемы реального железа корректно воспроизводятся. Плюс есть ещё функция перемотки времени назад (как в Braid), что иногда бывает весьма полезно. Сидел на FCEUX и его предках более 10 лет, но как-то легко перешёл на Mesen, когда распробовал его фишечки, уж очень он хорош.
Samsung обещает 4 года мажорных обновлений ОС (плюс год обновлений безопасности) для своих флагманов 2021-2022, что больше, чем обещает Google. К Galaxy Tab S8 это тоже относится.
Ну да, все потребности в электроэнергии уже закрыты возобновляемой энергетикой, поэтому будем спускать излишки в бессмысленный майнинг.
Солнечные панели и ветряки конечно же производятся на абсолютно безвредных производствах, и нет совершенно никаких проблем с их утилизацией после отработки положенного срока. Поэтому если их не хватает на майнинг, надо обязательно построить больше, потому что это же так полезно и необходимо человечеству.
Ну то есть всё что связано с майнингом в принципе не экологично, а значит маркетинговое заявление про экологичность — ложное. Обычная база была бы на порядки более экологичной.
Добавление 100 тысяч записей в базу — это крохи. На каком-нибудь телефоне в обычную базу можно добавить столько записей за несколько секунд, и сожрёт это энергии меньше, чем секунда работы чайника. Поддержание работоспособности такой базы и её доступность из сети тоже потребует на порядки меньше энергии, чем то что предлагается.
Кодировка UTF-8 изобретена в 1992 году, она была стандартизирована в январе 1993 года.
В июле 1993 года Microsoft, с выходом Windows NT 3.1, представила «широкий» API Windows, сделав ставку на кодировку UCS-2 (позже — UTF-16), а не на UTF-8. Это, как оказалось, было ошибкой, так как UTF-16 практически во всём уступает UTF-8. Правда, надо признать, что тогда некоторые проблемы не были особенно очевидными.
Разработка Windows NT началась в 1989, когда UTF-8 ещё не существовало, и UCS-2 казалась будущим. Очевидно, что ближе к релизу никто не стал бы переделывать все API на использование UTF-8.
То пользователь запарился бы всё это обновлять, плюс никакая кроссплатформенность, плюс проприетарность таких расширений, плюс плохая интеграция. ActiveX и NPAPI для своего времени были OK, но показали себя они плохо, сейчас они не нужны, все необходимые фичи в вебе нужно обсуждать и принимать в виде открытых стандартов, а не «мы тут подумали и сделали для вас вот этот бинарник, установите, и надейтесь что оно не скомпрометирует всю вашу систему, а как оно работает мы вам не расскажем и не покажем».
То что от ActiveX и NPAPI отказались — это однозначно хорошо, тут даже обсуждать нечего. Не нужны в вебе эти нестандартные примочки. Всё что нужно для веба должно быть прописано в открытых стандартах и встроено в браузер, а не приклеено кое-как к браузеру сбоку в виде какого-то бинарника, который ещё и не везде доступен.
Единственное, что в идеале следовало бы перед отказом как-то договриться с Adobe, чтобы она сделала WebAssembly-версию Flash, но это уже энтузиасты делают.
Я вот делал расширение Advanced Locationbar, которое внедрялось в стандартную адресную строку и сильно меняло её поведение. Для таких трюков нужен полный доступ к внутренностям, какого-то стабильного API тут не придумаешь.
На самом деле, в Firefox Developer Edition всё ещё можно запускать «экспериментальные» расширения с полным доступом к потрохам, но этой возможностью почти не пользуются.
Плюс появился Node.JS (который тоже быстрый), много кому удобнее на одном языке писать как frontend, так и backend. Python во многом набрал популярности за счёт новых областей типа Data Science, где для этого первее всего появились удобные библиотечки. Ну и одобрение Google наверное сказалось. Первые лет 15 Python ведь не особо пользовался спросом (Python старше PHP), а потом вдруг пошёл вверх.
Сайты у меня маленькие, поэтому снижение нагрузки никак не сказалось на моих расходах, всё в пределах тарифа было изначально (но видимый невооружённым глазом прирост производительности порадовал). А вот если сайт очень популярен, то это позволило бы заметно экономить деньги.
Судя по тестам, PHP 7 гораздо быстрее Python 3. При этом, сложность разработки на Python и PHP примерно одинаковая, то есть не получится сказать, что разработка «более быстрого» сайта на PHP будет дороже, что нивелировало бы экономию на серверах.
Нужно сбросить импортированные из телефонной книги контакты в Telegram. После этой статьи, для этого была добавлена такая функция в настройки.
На замену FCEUX нашёлся эмулятор Mesen, у которого тоже крутой отладчик, а главное — точная эмуляция, то есть проблемы реального железа корректно воспроизводятся. Плюс есть ещё функция перемотки времени назад (как в Braid), что иногда бывает весьма полезно. Сидел на FCEUX и его предках более 10 лет, но как-то легко перешёл на Mesen, когда распробовал его фишечки, уж очень он хорош.
Солнечные панели и ветряки конечно же производятся на абсолютно безвредных производствах, и нет совершенно никаких проблем с их утилизацией после отработки положенного срока. Поэтому если их не хватает на майнинг, надо обязательно построить больше, потому что это же так полезно и необходимо человечеству.