#заметка дня
Давайте разбираться, что же не так с Safari и почему он отстаёт.
История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.
Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.
В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.
Но двум мощным корпорациям недолго работалось настолько плотно вместе и в 2013 году уже Google форкнули WebKit, создав Blink. Некоторое время рендеринг в движках не сильно отличался, но время шло.
В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.
Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).
Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.
Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.
Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).
А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.
Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.
Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)
#apple #webkit #safari #wsl
Давайте разбираться, что же не так с Safari и почему он отстаёт.
История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.
Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.
В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.
Но двум мощным корпорациям недолго работалось настолько плотно вместе и в 2013 году уже Google форкнули WebKit, создав Blink. Некоторое время рендеринг в движках не сильно отличался, но время шло.
В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.
Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).
Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.
Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.
Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).
А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.
Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.
Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)
#apple #webkit #safari #wsl
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
#инструмент дня
Тут недавно в комментариях проскочил вопрос, чем так удобна командная оболочка zsh (Z shell) и набор расширений к ней Oh My Zsh. Чем оно лучше bash и вообще — ну зачем?
Ну короткий ответ — Tab умнее :)
Длинный — плагинами! Я не буду распыляться сейчас вообще, просто покажу один из свежих: автодополнение по npm-скриптам! Поддерживаются npm, yarn и pnpm.
Видео говорит само за себя, но что конкретно мне нравится — отображается не только команда, но и сам скрипт!
https://github.com/grigorii-zander/zsh-npm-scripts-autocomplete
Я сам только начинаю путь в zsh, но дефолтные настройки того же Oh My Zsh очень удобные.
#zsh #plugin #tool #linux #macos #wsl
Тут недавно в комментариях проскочил вопрос, чем так удобна командная оболочка zsh (Z shell) и набор расширений к ней Oh My Zsh. Чем оно лучше bash и вообще — ну зачем?
Ну короткий ответ — Tab умнее :)
Длинный — плагинами! Я не буду распыляться сейчас вообще, просто покажу один из свежих: автодополнение по npm-скриптам! Поддерживаются npm, yarn и pnpm.
Видео говорит само за себя, но что конкретно мне нравится — отображается не только команда, но и сам скрипт!
https://github.com/grigorii-zander/zsh-npm-scripts-autocomplete
Я сам только начинаю путь в zsh, но дефолтные настройки того же Oh My Zsh очень удобные.
#zsh #plugin #tool #linux #macos #wsl
👍12🤔3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
#инструмент дня
Тут недавно в комментариях проскочил вопрос, чем так удобна командная оболочка zsh (Z shell) и набор расширений к ней Oh My Zsh. Чем оно лучше bash и вообще — ну зачем?
Ну короткий ответ — Tab умнее :)
Длинный — плагинами! Я не буду распыляться сейчас вообще, просто покажу один из свежих: автодополнение по npm-скриптам! Поддерживаются npm, yarn и pnpm.
Видео говорит само за себя, но что конкретно мне нравится — отображается не только команда, но и сам скрипт!
https://github.com/grigorii-zander/zsh-npm-scripts-autocomplete
Я сам только начинаю путь в zsh, но дефолтные настройки того же Oh My Zsh очень удобные.
#zsh #plugin #tool #linux #macos #wsl #бородач
Тут недавно в комментариях проскочил вопрос, чем так удобна командная оболочка zsh (Z shell) и набор расширений к ней Oh My Zsh. Чем оно лучше bash и вообще — ну зачем?
Ну короткий ответ — Tab умнее :)
Длинный — плагинами! Я не буду распыляться сейчас вообще, просто покажу один из свежих: автодополнение по npm-скриптам! Поддерживаются npm, yarn и pnpm.
Видео говорит само за себя, но что конкретно мне нравится — отображается не только команда, но и сам скрипт!
https://github.com/grigorii-zander/zsh-npm-scripts-autocomplete
Я сам только начинаю путь в zsh, но дефолтные настройки того же Oh My Zsh очень удобные.
#zsh #plugin #tool #linux #macos #wsl #бородач
❤16👍1