Боль фронтендера: Как я пытался перенести сложные инструменты в браузер без бэкенда и почему мобильный Safari — это новая кость в горле.

Всем привет!

Существует популярное мнение, что современные смартфоны по мощности догнали ноутбуки, а браузерные API позволяют собрать внутри вкладки чуть ли не полноценную операционную систему.

Наслушавшись этих сказок, я решил перенести свой хаб полезных повседневных инструментов (конвертеры, распознавание речи, сжатие картинок) целиком на фронтенд. Идея была красивой: никакого бэкенда, всё крутится прямо на устройстве пользователя. Полная приватность, данные не уходят на сервер, закрыл вкладку — всё стерлось.

Chrome на ПК сожрал это и даже не поморщился. Но когда я начал тестировать проект на мобильных устройствах, я попал в настоящий ад, имя которому — мобильный Safari. Если раньше разработчики проклинали Internet Explorer, то сегодня главный кошмар любого инди-хакера — это браузер от Apple. Ниже — честный разбор того, с какими техническими ограничениями приходится сталкиваться, если ты принципиально не хочешь заводить сервер и базы данных.

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

На Android в Chrome всё работает более-менее предсказуемо. Но мобильный Safari в iOS ведет себя как жесткий надзиратель. У него есть внутренний лимит на потребление памяти вкладкой (часто в районе 300–400 МБ). Стоит пользователю загрузить изображение чуть большего разрешения для обработки — Safari не выдает ошибку в консоль, он просто молча перезагружает страницу с плашкой «Произошла ошибка, страница была перезагружена».

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

Одна из самых популярных функций на моем сайте — перевод голоса в текст (распознавание речи). На чистом фронтенде это реализуется через браузерное Web Speech API. В Chrome на Android это работает идеально: встроенный движок от Google распознает русскую речь на лету, свайпы, паузы — всё четко. Но Apple развивает свои технологии обособленно.

В мобильном Safari это API то работает с багами, то требует обязательного удержания экрана активным, то некорректно обрабатывает аудиопоток из микрофона, если параллельно свернули вкладку. В итоге, чтобы условная функция диктовки работала одинаково хорошо и на копеечном Android, и на топовом iPhone, приходится городить километры «костылей» и условий if (isSafari).

На смартфонах пользователи привыкли к многозадачности: надиктовал текст, свернул браузер, зашел в Telegram скопировать адрес, вернулся обратно. Для статического сайта без бэкенда сворачивание вкладки на iOS — это почти всегда фатально.

Операционная система мгновенно «замораживает» процессы в Safari, чтобы сэкономить батарейку. Если в этот момент происходил какой-то сложный расчет или обработка файла в Web Workers, процесс прерывается. На бэкенде задача бы докрутилась на сервере, а на фронтенде пользователю приходится начинать всё сначала.

После сотого бага в Safari появляется непреодолимое желание сдаться, поднять копеечный сервер на Node.js или Python, прикрутить базу данных и перенести всю логику туда. Это сэкономило бы мне 80% времени на разработку. Но я держусь за концепцию Client-Side по двум причинам:

Проект выживает за счет оптимизации кода и редких, но очень ценных донатов от пользователей, которые понимают, почему чистый веб без рекламы и серверов сбора данных — это круто.

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

💬 Коллеги-разработчики, как вы воюете с ограничениями мобильных браузеров? Часто ли приходится отказываться от крутых фич просто потому, что Safari на iOS решил «убить» вашу вкладку?