>>1093282
Тебе лучше с основами ЖС подразобраться, чтоб понимать все эти хитрости.

Исторически всё сложилось непросто. Так как ЕКМАСкрипт, это встраиваемый язык общего назначения, его спецификация написана на каком-то своём птичьем языке, к которому требуется привыкнуть.
https://tc39.github.io/ecma262/
Встраивание этого языка в браузер в народе называется ЖС (getElementById это уже не часть ЕКМАСкрипта, а только ЖС). Из-за непривычности, несоответствия и сухости спека у меня вызывала отвращение первое время. Надо пересилить и окунуться.
В спеке ЕКМАСкрипта есть абстрактные операции и внутренние поля (свойства или методы) у объектов. Абстрактные и внутренние потому, что они существуют только как договорённости, ты к ним никак не можешь обратиться, не можешь их прямо изменять, никогда их не встретишь в коде ЖС, они нужны для описания внутренних алгоритмов движка в спецификации. Внутренние свойства или методы решили писать в двух квадратных скобках (к массивам это не имеет отношения, скобки считаются прям частью имени в спеке).
Например, спецификация (в тутошнем вольном толковании) говорит, что Конструктором считается тот, у кого есть внутренний метод [[Construct]]. По-человечески: "Конструктор это тот, кто может делать констракт". Констракт это иметь способность вызываться с оператором new ( типа new Array() ) и знать, какие шаги предпринимать в таком случае.
Вызываться. Функция это тоже объект, у которого есть внутренний метод [[Call]]. Вспомни, ты не можешь их изменять, ты не можешь добавить такой метод произвольному объекту сам. Только если прямо создаешь функцию ( function fn() {} ), внутренности движка следуя спеке делают так, что у объекта fn будет какой-то механизм, соответствующий [[Call]], и тогда ты сможешь этот объект вызывать скобочками.
https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist
Взгляни, но пока не упарывайся. Этот внутренний метод проверяет другие внутренние свойства ( типа [[FunctionKind]] ), предпринимает прочие шаги. Вот так там всё внутри вертится.

Прототипы. У каждого объекта есть внутреннее свойство [[Prototype]]. Оно содержит ссылку на другой объект (типа адрес другого в памяти). Нужно это для экономии памяти, чтоб можно было не копировать свойства из объекта в объект, а дать возможность одним объектам ссылаться на другие. Так объекты складываются в цепочки, получается что-то похожее на наследование. В конце цепочки [[Prototype]]: null
Например, писать через точку obj.prop это вызывать внутренний метод [[Get]] (найди его в спеке), который вызовет абстрактную операцию OrdinaryGet, которая получает значение свойства из объекта, а если в нём свойства нет, то ищет по цепочке прототипов до null. Если ты делаешь obj.prop, движок внутри себя делает obj.[[Get]](prop, obj), если получает undefined, тогда делает obj.[[Prototype]].[[Get]](prop, obj) и т.д. по цепочке до null. Как только получит не undefined, а любое другое значение, как бы заменит им obj.prop
Если ты через точку, вызываешь функцию ( obj.prop() ), то внутренние алгоритмы для этого вызова функции специальную переменную this сделают равной объекту до точку. Это отдельная тема, но можешь попробовать сам поглядеть, только пока сильно не упарывайся, это забористое дерьмо
https://tc39.github.io/ecma262/#sec-ordinarycallbindthis

Когда ты создаёшь функцию ( var fn = function() {} ), она как объект автоматические получает всякие нормальные, доступные тебе, поля. Например fn.length вернёт количество аргументов, которые ожидает функция (тут 0). Или fn.name === "fn".
Можешь представить, что функцией этот объект делает только то, что этот объект содержит внутренние поля [[ECMAScriptCode]] (это строка, в ней всё, что ты в функции между {} написал) и [[Call]], который типа выполнит эту строку как eval(str);
Нам важно, что есть среди нормальных, доступных тебе полей, объект fn.prototype, на который будут в своём [[Prototype]] ссылаться объекты, которые будут созданы, если ты вызовешь fn как конструктор. fn.prototype и [[Prototype]] это разные вещи. Первый доступен тебе в коде, другой из спеки и кишков движка.
var obj = new fn();
obj.[[Prototype]] === fn.prototype // можно было бы сделать, если бы нам был доступен [[Prototype]], но он внутренний. Нам доступно только
Object.getPrototypeOf(obj) === fn.prototype // вот это вернёт true

var arr = new Array() // или var arr = []
Object.getPrototypeOf(arr) === Array.prototype // true, в цепочке, а значит
arr.indexOf === Array.prototype.indexOf // true, arr получает этот объект (функцию) по цепочке, это один и тот же объект-функция, полученный через [[Get]]

К чему была вся эта писанина, [[Prototype]] может содержать ссылку только на один объект. Получается только цепочка. Многие могут ссылаться на одного, но один на многих — никогда. Нет множественного наследования.

