Strannyk

Про список Просто автор хитренький и считает, что задача получения указателя на нужный элемент в списке - это отдельная задача поиска, которая как раз делается за O(n). Ну а со вставкой все просто - она действительно делается за O(1). Тот факт, что на практике зачастую вставка состоит из поиска и собственно вставки хитренький автор замел под ковер. Остерегайтесь хитреньких авторов!

Про массив Нетрудно догадаться™, что при вставке в массив на самое первое место, нужно сдвинуть весь хвост массива на один элемент (чтобы было место, куда вставлять). Вот это сдвигание, по самой пессимистичной (когда вставляем в самое начало) оценке и занимает O(n).

дизайнер предоставляет фигму или фотошоп.

Ваш фронтендер все собирает на реакте.

Как мне кажется это наиболее оптимальный путь.
Плюс фронтендер должен составить список требований к дизайну.
Как то:
Именогвание групп и элементов и стилей
Состояния активных элементов
карту желательных цветов

Фронт прав.
Это два очень разных направления работы.
1.Веб-диз делает диз.
2.Фронт по этому дизу кроит верстку.

Редко, когда фронт хориший диз, еще реже когда диз вообще верстает)).

Всё правильно говорит. Ваши прототипы, это, как карандашом на бумаге.

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

Typescript compiler - это инструмент проверки типов и компиляции typescript в javascript. Так же он умеет транспайлить конструкции новых стандартов js в более старые стандарты, но это не основная задача этого инструмента, и делает он это хуже целевых инструментов, в частности его можно настроить только на конкретный стандарт.

Babel - это инструмент для парсинга js кода в AST, обхода и модификации AST и обратной сериализации AST в js. Так же это еще и экосистема плагинов и пресетов. Плагины как правило реализуют транспиляцию одной из фич более нового стандарта в более старый. Пресеты - это просто конфигурируемый набор плагинов.
Так же в Babel AST есть поддержка некоторых расширений js (а ts - это тоже расширение js), но включается это все флагами.

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

Еще в экосистеме babel есть preset-typescript, который включает поддержку ts синтаксиса и транспиляцию ts в js. При этом, в отличии от tsc, он не делает проверку типов, а некоторые сущности может обрабатывать неправильно (как и большинство сторонних компиляторов ts, т.к. у ts нет строгой спеки и единственным источником правды является код tsc, который далек от идеального).

Оптимальным по выходному результату (пусть и за счет времени сборки) будет вариант, когда сначала ts код обрабатывается через tsc без транспиляции в старые стандарты, а затем происходит транспиляция с помощью babel + preset-env + browserlist.

Стоит ли учить и джаву и шарп?

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

Что насчет вакансий?

Это вы и сами можете посмотреть на любом работном сайте.

Знаю что языки очень похожи и все такое, вопрос больше про стандартные библиотеки и фреймворки.

Да, языки похожи, а потому на джунском уровне перейти с одного на другой достаточно просто. На мидловом уровне напарываешься на то, что экосистемы огромны, учить надо очень много всего даже в одной, на двух стульях становится сложно усидеть. На сеньорском уровне надо разбираться уже и в нюансах языка и виртуальной машины, тут-то становится заметно, что JVM и CLR очень разные.

Так что на базовом уровне стоит изучить и то, и другое, но для оттачивания мастерства придётся выбрать что-то одно.

10000 часов до мастерства.

Но 8 часов в день, считая еще плюсом время на учебу - это очень тяжко. Отдыхать тоже нужно, так что обязательно планируйте время на сон (7-8 часов минимум), физические тренировки (дома или в зале) и просто отдых. Так что, посчитаем 4 часа в день. Если заниматься и по субботам тоже, то можно планировать 300 дней в год. Итого 1200 часов в год, 3000 часов до окончания университета. Это вполне хороший запас времени. Я думаю что за это время вполне можно добраться до мидла.

Теперь о том кто же такой мидл, чему учиться. Ключевое понятие - самостоятельность. Джуниору нужна точная постановка задачи - сделай так. И он переводит с русского (или английского) языка на язык программирования. По сути это близко к понятию "кодер". Джуниор может очень хорошо знать язык, технологии, писать прекрасные программы. Но пока он не принимает самостоятельные решения - он остается джуном.
Мидл умеет принимать собственные решения в пределах своего модуля. Тут уже начинаются основы проектирования: SOLID, KISS, YAGNI, MVC, MVP и т.п. страшные слова. Главный критерий - практика. Поэтому я бы советовал реализовывать в качестве практики какой-нибудь долгоиграющий проект. Это даст важную практику работы "вдолгую", позволит ощутить такую радость как "сопровождение". И сразу же учиться применять стандартные для вашего стека инструменты, будь то composer, npm, gradle и др. Обязательно git. Обязательно приучать себя писать тесты (юнит-тесты, функциональные и интеграционные) - это будет большим плюсом в дальнейшем. Плюсом читать умные книги и сразу же применять то что в них написано на практике. Это в первую очередь "Программист-прагматик", "Идеальный программист", "Чистый код", "Чистая архитектура", что-нибудь по TDD. Плюсом документацию по выбранным технологиям. Несмотря на то что это скучно, в документации часто можно найти важные нюансы, которые редко встречаются в других источниках. Документацию можно заменить хорошими книгами по той же теме. Но тут сложно советовать абстрактно, не зная какой стек вы выбрали.

Достаточно много людей начинают работать на аутсорсе со 2-3 курса. Работа в команде для достижения уровня мидла дает больше чем 2 с половиной года по 8 часов в день.
Если 8 часов в день кодить, можно двинуться кукушечкой и до мидла не дотянуть.
Учи Английский, это правильно, говори на нем, в идеале с носителями, трать разумное время на теорию и практику в разработке, отдыхай и занимайся нетворкингом и успех тебе гарантирован.

Но я считаю что на реакте будет лучше.

Скажите просто несколько доводов в сторону реакт.

Вот вы нам и скажите )) Вы же говорите что на реакте лучше. Особенно про слабые библиотеки интересно услышать доводы.

Данная функция принимает аргумент constructor любого типа T, который является подтипом типа { new (...args: any[]): {} }

В свою очередь { new (...args: any[]): {} } - это абсолютно тоже самое, что и new (...args: any[]) => {}. Это сигнатура конструктора, с любым количеством любых элементов и инстанциирующий значение с типом {}.

Ну и тип {} - это множество всех не нулевых значений (не только объектов), то есть по сути это как тип any, но без null | undefined и с не сломанной вариантностью. Здесь его безболезненно можно заменить на тип unknown, в отличии от тех же аргументов, где из-за контрвариантности аргументов функций (и конструкторов) предикаты на типах ломаются и без any нормально не сделать.

В целом, под такой дженерик подойдет абсолютно любой конструктор

Подскажите самые простые учебники / статьи / видео курсы по React, где нормальным языком доступно объясняется.

Документация.

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

Значит, рано за react взялись. Это ОЧЕНЬ простая вещь - конечно, для тех, кто готов её осваивать.

фразы оттуда навроде "Подъём состояния в родительский компонент — обычное дело при рефакторинге React-компонентов." лишь отпугивают новичков вроде меня

Вот это хорошо. Новичкам react ни к чему.

C javascript знаком на базовом уровне

Этого мало.

Быстрее ли поиск в Map чем поиск в обычном массиве?

Поиск по ключу - конечно да. В случае массива, в худшем случае, придётся перебрать весь массив, а в случае с Map и Object поиск будет за константное время, но чуть большее, чем в массиве по номеру элемента.

А разницы между Map и Object особой быть не должно, но я бы предпочёл Map.

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