Помню, на Авито такое было. Когда там Роман Дворнов работал, как-то на конференции обсуждали эту "защиту". Сейчас зашёл — ничего похожего не осталось.

Скорее всего не работала с debugger

Нужен конкретный пример, чтобы подобрать способ, поэтому пока просто накидаю вариантов.

Можно игнорировать точки останова полностью:

В таком случае код сохранит работоспособность и его можно изучать "в процессе".

Когда игнорирование точек останова не работает, можно попробовать игнорировать файл целиком:

В таком случае файл будет "отключён" от страницы, сайт скорее всего сломается, но код изучить можно будет.

Спасибо за поддержку.

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

К тому же, отладка с source maps - это то ещё удовольствие. Сразу же хочется в объятья console.log вернуться.

На переходный период есть log point, это как break point только с логированием вместо остановки.

В четвёртой части расскажу о нём.

Увы, путём революции не всегда можно пойти. Слишком большой охват у Виндовз. Вот и появляются две панели управления и подобное. Обратная совместимость. Думаю, ещё версия-две и останутся одни "Параметры".

Следует отметить, что основы оформления обычных субтитров и субтитров для слабослышащих, как правило, совпадают

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

Для обычных субтитров важны правильная разбивка диалогов и укладка по времени:

• Чем меньше будет титров, где речь нескольких персонажей, тем меньше вероятность запутаться, кто говорит.

• Если текст в титре учитывает время титра, зритель с большей вероятностью успеет его прочитать.

• Переносы в титрах должны быть со смыслом: предлоги не висят, длина разных строк примерно одинаковая.

Уже соблюдение этих простых правил скажется на ощущении от просмотра.

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

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

Исправления уже за рамками нашей статьи. Тем более по ссылке специальная версия с ошибкой для отладки.

Рабочую версию приложения вы найдёте по ссылке https://mozilladevelopers.github.io/sample-todo/04-final

Отладчик можно научить редактировать файлы, но обычно правят в редакторе.

Вижу что есть какие-то точки останова, есть какие-то XHR, что-то где-то выделено. Но что это? Что за точки? Что они останавливают? Как этим пользоваться? Что такое XHR? А можно не точки, а кривые безье? А кривые безье останова?

Что такое точки останова, во второй части ;-)

остаётся несколько абзацев в стиле КО и пара скриншотов

Конечно, для человека, который пишет статью "Хитрости при отладке", введение будет "в стиле КО".

Здесь даже спорить не о чём.

Можно было склеить всё в одно, но я решил придерживаться оригинальной разбивки, чтобы не вышло простыни.

Так потому 1/4, что дальше будет на примере отладки раскрываться каждая часть:

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

Чего должно хватить новичкам. Конечно, с поправкой, что JavaScript они знают.

Основные возможности действительно интуитивно понятны, но некоторые редкие функции приходится изучать. Правда такие вещи уже за пределами этого гайда, в документациях: Firefox DevTools, Chrome DevTools.

p.s. Ещё тестировщики пользуются.

Оригинал и моя адаптация нацелены на джунов и смежных специалистов, вроде бэкендеров. И у тех, и у других мало опыта в JavaScript, а ошибку найти нужно. Здесь отладчик приходит на помощь.

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

Да, хотя DevTools как строка поиска, одинаковая у всех, в некоторых деталях инструменты отличаются.

К сожалению, тут нет одного фаворита. Что-то лучше в Chrome, что-то в Firefox, что-то в Safari. И это хорошо!

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

Об этом мой манифест в начале статьи.

В Chrome DevTools есть хэлперы в консоли. Функция debug() позволяет приостановить выполнение при вызове определенной функции.

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

p.s. В Firefox хэлперы тоже есть, но вот именно такого - нет.