Мы живем в мире готовых решений и за частую это оправданно, потому что это оптимизирует расходы. Можно часто услышать фразу "не надо изобретать велосипед". Правда, есть у этого подхода и обратная сторона - когда технология, которую вы используете, становится вам недоступна. Причины могут быть разные: от не пропуска СБ вашей любимой библиотеки на проект, до ухода компании, которой принадлежит технология, с рынка или неэффективности такой технологии в конкретном случае. И вот очень яркий пример. Когда начинали разрабатывать проект кортеж - мыслили именно готовыми решениями, что чуть не привело к провалу. Как это связано с разработкой? Да очень просто. Вот свежий пример с работы: Есть входящий массив объектов. У каждого объекта есть поле typeId в диапазоне от 0 до n. Полученные записи надо фильтровать по typeId,  допустимых typeId больше одного. И чаще всего можно увидеть решение arr.filter(it => allowedIndexes.includes(it.typeId)). И вроде все с этим решением нормально, если не брать в расчет, что сложность выполнения этой истории - квадратичная. Включая голову и отказавшись от привычных шаблонов, можно вспомнить про алгоритмы и структуры данных и использовать словарь или Set , что ускорит это в n раз. В общем-то к чему все это, мы имеем то, что заслужили. Пока большинство использует необдуманных готовые решения, мы будем и дальше писать неэффективные программы, выпускать китайские москвичи и переклеивать шильдики