Основы Интернет-ресуры Литература уровня "Middle" и выше Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто "Frontend-разработчик", а более развернуто - "Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик". Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы. Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низшего уровня, к наивысшему и без привязки к инструментам/библиотекам)  Intern Frontend-developer - другими словами - стажер Junior Frontend-developer - уровень выше начального, уже более менее самостоятельная единица Middle Frontend-developer - самостоятельная единица, командный игрок, много умеет, но чаще всего в одной сфере / направлении. Через тернии к звездам или стремится к Senior Senior Frontend-developer* - старший, чаще всего в компаниях самый опытный. Человек, который попробовал многие инструменты, много может, много пробует.  Architector Frontend-developer** - человек, который часто занимается вопросами выбора технологий, решений в вопросах архитектуры будущего приложения TeamLead - глава команды - распределеяет задачи, связующее звено между командой разработки и бизнесом. Хороший управленец и разработчик  * - он может быть также ведущим разработчиком, который выполняет все те же функци, что и выполнял senior, но при этом отчасти может выполнять функции архитектора. Я видел компании, где понятия "ведущий разработчик" и "Senior developer" отождествлялись.  ** - Архитектор - достаточно размытое понятие. Иногда, в командах нет архитектора, но при этом есть techlead. Если загуглить, то он решает все те же задачи, что и архитектор.  Из списка выше и примечаний можно сказать одно - все эти "звания" относительны. И действительно, разработчик от компании к компании может занимать разные должности - "уровни". Например, в больших компаниях чаще всего занижают уровень - требования там выше в профессиональном плане, в плане знаний и умений.  Но даже несмотря на все эти условности, существует литература по уровням. Стажеру нет смысла брать книги с полки техлида о микросервисной архитектуре - все придет постепенно. Сейчас у стажера есть свои, не менее важные задачи, важные книги, материалы, интернет-ресурсы, которые он должен изучить.  Эта статья как раз о том сборнике книг для разработчиков уровня "Middle и выше".  У каждой книги есть своя цель, и у этой книги она тоже есть. Цель - напомнить вам о том, что есть в чистом js, что есть в браузере, что такое DOM и какие есть возможности у него.Она буквально вам говорит:  "Отвлекитесь от фреймворков и библиотек - посмотрите что умеет язык без этого!". На страницах есть краткая информация для повторения основных понятий в js, некоторых стандартных приемов работы, например, с событиями. Все это приправлено от души хорошими примерами кода.Книга хороша своим грамотным делением на главы и простым языком изложения. Тот самый случай, когда на ночь можно почитать не только с удовольствием, но и с пользой.   Мы поняли как работают события, что такое замыкания, как использовать генераторы, как убежать от адской пирамиды вызовов и самое главное - с помощью чего. Теперь время писать код. Вот только мы не знаем самого главного в любом коде - способов его организации. На просторах интернета и в книгах, о которых я напишу ниже вы сможете увидеть такие понятия как DRY, SOLID, KISS, YAGNI - это все общие положения, немного размытые, о построении архитектуры кода, приложения.  В Книге Фаулера идет полное описание каждого действия в момент рефакторинга кода. И да, Мартин Фаулер описал все способы - поверьте, Фаулер докопался и описал даже способ рефакторинга "Вынос в функцию". По факту - книга полноценный справочник или очень хорошая настольная энциклопедия, которая служит на благо архитектуры вашего кода.  Джон Резиг решил не вдаваться в подробности и не стал делать как многие авторы - описывать в первых главах все ключевые зарезервированные слова, встроенные методы перебора массивов и т. д. Книга Резига имеет скорее обзорный характер, она рассказывает о языке в целом, о его перспективах, некоторых интересных и уже всеми забытых методах валидации форм, об интересных моментах в работе с событиями в браузерах и о браузерах в целом. Не скажу, что это мега-полезная книга. Книга скорее служит исторической справкой об языке. Может быть, у меня сложилось такое ощущения, потому что я первой прочел "Секреты Javascript ниндзя". В той книге информации было как-то больше, но обращу внимание на начало второго абзаца - Труд Резига имеет обзорный характер. Возможно, в этом есть свои плюсы.  А что такое паттерны?  Паттерн проектирования — это типичный способ решения какой-либо часто встречающейся проблемы, возникающей при проектировании программ. Паттерны не являются готовыми решениями, которые можно сразу скопировать в свой код. Они представляют собой общее описание решения проблемы, которое после некоторой доводки можно использовать в самых разных ситуациях. Взято с RefactoringGuru Я уже говорил об DRY, SOLID, KISS, YAGNI. В электронной книге или на официальном сайте вы сможете ознакомиться с данными понятиями более подробно. Авторов можно поддержать - купить электронную версию, что я советую всем сделать. Труд был проделан огромадный. Я всегда был сторонником идеи "Если можешь объяснить ребенку что-то - значит ты владеешь этим на все 100". Книга "Погружение в Паттерны Проектирования" будет понятна наверное даже ребенку, потому что все очень подробно описано как в главах об архитектуре кода, так и в главах про устройство и построение архитектуры всего приложения. Естественно вся книга приправлена хорошими примерами реализации на псевдокоде, сравнительной характеристикой паттернов, выделением плюсов и минусов каждого решения и уместностью его использования.  Да, последние книги про архитектуру, но иначе никак - разработчик не должен писать код ради кода, он должен думать о пригодности этого кода в будущем. Даже не так - разработчик должен писать код ради бизнеса. А чтобы он был ради бизнеса, он должен быть поддерживаемым в будущем. Роберт Мартин писал книгу не для  Frontend-developer`ов, а для всех разработчиков и им сочувствующих. Мартин объяснил почему стоит уделять внимание архитектуре, как проводить архитектурный рефакторинг, с основными принципами, о которых также написано в refactoringGuru. (в refactoringGuru, как по мне, более подробно раскрыты некоторые моменты).Вопрос архитектуры приложений всегда для нас будет стоять ребром, потому что размер приложений с каждым днем увеличивается, а следовательно увеличивается их сложность. Если мы изначально будем строить неструктурированный продукт - бизнес загнется, а вместе с ним и мы с вами.  Лучший код там, где нас нет. Лучший код тот, который мы не писали. Любой код, который напишет один человек всегда будет заставлять другого напрягать голову и читать его. Именно поэтому в этой части, я уделил больше внимания архитектуре приложений, а не возможностям функционального, структурного, объектно-ориентированного программирования на javascript. Уделите время на архитектуру - она поможет другому разработчику чувствовать себя увереннее в вашем коде. Спасибо за внимание!  Lead в Yandex. Ex-Lead в Сбер