10 причин, почему Firefox лучше, чем Chrome для веб-разработчика

firefox против chromeУчитывая постоянно растущую долю Google Chrome на рынке браузеров, может быть не сразу понятно, почему статья названа именно так.

Да, Хром набирает популярность у рядовых пользователей интернета, но это не значит, что он так же набирает популярность и среди веб-разработчиков.

По крайней мере, для меня он так и не стал основным браузером.

Если я приму, что Chrome — браузер по умолчанию на моем компьютере, то мне все равно придется постоянно нырять в Firefox. Причины этого как раз изложены в статье.

Но давайте сразу договоримся, что это не проплаченная фанатами Огнелиса статья, и я не ярый противник Хрома :)

Безусловно, Google дал веб-разработчикам много полезных инструментов, но Chrome пока не стал одним из них.

Конечно, я не расчитываю всерьез, что кто-то из Google когда-нибудь прочтет этот пост. И уж тем более не расчитываю, что этот кто-то передаст все мои пожелания вверх по цепочке. Но призрачная мысль, что чудеса все же бывают, и желание просто поделиться мыслями с вами заставляет меня опубликовать все это.

1. Просмотр HTML

При разработке сайтов мы частенько допускаем ошибки, которые приводят к генерации неправильного HTML-кода. То есть, нам часто нужно просматривать сгенерённый HTML-код, чтобы выяснить, что с ним не так.

У Fire­fox‘а есть замечательная фишка, позволяющая выделить интересующий участок на странице и посмотреть исходный код именно этого участка. У Хрома такой фишки нет.

Максимум что есть в Хроме — Inspect Ele­ment что позволяет просмотреть HTML код элемента страницы под курсором. Это не одно и то же. Если я выделил какой-то участок страницы, я хочу посмотреть исходный код всего участка, а не только одного какого-то элемента.

Еще одна досадная для разработчика особенность Chrome в том, что он пытается улучшить сгенеренный код страницы. Это значит, что если вы ошиблись в формировании кода и не закрыли где-то тег, вы никогда не обнаружите, где же именно вы не закрыли тег, потому что Хром обнаружил эту ошибку, исправил ее и только после этого показал вам. Хотелось бы увидеть в Хроме опциональное выключение “бьютифаинга”

2. Валидация HTML

Другая замечательная фишка Fire­fox в том, что он может показать разработчику все ошибки валидации страницы. На самом деле, эта возможность обеспечивается расширением HTML Val­ida­tor.

Перепробовав множество плагинов для Chrome, могу сказать, что ни один из них и рядом не стоит с плагинами для Фокса. Некоторые скажут, что можно использовать сервис валидации от W3C, которому можно скормить URL страницы и он отвалидирует код. Но согласитесь, не всегда тестовый сервер, а сним и страница, доступны из интернета, а следовательно, W3C не сможет пройти по ссылке.

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

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

Таким образом приходим к выводу, что для Хрома нет нормального, удобного инструмента валидации HTML, и что такой инструмент несомненно нужен.

3. Выключение JavaScript

Иногда возникает необходимость проверить, как работет ваш сайт с выклчюенным JavaScript. Единственное решение для Хрома — пойти в настройки и выключить его. Так не годится.

В Fire­fox можно использовать замечательное расширение Web devel­oper (Скачан 581 раз) от Криса Педерика (Chris Ped­er­ick) в котором есть специально обученная кнопка, живущая вместе с остальными кнопками. И называется она “Dis­able” по нажатию которой можно выключить Javascript, кеш, метаредиректы и прочее.

Для Chrome тоже есть подобное расширение от того же автора, но в нем, как ни странно, нет инструмента, позволяющего выключить JavaScript.

Проблема связана с ограничением Chrome API на вызовы из расширений. То есть, Хром не посзоляет выключать JavaScript из расширений.

Есть фьюче реквест в “Chromium project” на добавление возможности временного отключения JavaScript. Исполнение этого реквеста даже было назначено. Год назад. Как видите, ничего не изменилось. Как ни странно, юзерам запрещено оставлять комментарии к этой заявке.

4. Очистка кеша браузера

Бывает, вам нужно очистить кеш браузера, чтобы “начисто” загрузить разрабатываемый сайт с последними изменениями.

Та же песня, что и с JavaScript. Вы не можете сделать этого из плагина к Хрому. Вы вынуждены делать это только через “Настройки” браузера.

Точно также, как и в предыдущем примере, есть фьюче реквест на эту возможность. Причем аж 2 года назад. И только 3 месяца назад статус заявки сменился и есть надежда, что скоро(?) это будет реализовано.

5. Переключение “user agent”

