... низкая производительность
Один из тестовых случаев сравнивает вызов пустой функции с вызовом console.log.Пустая функция, вероятно, будет встроена компилятором JIT, так что вы фактически сравниваете без кода с console.log.Конечно, никакого кода вообще намного быстрее.
Я никогда не испытывал (заметного) запаздывания из-за ведения журнала, за исключением того, что вы регистрируетесь внутри цикла рендеринга или чего-либо, выполняемого очень, очень часто.
... плохая репутация
Серьезно?На мой взгляд, у JS есть отличные способы отладки по сравнению с другими языками (возможно, потому что JS получил самые хорошие ошибки :)), поскольку вы можете просматривать вложенные структуры «вживую», вы можете остановить выполнение в точках останова, вы можете подготовить код для отладки с помощью debugger; заявление, вы можете сбросить всю память, визуализировать поведение GC, горячие функции и многое другое.Да, все эти функции снижают производительность, однако консоль работает достаточно хорошо.
Есть ли более производительная альтернатива, которая присуща vanilla JS (без фреймворков / библиотек)?
Ведение журнала напрямую записывается в движок, выполняющий JavaScript, это означает, что он может получить доступ ко многим вещам, к которым вы не можете получить доступ через JS, также нативный код всегда будет быстрее, чем скомпилированный JavaScript (или такой же быстрый, но никто не может гарантировать, что).
В случае необходимости оставлять сообщения об ошибках в стиле console.log () в производственном приложении / на веб-сайте ...
И кто должен читать эти журналы?Вы хотите попросить своего клиента заглянуть в консоль в случае ошибки?
Вход в систему Production не должен регистрировать все, что вы используете с помощью отладки, но достаточно для того, чтобы вы могли отследить ошибки, поэтому некоторые крошкичтобы выяснить, где произошла ошибка (например, «открыто меню»), и сами ошибки.
Если вы не хотите самостоятельно писать производственные журналы, посмотрите sentry для JS