Дмитрий Беляев

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

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

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

const a=1, b=2, foo='bar';
const obj = {a,b,foo};
console.log(obj); // -> {a: 1, b: 2, foo: 'bar'}

myArray.findIndex(function (record) {
    return record.id === 3;
});

Потому что объекты (а массив - это тоже объект) сравниваются не поэлементно. Сравниваются ссылки на объекты, а они разные, даже если содержимое объектов абсолютно одинаковое.

1 == 1 // true
[1] == [1] // false

поправьте условие в цикле на i < mas.length

function getMonthLastDay(year, month) {
 return (new Date(year, month + 1, 0)).getDate();
}

appendChild() не копирует элемент, а перемещает.
Если вам нужно копирование - можно использовать cloneNode(true)

console.log(new Number(1) + new Number(2)); // выводится 3 и typeof полученного значения number
То есть всё в порядке, это то же самое, как если бы мы сделали:
console.log(1 + 2);

Число - это Primitive. У примитивов есть эквивалентные объектные аналоги (кроме null и undefined). Поэтому да, это "то же самое" в каком-то смысле (у примитива нет методов, в отличии от эквивалентного объекта, они не могут быть изменены, и.т.д., но в таких простых расчетах мы не обращаем на это внимания). А штуки вроде упомянутых промисов, дат и что там еще бывает - это будут уже не примитивные типы данных, там такой двойственности уже нет.

В остальном - там есть немного синтаксического сахара, связанного с функциями и объектами. Например Object может быть создан разными способами, хотя фактически они приводят к одному результату, а не как у примитивов и их объектных оберток-аналогов.

Функция functionName существует в контексте контент скрипта.

При добавление кнопки с onclick="functionName()" по клику на нее functionName будет вызывать в контексте веб страницы, где данной функции нет.

1. Добавь кнопку.
2. Добавь эвент листенер через addEventListener на нее.

Будет работать.

А как вообще определяется лучшесть и быстрость..
А если один язык посчитал быстрее, значит он лучше?

Язык - это набор грамматик для парсера; набор правил для описания последовательности действий с данными, описания данных, работы со строками и т.д.
Язык ничего считает, и сам по себе либо хорош для какого-то класса задач, либо совсем не хорош. Например, писать кросс-платформенный три в ряд на php идея так себе. Вся магия заключается в том, для чего этот язык служит ручкой управления - для игровой приставки, телевизора, виртуальной машины, веб-сервера, специального ПО или ПК.

Язык без контекста вообще не имеет никаких свойств, это просто инструмент. Сначала говорят о процессе разработки, сроках, задачах, в процессе оценки сложности проектирования определяется стек технологий для решения и среди них будут языки.

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

Это происходит потому, что знакомство с процессом программирования начинается не с C и не с изучения алгоритмов и структур данных. В результате получается, что большая часть проблем у новичков - это когда что-то работает, но медленно, а ошибка из-за отсутствия некоторых базовых для области знаний не видна. Отсюда и возникает такой вопрос, который с точки зрения терминологии некорректно сформирован.

А количество написанных строк кода при достижении одинакового результата показывает какой язык лучше?

Количество строк в решении задачи на языке А по сравнению с языком Б может позволить неточно оценить отношение цикломатических сложностей для решений. Но это имеет смысл только для языков из одной категории. Например, для ПО для работы с геоданными и картами может потребоваться встроить какой-нибудь существующий язык, либо навелосипедить DSL. К примеру, в качестве встраиваемых кандидатов можно взять lua, js, python. Если в аналитической модели большинство операций связано с операциями над множествами, то на тестовой задаче станет видно, что решения на python самые лаконичные. Если в модели много работы с данными разных типов, то возможно тут выиграет js. Если все модели данных уже предопределены, или в числодробилках задействованы распараллеливание вычислений, то скорее всего обвязка на lua даст самый лаконичный результат. Да, все дело в том, какие именно паттерны и модели изначально встроены в синтаксис языка. По факту, именно специализация языка на классе задач позволяет сделать решение лаконичным.

Но лаконичность и скорость исполнения более важны для языков с JIT компиляцией. В AoT основная ценность это производительность программы и минимальное потребление ресурсов, в C++ лаконичность в решении это результат введения чего-то хорошего в стандарт. В целом, нужно исходить от класса задач, а не просто из количества строк.

Перейдя на реакт вы будете страдать. Реакт - это тупо даунгрейд. Всё то же самое, но хуже и местами отсутствует. Есть ли в нём хоть какие-то преимущества перед vue? Не знаю таких.
Что за проблемы у вас с библиотеками?

Не уверен в том, что при малейших проблемах с хантингом на VUE нужно переходить на React. Ну в общем, если бы это был например выбор на Angular JS vs Angular я бы проголосовал за апгрейт на Ангулар вне зависимости от усилий, банально потому что содержание разработчика на устаревшем фреймвоке в перспективе выйдет дороже.
Я почти уверен что на VUE все еще можно найти специалиста за адекватную цену.

Пишу как React разработчик, я бы ориентировался на цену миграция vs зарплата разработчика, не вижу особой разницы с технической стороны.