В твоём примере ты хочешь обращаться с живой коллекцией (объект, который содержится в document.getElementById("parent").children), как с массивом. Но из-за отсутствия множественного наследования, этот объект не может быть и NodeList, и Array. Никаких методов из Array.prototype этот объект не получает через точку, через [[Get]], потому что не имеет к его цепочке прототипов вообще никакого отношения. У него своя спецификация:
https://dom.spec.whatwg.org/#interface-nodelist
{"0": HTMLElement, "1": HTMLElement, length: 2}
Но, судя по его спецификации, он очень похож на массив. Есть ключи-индексы, есть длина.
Взгляни на
https://tc39.github.io/ecma262/#sec-array.prototype.indexof
Ему как раз не нужно ничего, кроме ключей-индексов и длины. Вот только шаги свои он предпринимает для this. Чтоб this стал равен живой коллекции, надо бы вызвать через точку children.indexOf(), вот только вызывать нечего, не найдётся такого метода в цепочке от children.
Сам A.p.indexOf это функция, а значит
indexOf.[[Prototype]] === Function.prototype
Все функции по цепочке могут получить свойства из прототипа Конструктора функций. Там есть метод call(thisArg, ...args)
https://tc39.github.io/ecma262/#sec-function.prototype.call
который вызывает функцию с явным this = thisArg. Как точка, только точка это делает неявно, а первый аргумент call() — явно.
obj.fn(1, 2) // то же, что и
var fn = obj.fn
fn.call(obj, 1, 2)

Итого:
Ты хотел бы обращаться с объектом, похожим на массив, как с массивом.
Array доступен в глобальной области видимости.
Ты взял объект-функцию indexOf из объекта protorype из объекта Array. Обычный массив получал бы эту функцию по цепочке прототипов, но NodeList не массив.
Из объекта-функции indexOf ты вызвал метод call, который нашёлся в indexOf.[[Prototype]].
Метод call(children, elem) вызвал свой this (объект до точки, indexOf который) и явно установил для этого вызова (внутри indexOf) this равным children, а elem передал первым аргументом.
Получилось неотличимо от children.indexOf(elem).

Хорошо сказано про фронт енд разработчиков.

1. В среднесрочной перспективе это самая популярная область для вкатывания. Типичный "телезритель ВКонтакта и Одноклассников", решивший стать программистом, не пойдет месить спринги в NetBeans IDE, писать логику обработки данных на R, мигать светодиодами на SoC или причесывать аппликативные функторы с монадами. Он откроет в соседней с "Одноклассниками" вкладке браузера какой-нибудь нагугленный сайт и почитает про программирование, после чего заглянет в исходный код страницы, начнет изучать верстку, стили и так далее. Что это значит? А то, что конкурентов будет вагон. И не обязательно тот самый "телезритель ВКонтакта и Одноклассников" окажется глупцом. Может быть, он хорошо изучит тему.

2. Как хорошо сказал один анон, есть логически выводимые знания, а есть - талмудические. Так вот, расчет изменения окна перегрузки в TCP для конкретных сетей - логические знания, а весь Web - талмудизм. Знание о том, как сделать конкретную вещь работающей в 7 различных браузерах (умножить на 10 версий каждого браузера), используя пять CSS-хаков, вендор-префиксы и пару небольших скриптов-затычек, - это талмудизм. Обойтись без талмудизма вы не сможете. Есть стандарты на языки и технологии, но нет ни стандарта на рендеринг, ни стандарта на браузер, ни единого мирового стандарта на взаимодействие с сайтом на разных платформах и устройствах, ни стандарта на варианты настроек браузера / хинтинг / сглаживание / subpixel rendering. Более того, браузеры очень активно развиваются и постоянно обновляются, в них бывают баги.

3. Фраза "Ничто не истина, все дозволено" - это про Web. Если к разработке, связанной с middleware или ОС, применима фраза "Практически любой каприз за ваши деньги", то к фронт-эндам применима фраза "Абсолютно любой каприз за ваши деньги и вот еще бесплатно с горочкой". Короче, клиент всегда прав, любые хотелки обязательно надо реализовать, мы за ценой не постоим (даже если будем работать 15 часов подряд, а заплатят нам за 8). И если в других областях клиент или сам является бывшим инженером, или тактично не лезет в разработку, то здесь клиент будет очень активно вмешиваться, постоянно желая разного, а программиста он будет воспринимать, как дизайнера. Здесь как нигде популярна Agile-методология с еженедельно растущим техническим долгом, постоянными изменениями и новыми идеями, отсутствием плана, частыми релизами и отсутствием четких контрактных требований для каждой фазы проекта (вследствие чего программиста всегда можно будет обвинить, вынудить перерабатывать или немножко поработать задаром). Клиент видит только UI, поэтому ему будет сложно объяснить необходимость тратить деньги и время на технический долг. Некоторые клиенты могут даже заставлять использовать облачные IDE на JavaScript внутри браузера, чтобы следить за ходом разработки, править что-то (что они не совсем понимают) и даже раздавать ценные указания в real-time.

4. Web-разработка - постоянная гонка, забег на дистанцию, и въедливость с учетом всех возможных комбинаций тут не приветствуется. Не используются ни средства проверки моделей, ни доказательства теорем, ни иные методики верификации. Не используется даже покрытие кода юнит-тестами или въедливое ревью чужого или своего кода. Вместо этого используются обычные тестировщики, которые комбинаторно все во всех версиях и семействах браузеров прокликивают и проверяют. Если вам не дали тестировщика, то все это придется делать вам (или же просить заказчика все-таки взять на проект одного или двух тестировщиков). Постоянное совмещение в себе двух ролей - разработчика и QA - сможет довести вас до нервного срыва, поэтому лучше выбирать строго одну роль, одну из.

Вывод: front-end-разработка - тяжкий труд. Не входите в айти.