Иногда нужно зайти на разрабатываемый сайт как бы из другого браузера, но сохраняя все девелоперские возможности Firefox.

Например, если вы хотите по запросу RSS-ленты перенаправлять все браузеры на Feed­burner, кроме того случая, когда клиент и есть сам Feedburner. И было бы неплохо заставить ваш браузер прикинуться Фидбурненром, чтобы проверить, правильно ли отрабатывает перенаправляющий код.

В Fire­fox вы можете использовать плагин User Agent Switcher. В Chrome тоже есть плагин User Agent Switcher. Только проблема в том, что он не работает. Точнее, работает, но не так, как ожидается по логике.

Этот Хром-плагин может только менять идентификатор браузера, который определяется в JavaScript. Это означает, что в HTTP-запросах ничего не меняется и ваш скрипт-редиректор RSS не поймет разницу между “просто Хромом” и “Хромом с измененным идентификатором user agent”.

Есть подозрение, что все-таки существует возможность переключать user agent, но пока это только слухи и догадки. Пока это не будет реализовано в Хроме, мы вынуждены будем пользоваться в этих целях Фаерфоксом с его “Agent Switcher extension”.

6. Кнопки в строке статуса

Замечательная штука в большинстве современных браузеров — кнопки в строке статуса. Это та самая строка, где живет кнопка Fire­bug, Gmail Checker, Seo­Quake и прочие. Очень удобно в процессе разработки в любое время тыцнуть кнопку Fire­bug и дебажить, например, код JavaScript.

Chrome практически лишен статус-бара. Она используется только для показа статус-сообщений таких как адрес ссылки под курсором. Чтобы открыть какой-либо девелоперский инструмент, вам нужно порыться в меню, либо вспомнить далеко не тривиальный прием из Хром-Кунг-Фу с комбинацией на кливиатуре.

Конечно, со временем можно привыкнуть и к аскетизму Хрома, но согласитесь, было бы гораздо более удобно и что называется, юзер-френдли, если бы нужные инструменты были доступны в виде кнопок в статус-баре или хотя бы те же кнопки вверху окна.

7. Кеширование страниц после POST-запроса

Иногда нужно вернуться к старнице, которая является ответом на POST-запрос. То есть, страница после отправки формы. Однако, вы не хотите еще раз отправлять запрос.

При некотором стечении обстоятельств, совокупность которых я так и не смог выяснить, Хром вместо показа этой страницы спрашивал меня, хочу ли я снова отправить запрос, и не показывал мне нужную страницу до тех пор, пока я не соглашусь все-таки отправить запрос заново. У Фаерфокса таких проблем не наблюдается. Он всегда просто показывает мне нужную страницу, даже если эта страница сгенерирована в ответ на POST-запрос из формы.

8. Частые падения Flash плагина

Я не разрабатываю приложения на Flash. Однако иногда возникает необходимость просматривать сайты, предоставляющие нужную информацию во флеше. Я говорю сейчас о Google Ana­lyt­ics и Google Web­mas­ter Tools.

К сожаленияю, плагин Flash, поставляемый с Chrome, часто падает без видимых причин. Причем, при использовании Firefox для просмотра тех же самых сайтов, такой проблемы не возникает.

Лучше бы ребята из Гугл переставли использовать фдеш в своих онлайн-продуктах. Большинство информации, представленной у них через Flash, в этом самом флеше на самом деле не нуждается. Может, у Гугла просто нет времени и/или разработчиков для отказа от Flash?. Ну в таком случае пусть хотя бы пофиксят флеш-плагин, который идет в коробке с Хромом.

9. Редактор HTML генерирует некорректный код

В настоящее время большиснтво сайтов, публикующих генерируемый пользователями контент, предоставляют весьма функциональные WYSIWYG-редакторы. Идет постоянная работа с тегом DIV.

Проблема в том, что HTML-редактор в Chrome до сих пор остается очень глючным. Если вы возьмете скопируете сгенеренный им HTML и вставите его в редактор, вы получите кривой HTML.

Например, я видел теги meta, появляющиеся в случайных метсах внутри тела HTML после того, как документ был отредактирован в Хроме. Еще я видел странный CSS-стиль Apple-style-span, котороый появился после при вставке HTML, в то время как такого стиля никогда не существовало на самом деле.

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

Вообще, лучше всегда пользоваться подобными фильтрами, что будет в известной степени гарантировать чистоту редактируемого в браузере кода. Но факт остается фактом: если вы используете для редактирования HTML браузер Firefox, вы получаете на выходе нормальный код, а не мешанину, предлагаемую Хромом.

10. Нет никакого отклика на сообщения об ошибках.

