Михаил Макаров

Для задачи заработка денег.

extJS и vue.js

Сравниваете тёплое с мягким.

Мне кажется, что они не медленнее движутся, а при начале прокрутки между блоками увеличивается расстояние, а в конце - уменьшается до исходного.

Потому что в первом случае внутренняя функция будет создана один раз, а во втором - каждый раз при вызове counter()

Это не словарь, а список. Пишут, что в питоне доступ к элементу по индексу имеет сложность O(1), уж не в курсе, как в нём списки реализованы.

Списки по своему устройству очень сильно отличаются от массивов. Учитывая, что вы дошли до NumPy, вы должны это хоть примерно представлять. Ну а NumPy предназначен для быстрой обработки данных, потому списки там ну никак не катят.

А в чём суть вопроса? Ну то есть, при совсем базовых знаниях JS это всё очевидным становится.
Нужно повесить обработчик на событие Click кнопки. В обработчике получаем один элемент по id или class, берём его значение и присваиваем другому, какому надо. Ну и всё. На каком этапе возникает проблема?

2.

Для скорости.
Сторонние библиотеки нужно подключать отдельно и не со своего хостинга, а с популярного CDN.
Свой код - лучше минифицировать и скомпоновать в один файл, чтобы браузер загрузил его и закешировал. Ежели какие-то отдельные фрагменты своего кода часто изменяются (по причине развития сайта, например), то их лучше выделить в отдельный файл, чтобы остальной код, опять же, закешировался.

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

Ваша работа, за которую вы получаете деньи, заключается в реализации необходимых бизнесу механизмов.

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

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

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