Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год? Да так, что уже видно что это тенденция и не хочется инвестировать время в то, что через год закопают. Сколько их было и есть? Silverlight, WinForms, XAML, Xamarin, Avalonia, вот сейчас всех на MAUI перетягивают.
Silverlight — не предназначался для разработки настольных приложений, это плагин для браузера, его закопали вместе с другими плагинами для браузеров.
WinForms — уже 20 лет живёт и развивается, но он никогда не был кроссплатформенным, это изначально обёртка над классическим WinAPI.
Xamarin — для мобил, переродился в виде MAUI с поддержкой десктопа.
XAML — это язык разметки, который до сих пор используется в том же MAUI.
Avalonia — не имеет отношения к Microsoft.
Ну как минимум таймеры и значения переменных восстанавливаются, проверил на radar.veg.by. Без восстановления состояния там бы таймер с обратным отсчётом сбрасывался бы до ближайших 30 секунд, как при перезагрузке страницы. Что-то более тяжёлое из современного вы там вряд ли заведёте уже. Возможно, в каких-то случаях оно работало плохо или с ошибками, я не знаю. Оперой как основным браузером никогда не пользовался, только тестировал в ней свои сайты. Иногда сталкивался с неприятными багами в неожиданных местах при этом. Возможно, вы тоже сталкивались с какими-то ошибками в реализации.
Думаю, со временем от открытия HTTP-версии сайта по умолчанию откажутся. Если сайт не доступен по HTTPS, пользователю нужно будет явно согласиться с тем, что он хочет на незащищённую версию. Такой режим в браузерах уже есть, просто он не включён по умолчанию.
Max 2, купленную в 2019-м, тоже уже перестали поддерживать, последний апдейт был прошлым летом. Выйдет какой-нибудь TLS 1.4, потом пяток версий хроме, и всё, приплыли.
Не надо преувеличивать. Современный Chrome поддерживает Android 6+, который стоит на устройствах 7-8 летней давности. Вместе с собой он тащит поддержку новых протоколов и в том числе и свежие сертификаты. Firefox делает так же.
До сих пор актуальный TLS 1.2 доступен нативно даже в древней Windows 7. Когда открываешь HTTPS-сайты в IE11, они обычно ломаются не из-за слишком нового TLS, а из-за совершенно других вещей, потому что мир не стоит на месте, и ожидать, что современные сайты будут нормально работать в древних браузерах как-то странно.
Чтобы первый запрос не ушёл по голому HTTP, можно создать DNS-запись HTTPS, через которую можно настроить первое обращение даже через QUIC (HTTP/3). Там же можно настроить Encrypted ClientHello, который позволяет скрыть хост и почти всю служебную информацию при установке TLS-соединения. Ну и чтобы сам DNS-трафик не перехватывали и подменяли, в браузерах есть DNS-over-HTTPS.
Под табличкой должна быть настройка что делать с «остальными» файлами. Эта настройка появилась вроде как не сразу, точно не знаю когда, но в Firefox 102 есть.
Оно и стало работать сильно быстрее. До этого весь JS в Firefox (все вкладки и интерфейс) работал в один поток. Один тяжёлый сайт мог повесить весь браузер. Конечно, можно было просто разнести по разным потокам JS вкладок и интерфейса (всё равно сломав совместимость с расширениями), но разнос ещё и по разным процессам давал больше плюшек (лучше безопасность и стабильность), поэтому пошли этим путём.
Всё необходимое в вебе должно приниматься в виде открытых стандартов, а не «мы тут с Васяном решили на коленке запилить такую фичу для веба, вроде кое-как работает, вчера даже перестало падать, нате вам нативный бинарник, установите его, и надейтесь, что оно не скомпрометирует вам всю систему».
Вот поэтому браузеры и жирнеют всё время, из-за вот такой парадигмы
Ну то что они стали весить больше — не страшно. Зато они быстрее. Проблема в том, что сайты сильно потяжелели. Старомодные сайты на ноуте 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 будет дороже, что нивелировало бы экономию на серверах.
WinForms — уже 20 лет живёт и развивается, но он никогда не был кроссплатформенным, это изначально обёртка над классическим WinAPI.
Xamarin — для мобил, переродился в виде MAUI с поддержкой десктопа.
XAML — это язык разметки, который до сих пор используется в том же MAUI.
Avalonia — не имеет отношения к Microsoft.
До сих пор актуальный TLS 1.2 доступен нативно даже в древней Windows 7. Когда открываешь HTTPS-сайты в IE11, они обычно ломаются не из-за слишком нового TLS, а из-за совершенно других вещей, потому что мир не стоит на месте, и ожидать, что современные сайты будут нормально работать в древних браузерах как-то странно.
То пользователь запарился бы всё это обновлять, плюс никакая кроссплатформенность, плюс проприетарность таких расширений, плюс плохая интеграция. 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 будет дороже, что нивелировало бы экономию на серверах.