Я пробовал отправлять отчеты об ошибках с помощью встроенной в Chrome системы баг-репорта. Вы можете увидеть ее, пройдя в меню Tools -> Report an Issue. Вы увидите весьма удобную форму отчета даже со скриншотом текущей страницы.

Но дело в том, что я еще ни разу не получал хоть какой-нибудь отклик на свои отчеты. То есть, я даже не могу быть уверенным, что мой отчет дошел, не говоря уже о том, что его кто-то прочитал и принял какие-то меры.

И я не знаю, стоило ли вообще тратить свое время на описание этой ошибки. Я думаю, было бы более эффективно и наглядно, если бы эти отчеты отправлялись прямиком в Chromium project.

Может быть я ошибась (и я хочу, чтобы это было ошибочным мнением), но иногда мне кажется, что парням из Гугла просто наплевать на обратную связь с юзерами; что они не считают фидбек чем-то важным.

Это напомнило мне о проблемах с поддержкой PHP в AppEngine. Это было самой востребованной штукой в AppEngine. Ребята из Google отмахнулись от этих просьб и решили вообще не делать поддержку PHP, ссылаясь на нехватку ресурсов. Согласитесь, это слегка странно для компании с многомиллиардным годовым доходом.

И опять: комментировать этот фьюче реквест запрещено; никто теперь даже напомнить разрабам не сможет. Создается ощущение, что Гуглу просто плевать на сообщество PHP-разработчиков, хотя именно его можно считать крупнейшим сообществом разработчиков.

Заключение и выводы

Всё вышесказанное — исключительно моя точка зрения и ни в коем случае не отражает мнение всего сообщества PHP-девелоперов о том, как Google должен распределять приоритеты между своими проектами и каким сообществам отдавать предпочтение.

Может быть, я просто не доконца понимаю, КАК Google работает с обращениями девелоперов, как реагирует на них, насколько вообще ребятам из Гугла нужно мнение веб-девелоперов. Может, у читателей этого блога есть какие-то свои соображения по этой теме? Буду рад комментариям!


Сегодняшнее видео о пилоте-профессионале, который “косит траву” несущим винтом военного вертолета

Еще видео на WeCanFly.TV



Вы можете оставить комментарий , или использовать trackback - ссылки с вашего сайта.

10 комментариев to “10 причин, почему Firefox лучше, чем Chrome для веб-разработчика”

  1. щекастый:

    согласен что файрофокс лучше. а хром гавно

  2. Николай:

    В Н И М А Н И Е ! Больше половины изложеных тут проблем уже давным давно решены. Остальную половину не проверял, т.к. не разработчик и именно поэтому для юзера хром — лучший выбор.

    • TryK's:

      Да. 3 месяца с публикации статьи прошло все же…

    • Alecfyz:

      Николай, вы может быть не заметили, но в заголовке русским по белому сказано, что ситуация с браузерами рассматривается, исходя из потребностей разработчика. Вы, по вашим же словам, не разработчик, но тем не менее считаете необходимым сообщить всем свое мнение.
      И потом, не могли бы вы хоть кратко пройтись по всем 10 пунктам, рассмотренным в статье, и указать как решена каждая из проблем?

  3. Кажется, ребята из Гугла сильно заняты. Они не реагируют на баги к их же продуктам. У нас похожая ситуация с Андроидом.

    • Alecfyz:

      Но это ведь не правильно! Фидбек же должен обеспечиваться хоть на каком-то уровне.

      • Меньше фидбека — меньше работы.

        Возможно, среди фидбека много всякой херни.

        Что мне ужасно у Андроида не нравится: есть статьи и документация, в них ошибки или неточности. Но абсолютно никакой возможности оставить сообщение Гуглоидам.

        По-моему, это движение в неправильном направлении.

    • KibeR_ShuriK:

      Интересно, как же они должны реагировать на баги, если встроенная в браузер система баг-репорта ориентирована на анонимность?

      В любом случае, когда я отправлял сообщения об ошибках, в следующих релизах хрома этих ошибок я уже не замечал.

      • Alecfyz:

        »> как же они должны реагировать на баги, если встроенная в браузер система баг-репорта ориентирована на анонимность?
        Разговор не только об анонимной системе багрепорта, но и о багтрекерах, форумах, гугл-группах и т.д.

        »> В любом случае, когда я отправлял сообщения об ошибках, в следующих релизах хрома этих ошибок я уже не замечал.
        Вам повезло :)

Оставить комментарий

Читать RSS в Google

Добавить в Google Reader

Читать RSS в Яндексе

Добавить в Яндекс-ленту

Страницы 1 of 11

Switch to our mobile site

Rambler's Top100