Комментарии 27
Даже сам Хабр не готов к таким вещам.
Ух ты, еще одна бесполезная статья, спасибо.
console.log забываются в нескольких местах кода, что кроме гипотетической потери производительности
По сравнению с тем, что js-пакеты после сборки превращаются в 10MB+ монстра, вызовы console.log кажутся песчинкой в пустыне по затраченным ресурсам. Я уже молчу про остальной собираемый фронт, который грузит проц на 100% в течение 10 секунд.
А уж сколько ресурсов кушает браузер при обычном скролле... вывод console.log - это точно цветочки.
Данное сообщение по умолчанию будет «скрытым» для пользователя
Не каждый пользователь вообще открывает консоль через F12. А если уж открыл и читает какие-то значения, которые сыпятия консоль, то уж точно ему будет не сложно включить режим дебага.
Решение состоит в том, чтобы использовать инструменты отладки, предоставляемые вашим браузером
Статья как-будто из 2010х, но Chrome Dev Tools появился как-бы позднее. Сейчас многие фронты много раз собираются разными сборщиками, которые многократно пакуют и изменяют код. Удачи поставить точку останова там, где 10MB javascript'а написан в одну строчку.
По итогу, скажем так, console.log - уж точно не главная боль современного frontend'а.
По сравнению с тем, что js-пакеты после сборки превращаются в 10MB+ монстра, вызовы console.log кажутся песчинкой в пустыне по затраченным ресурсам.
Мне пришлось сделать дома кластер из XEON'ов чтобы перенести вывод консоли на него.
Так в non-prod-режиме код собирается обычно с source-maps и дебаггер останавливается в нужной строке исходника.
А вообще для такого есть абстракции логгеров, вставляешь в код (даже оставляя в продакшене), чем больше тем даже лучше, всякие trace / debug, а потом с помощью LogLevel определяешь что выводить.
А подменяя абстракции, можно вместо вывода в консоль, хоть отсылать логи на сервер, хоть складывать в localStorage, меняя только флаги сборки.
Т. ч. я считаю, что неиспользование console.log, хоть и не "главная боль", но у ж точно показатель культуры разработки.
Так в non-prod-режиме код собирается обычно с source-maps и дебаггер останавливается в нужной строке исходника.
Но есть три проблемы, из-за которых я этим редко пользуюсь:
Оооочень медленно. Пока браузер прогрузится в дебаг режиме, я пять раз перезапустить успею. И ресурсы выедает как не в себя (наверное из-за этих же соурсмапов)
Останавливается почти там где нужно (не всегда потому что после бейбеля код может очень сильно отличаться), но вместо осмысленных переменных вокруг показывает обфусцированный мусор.
Зачастую мне нужно проверить тот же реакт компонент, который перерендеривается по 15 раз и интересуют только последняя пара раз. Это слегка мучительно
бонус: режим «остановка на исключениях» был бы супер полезный если бы недобросовестные разработчики не принялись кидаться и ловить ошибки налево-направо для всех этих suspense и чего бы то ни было.
Но иногда дебаггер - единственное что спасает.
Недавно запустил дебаг на исходнике с sourcemap, он встал где нужно, только при наведении на переменные я не увидел их состояния. Видимо, он не понял, как typescript-переменные связаны с JS-переменными.
так можно в исходном коде написать debugger, вместо того чтобы ставить точку останова в девтулзах
Удачи поставить точку останова там, где 10MB javascript'а написан в одну строчку.
Использую source maps, особых трудностей в отладке не испытываю. С другой стороны, не понимаю агр автора в сторону console.log: тоже вполне полезный инструмент, иногда приходится и им трейсить.
Список исчерпывающий, но console.assert и console.count в нём почему-то нет.
Для отладки - почему бы и нет? Так, например, можно посмотреть, правильно ли работает цикл, не заморачиваясь. Главное не забыть убрать
Да всегда будут использовать console.log, потому что это удобно. Прекратите запрещать людям делать то, что им удобно)
P.S. Понятно, что это не к переводчику посыл)
Часто случается так, что console.log забываются в нескольких местах кода
Для этого линтер существует
от линтера здесь толку мало - просто забывают console.log вместе с eslint-disable-next-line перед ним
Я таким образом делала, в проекте линтер настраивала с возможностью писать console.log, а потом запуская линтер в CI дописывала правило через команду в терминале. Таким образом при локальной разработке ругани не было, а вот на стадии принятия MR он отваливался
Я пользуюсь линтером, который проект собирает и выводит в консоль что надо, но в среде разработки показывает ошибку, которую нельзя не увидеть перед пушем, например
Лайфхак: если пользуюсь временными выводами данных в консоль, с какого-то момента первым аргументом всегда пишу имя функции или переменной о которой идет речь. Это позволяет понимать о чем речь, а главное - быстро находить тех кто уже почем зря мусорит в консоль, если по тем или иным причинам еще не хочется выкидывать все отладочные данные.
А про газлайтинг разработчика, вооружённого console.log со стороны банды промисов в состоянии гонки где?
многие разработчики регулярно используют console.log метод таким образом, который я считаю неправильным
Простите, больше не буду
Вообще-то у console.log есть и преимущества перед debugger:
Остаётся история вызовов. Я вижу, как менялось состояние. С дебаггером приходится вспоминать, что было, в каком порядке и сколько раз.
Не останавливает выполнение кода на каждом вызове, а просто пишет на экран. Для ряда кейсов так банально быстрее получается.
Как следствие из п.2 не портит тайминги. Например, с дебаггером может случиться нежелательный тайм-аут, reject промиса, потому что код остановился, а часики-то тикают :-)
А ещё есть ситуации, когда дебаггер невозможно включить. Например, в вебвью сторонних приложений или на удалённом iOS устройстве. Тогда и, прошу прощения, alert может пригодиться. :-D
есть же babel plugin который убирает в релизе все console.log, подключил и не переживаешь за просадки производительности в релизной сборке
Прекратите использовать console.log