Что такое библиотеки яндекс практикум

Веб-тренажёр Яндекс.Практикума. Как всё устроено

Образовательный процесс важно делать интересным и по возможности интерактивным. Особенно, когда дело касается технологий — гораздо полезнее, когда есть возможность не просто написать какой-то код, а потом получить ответ от проверяющего, мол, молодец, всё хорошо, а на лету смотреть, всё ли у тебя работает, где косяки и как ты в целом справился.

В попытках сделать что-то подобное мы в свое время запустили в Яндексе MVP веб-тренажёра, в котором пользователь мог писать код, скрипты и всё остальное на разных вкладках, а по соседству у него всё это отображалось в качестве финального результата.

MVP показал себя хорошо, и мы вывели веб-тренажёр на уровень полноценного инструмента для проверки знаний наших студентов в Яндекс.Практикуме. Меня зовут Артем, и я расскажу, как мы делали тренажёр для обучения веб-разработке, как он работает и что умеет.

Со стороны кажется, что тут вообще всё просто — запихал весь пользовательский код в iframe, запостил его через postmessage, потом отрисовал любым доступным образом, и всё работает. Такой немного прокачанный онлайн-предпросмотр кода.

Как всё устроено

Мы на старте отметили возможную проблему: если разворачивать тренажёр на домене Яндекса (как сам Практикум, например), то появляется ненулевая вероятность, что пользователи окажутся чуть более любознательными. А именно — возьмут и закинут в тренажёр какой-нибудь код, который тренажёр с энтузиазмом примется обрабатывать. А код окажется мошенническим и уведет имеющуюся куку Яндекса, вставит её в какой-то сторонний сервис, после чего мошенник будет иметь доступ к личному кабинету пользователя в Яндексе и всем личным данным. Реализовать подобное довольно легко, если этот iframe находится в домене yandex.ru. Поэтому мы сделали отдельный домен на yandex.net специально под тренажёр и назвали его Фейнман (Feynman). В честь Ричарда, да.

В целом наш тренажёр хранит файлы, которые мы ему отправляем на бекенд, в формате plain text, json и base64 для изображений. Затем они преобразуются в реальные файлы и раздаются уже в виде статики, которую мы можем положить в iframe для отрисовки.

Но мы же тут не просто в подсветку синтаксиса играем, у нас тренажёр для проверки знаний. Поэтому нам надо этот код на лету тестировать и проверять, то есть каким-то образом вклиниваться в процесс iframe и смотреть, всё ли пользователь сделал правильно, скажем, как назвал переменную, или всё ли у него в порядке с div-ами.

И тут мы опять упираемся в домены. Пользовательский код, как я уже писал, кладется в тренажёр на домене Feynman, а проверяем мы его уже со стороны Яндекса, из домена praktikum.yandex.ru. Политика браузера same-origin как раз стоит на страже и не позволяет вам вмешиваться во внутренности iframe, если у вас домены разные.

Поэтому мы решили запихнуть iframe в iframe.

Получилась такая ситуация:

Не тестами едиными

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

Для этого была написана специальная библиотека, которая подгружает все необходимые стили и эмулирует responsive-режим. Также мы немного меняем наш исходный iframe и добавляем в него всё, что позволяет пользователю выводить на экран его console.log, и не только какие-то простые объекты, но и полноценные dom-деревья документа.

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

Для отдачи пользователю результата предварительного тестирования мы тоже используем postmessage — посылаем через него сообщения, нашлись ли какие-то ошибки или всё круто. Кстати, код студента на веб-тренажёре проверяется еще и через линтер es-lint с переводом на русский язык и всегда подсвечивает синтаксические ошибки.

Проблемы при проверках кода (и не только)

Если на странице были какие-то системные или браузерные уведомления, например, предлагалось что-то ввести, то часто при прогоне нашего теста пользователь продолжал видеть браузерные окна с уведомлениями и запросами на ввод данных. Нам надо было сделать вот так: когда пользователь просто запускает страничку со своим кодом, чтобы посмотреть, как всё работает, нужно, чтобы этот алерт тоже работал. А когда тест прогоняет этот код для проверки, нам уже не надо, чтобы алерты продолжали появляться у пользователя на экране. Мы по сути все эти алерты заменяли своими заглушками для тестов (мокали), переопределяя alert, prompt, confirm внутри window. Если этого не делать, можно было на выходе получить зацикливание или вообще пустой алерт, который ничего не делает.

Кстати, о бесконечных циклах. Основная проблема тут была в том, что пользователь мог заведомо взять и написать код, который благополучно уйдёт в бесконечный цикл (в браузере же всего один тред у javascript), и в итоге весь браузер шёл полежать.

Для борьбы с этим мы научились прежде всего отслеживать такие бесконечные циклы перед тем, как отдавать код на проверку. Чтобы сделать это, надо было каким-то образом переделать скрипт пользователя, мы пошли вот таким путем:

И для всех ссылок мы написали специальный обработчик: если видим, что ссылка внешняя, то отдаем postmessage наружу, обрываем сам обработчик ссылки (prevent default), и к нам обратно в наш фронт приходит postmessage. Мы видим, что у нас тут external link, и показываем уведомление — точно ли переходим на внешний сайт? И уже после этого открываем новые вкладки.

А ещё якоря, с ними всё было куда более как однозначно. Они просто не работали внутри iframe. Вообще. Поэтому мы в качестве небольшого хака подписались на события клика по любой ссылке — если на ней был якорь, мы делали scrollIntoView на конкретный элемент.

Все метаданные (если у пользователя на HTML-страничке была прописана фавиконка, например, или конкретный заголовок) мы тоже шлем через postmessage уже после того, как iframe загрузился. С помощью querySelector достаем два этих тега, через postmessage посылаем их обратно на наш фронт, а фронт уже сам вставляет все эти иконки, куда надо. Вроде бы мелочь, но у пользователя создается впечатление, что у него внутри браузера полноценный браузер.

Попытки обойти тренажёр

Наш веб-тренажёр, в отличие от тренажёров, которые мы делали для Python, SQL и прочего, использует для проверок именно фронт, а не бекенд. Поэтому, когда пользователь корректно завершает тесты, отправляется соответствующий POST-запрос на бекенд. В принципе, пользователь при должной сноровке может сделать то же самое и послать такой запрос вручную.

Тут палка о двух концах. С одной стороны, это круто, что человек в достаточной мере интересуется технологиями и базовыми хаками, чтобы такое проделать. С другой, это немного напоминает выстрел в ногу, у нас ведь тренажёр стоит не для того, чтобы формально получить от него «ОК, ты молодец вообще, всё сделал», а чтобы научиться нормально работать, замечать свои ошибки и исправлять их. В целом, это все равно как прийти в спортзал, посидеть 5 минут на скамье для жима лежа, а потом написать в фейсбучек «Сделал 3 подхода с сотней кило»: самомнение потешить получится, но на этом достижения и остановятся.

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

Мы постоянно улучшаем веб-тренажёр, пользуясь как собственным списком пожеланий, так и обратной связью от пользователей, так что будем продолжать вам рассказывать про его развитие. Сейчас он дорабатывается, учитывая потребности студентов с запросом на конкретные технологии, например, мы добавили работу с React и NodeJS. Веб-тренажёр на сегодня самый популярный из всех, за ним следует тренажёр для Python — по большей части это связано как с более низким порогом вхождения, так и с популярностью самих технологий. Кроме технической части внутри тренажёра ещё и множество механик для работы с интерактивной теорией (а её достаточно на всех наших курсах). Отдельного тренажёра нет только на специальности QA, там мы сделали специальный набор квизов + стендов, на которых и учатся тестировщики. Кстати, пара тестировщиков, которые сейчас помогают нам делать Практикум, — выпускники нашего курса QA.

Сложнее устроены тренажёры для C++ и тренажёр для машинного обучения, если вам будет интересно — постараемся рассказать о них в следующих постах.

Спасибо, что дочитали, если у вас есть какие-то вопросы по нашим тренажёрам или по Практикуму в целом — пишите, ответим.

Источник

Как стать программистом за 60 секунд или «Яндекс.Практикум» — НЕ ковчег судьбы

От автора

В данной статье я не хочу пытаться что-то доказать или опровергнуть, моя цель и мотивация лишь поделиться своими впечатлениями от сервиса по On-line образованию от «Яндекса» по направлению «WEB-разработчик», но суть статьи, как мне кажется, в целом о сервисе «Яндекс.Практикум». Я так же ни к чему не призываю и не от чего не отговариваю, хотя все же не так… призываю думать своей головой – говорят это полезно. Да бы вы не умерли от скуки читая очередную статью, постараюсь добавить немного юмора.

Погнали наши городских

Едем дальше…

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

Ваша остановка следующая

А если ты не такой как я описал выше, ты не ленивая попа, а очень даже старательная попенция, которой просто не хватает немножко знаний и практики что бы вот-вот стать программистом, отвечу – НЕ ТРАТЬ ДЕНЬГИ! Начни свой проект, пусть он будет небольшой, но твой и бесплатный, а дока на React.JS и Google тебе в помощь и делай, делай, и делай… потом возьмись за маленький и дешёвый, а может и даже совсем бесплатный проект и делай, делай, и делай… только так и НИКАК иначе ты сможешь стать тем кем так хочешь! Все остальное от лукавого, как бы сказал Ленин=)!

И что же, грустно выдохнув, спросишь ты, «Яндекс.Практикум» совсем, совсем никому не подходит? Почему же, конечно подходит, и в первую очередь тем, у кого тяжело в кармане, ну да-да есть те для кого 200т.р. и 300т.р. и более, сумма в принципе не большая и можно разок другой в бар не сходить и заплатить за очередной сервис Яндекса. Спорить тут не о чем, Вам советую СМЕЛО! Еще если вы студен и можете «потянуть», ну либо ваши родители могут «потянуть» то может быть данный курс расширит Ваш кругозор, если конечно его ранее кто-то уже не расширил (привет Эдуард Суровый!), и даст дополнительную корочку, на которую не посмотрят или посмотрят мельком и перейдут к реальным кейсам из вашего портфолио.

Последний Скрип

Курс «программирования» от Практикума». Не буду говорить хороший или плохой, так как не с чем сравнивать, а все познается в сравнении, в моём опыте он такой, как я описал выше.

Хорошую по качеству, но с хреновым принятом футболку. Эх Морфеус, Морфеус где же ты когда ты мне так нужен, сказал бы я, если бы Морфеус был бы дизайнером…

Опыт. Не встречал ещё ни одного человека, который бы учился только на чужом опыте, но встречал очень много тех кто, наступив в пятый раз на те же грабли радуется, что их еще не украли.

Источник

Опыт обучения из первых рук. Яндекс.Практикум – Аналитик данных

Как я пришла к «мысли» об аналитике?

Несколько лет занималась созданием интернет-магазинов и их обслуживанием (маркетинг, реклама, Яндекс.Директ и т.д.). Захотелось сузить сферу деятельности и заняться только тем, из этого широкого спектра, что нравится больше всего. Причем даже название будущей профессии не знала, были только примерные требования к рабочему процессу. Самостоятельное освоение программ и инструментов, никогда не было для меня препятствием, поэтому решила искать, где можно и опыт применить и освоить новое.

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

Начала изучать, что есть по информационной аналитике в плане получения второго высшего, но оказалось, что сроки обучения довольно велики для сферы, где всё очень быстро меняется, высшие учебные заведения, вряд ли успеют реагировать на это. Решила посмотреть, что предлагает рынок помимо Практикума. Большинство участников, снова предлагало очень долгие 1-2 года, а хотелось бы параллельного развития: вход в профессию на нижних позициях и дальнейшее обучение.

Что хотелось в профессии (рабочий процесс не рассматриваю)

Итак, выбор пал на Яндекс.Практикум из-за:

Как проходит учебный процесс?

Для начала Вы должны пройти бесплатный вводный курс по Python и выполнить все задания, так как, не выполнив предыдущее, не появится следующее. Так построены и все последующие задания в курсе. Так же, объясняется, в чем заключается профессия и стоит ли идти на курс.

Помощь можно получать в Фейсбуке, Вконтакте, Телеграмме и основное общение в Slack.
Основная доля общения в Slack происходит с преподавателем при прохождении тренажера и при выполнении проекта.

Кратко, об основных разделах

Начинаем обучение с углубления в Python и начинаем использовать Jupyter Notebook для подготовки проектов. Уже на первом этапе выполняем первый проект. Так же происходит ознакомление с профессией и требованиями в ней.

На втором этапе происходит обучение обработке данных, во всех ее аспектах, и начинаем изучать и анализировать данные. Здесь добавляется еще два проекта в портфолио.

Затем идет курс по статистическому анализу данных + проект.

Первая треть пройдена, делаем большой сборный проект.

Далее обучение работе с базами данных и работе на языке SQL. Снова проект.
Теперь углубление в анализ и маркетинговая аналитика и конечно же проект.
Далее – эксперименты, гипотезы, А/В-тестирование. Проект.
Теперь наглядное представление данных, презентация, библиотека Seaborn. Проект.

Вторая треть пройдена – большой сводный проект.

Автоматизация процессов анализа данных. Потоковые аналитические решения. Дашборды. Мониторинг. Проект.
Предсказательная аналитика. Методы машинного обучения. Линейная регрессия. Проект.

ВЫПУСКНОЙ ПРОЕКТ. По результатам которого, получаем сертификат о дополнительном образовании.

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

Все проекты проверяются менторами Яндекс.Практикума – работающими аналитиками. Общение с ними так же оказалось крайне важно, они и мотивируют, но для меня самое ценное проработка ошибок.

Важная часть это — видео-конференции с наставниками и видео-тренинги с приглашенными практикующими специалистами.

Существуют и каникулы)) – по одной неделе между двумя третями. Если процесс идет по расписанию, Вы отдыхаете, а если не очень, то доделываете хвосты. Так же есть и академический отпуск, для тех, кто по каким-то причинам должен отложить обучение.

Немного про тренажер

Курс новый, но видимо основываясь на других курсах, специалисты Яндекса знают, как иногда тяжело приходится, когда наступает перегруз и информация «не заходит». Поэтому решили максимально развлечь учащихся веселыми рисунками и комментариями, и надо сказать, это действительно помогало в моменты отчаяния, когда «бьешься» над заданием.

А отчаяние иногда наступало:

Совет будущим студентам – 90% ошибок больше от усталости или перегруженности новой информацией. Отвлекитесь на полчаса – час и снова пробуйте, как правило, за это время Ваш мозг переработает и решит всё за Вас)). И 10% если Вы не поняли тему – перечитывайте еще раз и все обязательно получится!

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

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

Недостатки и не совсем оправданные ожидания, куда же без них

Часть статей рекомендует Яндекс.Практикум, но этого недостаточно. Могу порекомендовать, параллельно дополнить курсами на Stepik – Big Data для руководителей (для общего развития), Программирование на Python, Основы статистики обе части с Анатолием Карповым, Введение в базы данных, Теория вероятностей (первые 2 модуля).

Источник

Что нужно знать о популярных JS-фреймворках

Привет! Меня зовут Дима Чудинов, я наставник на веб-факультете Яндекс.Практикума, Head of Group, Front-end, ABBYY.

Студенты недавно задали мне вопрос: «Что лучше: Angular или React?». Я начал отвечать и понял, что мне понадобится для этого статья. Позже я понял, что и одной статьи не хватит.

О том, какой фреймворк выбрать, я расскажу в другой раз. А в этой статье опишу историю создания фреймворков и их особенности. Выбрать рабочий инструмент статья не поможет. Зато поможет вести споры с другими разработчиками на кухне (если не будет карантина) и в сети. Статья будет полезна новичкам, которые только начинают своё знакомство с фреймворками и библиотеками, и поможет взглянуть на «зоопарк» веб-технологий сверху.

Библиотеки и фреймворки

Для начала важно понимать, что библиотека и фреймворк — не одно и то же.

Библиотеки

Библиотека — код, который встраивается в приложение и решает ограниченный набор задач в зависимости от того, какие обязанности на нее возложили разработчики.

Как правило, библиотека — контейнер для набора классов и/или функций, которые разработчики могут использовать в своем приложении. Например:

Фреймворки

Фреймворк — каркас приложения, который состоит из набора библиотек.

Вместе они дают возможность пользователю выстроить свою функциональность на некотором фундаменте. Фреймворк задаёт структуру и подход к архитектуре вашего приложения, он диктует, как вы должны писать код. Например:

Что и когда используют

Приложение может быть построено как только на одних библиотеках, так и на одном фреймворке. Но чаще всего разработчики используют фреймворк и сторонние библиотеки одновременно.

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

Как правило, новички начинают либо с нативного JS без использования библиотек/фреймворков, либо с одного из популярных фреймворков. Изучают его, находят слабые места и пытаются со временем закрыть их библиотеками.

Более опытные разработчики уже знают подводные камни многих инструментов и выбирают технологический стек исходя из задач. К примеру, один из частых наборов инструментов — React и Redux — библиотеки, которые не дают готового решения и каркаса, а открывают путь для творчества.

Что было раньше

React, Vue, lodash, D3… новичку порой сложно разобраться в этих названиях. Так в сети появилась шутка от разработчика, который всегда просит рекрутеров назвать, кто из стека в его профиле — покемон. Сможете отгадать?

Интерпретация мема: «I typically ask recruiters to point out which of these are pokemon»

Google в 2000-е и сейчас. UX сильно отличается: изначально он был сделан на стандартных html-контролах, теперь это более сложные и стилизованные компоненты.

Не было статей и вопросов в интернете на тему, какой фреймворк выбрать: «React, Angular или Vue?». Разработчики фокусировались на реализации функциональности и наполнении веба. Но были и пытливые умы, которые старались ускорить разработку и создавали библиотеки — с ними можно было писать меньше кода. Такие библиотеки давали возможность инженерам создавать более «богатые» приложения с динамикой, анимацией и прочими радостями, которые есть сейчас.

Первые шаги к приложениям будущего

В марте 2005 года появился Dojo Toolkit, который содержал виджеты, методы для работы с локальными хранилищами и REST-клиент. В июне 2006 года была выпущена альфа-версия библиотеки jQuery, которая включала в себя методы для манипуляций с DOM, работу с событиями, методы для анимаций и модуль AJAX. Все эти инструменты помогали унифицировать разработку, не писать одни и те же утилиты, шаблоны, а брать готовые протестированные модули.

JavaScript: ES3 и ES5

Javascript тогда заметно отличался от современной версии как по синтаксису, так и по возможностям. В 1999 году был опубликован стандарт ECMAScript 3. Он содержал хорошую базу той функциональности, что мы имеем сейчас. А вот стандарт ECMAScript 5 2009 года уже имел особенности:

Переход к новому стандарту позволил сделать огромный шаг в развитии фронтенда, а именно Javascript. Как изменилось написание и объём кода можно увидеть на примере маленькой задачи:

Куда делся ES4

ECMAScript 4 был амбициозным проектом, но по слухам имел плохую совместимость с ES3. В итоге после долгих прений, техническим комитетом TC-39, в который входили участники из Google, Intel, Microsoft, Facebook, было принято решение продолжить работу над ECMAScript 3.1. Позже, в 2009, этот проект был переименован в ECMAScript 5.

Эра фреймворков

Новый стандарт дал огромный толчок развитию как Javascript, так и созданию новых фреймворков.

Backbone.js

В 2010 году появился Backbone.js — библиотека, которая реализует MPV (Model-Presenter-View) паттерн. С помощью Backbone.js можно было создавать SPA с клиентским рутингом. До этого клиентский рутинг был диким неукрощённым зверем, поэтому повсеместно использовали вариант с отдачей шаблонов — серверным рутингом.

На Backbone.js написано много приложений, некоторые до сих пор поддерживаются. Особенность приложений на Backbone.js — частое использование CoffeeScript от того же автора. Он предоставлял более широкие возможности по сравнению с Javascript: код выглядел короче и был более читаемым, были стрелочные функции и наследование. Но, к сожалению, эти технологии забыты на новых проектах, хотя и оказали колоссальное влияние на разработку.

AngularJS

В это же время произошёл релиз AngularJS от Google — полноценного фреймворка, который включал не только каркас приложений, но и средства для тестирования. Изначально этот фреймворк завоевал сердца разработчиков — на нём написано множество популярных сайтов. Например, сайт МакДональдса:

Сайт МакДональдса, написанный на AngularJS

Но несмотря на свою популярность, AngularJS сильно разочаровал разработчиков. Как так вышло — расскажу дальше.

Ember.js

2011 год принес Ember.js — ещё один SPA фреймворк со встроенным шаблонизатором Handlebars. Сам же фреймворк построен на классической архитектуре MVC (Model-View-Controller). У Ember очень дружное комьюнити, которое развивает инструмент и не останавливается, — даже в 2020 году у фреймворка есть роадмап и цели по развитию. Всё ещё можно встретить статьи: «Как мигрировать с React на Ember», поэтому этого старичка не стоит списывать со счетов.

Библиотек и фреймворков становилось всё больше и больше. Поэтому в 2010-х годах разработку разделили на бэкенд и фронтенд — стало сложнее найти специалиста, который знал бы серверные технологии, все тонкости JS и необходимого фреймворка, ведь каждый из них имел свои особенности. Работодатели начали оценивать не общий кругозор в веб-разработке, а умение пользоваться конкретной технологией, на которой можно выстроить новый продукт.

Хороший маркетинг — AngularJS

В 2010 году разработчики Google выпустили фреймворк AngularJS. Поддержка крупной компании и хороший маркетинг сильно выделяли его среди равных — Backbone и Ember.

Кроме этого, AngularJS предлагал на тот момент интересный подход — two-way data binding (с англ. двустороннее связывание данных), который ещё не был широко распространён в разработке.

Особенности AngularJS

AngularJS — полноценный фреймворк, целью которого было упростить разработку Single Page Applications.

Основная особенность фреймворка в том, что отображение может менять модель, как и модель — менять отображение. Это нужно, чтобы связать действия пользователя. Например, пользователь вводит данные в поле → обновляется модель → посылается запрос на сервер → приходит ответ с сервера → обновляется модель → обновляется представление. Это и есть принцип two-way data binding.

Схема взаимного обновления модели и представления

Еще AngularJS привнёс несвойственный клиентским приложениям паттерн проектирования — Dependency Injection (с англ. внедрение зависимости).

Упрощённая схема работы паттерна Dependency Injection

Этот механизм позволяет легко подключать нужные зависимости модулям. Внедрение зависимости можно представить так: у вас есть команда, которая состоит из разработчика (контроллер), дизайнера (сервис) и контент-менеджера (константа). Все они сидят в одном кабинете (DI контейнер). Когда разработчику нужен макет, он обращается к дизайнеру, а тот берёт наполнение для макета у контент-менеджера. Это легко и быстро, ведь все они сидят в одном кабинете. На выходе разработчик получается всё необходимое для реализации проекта.

Но AngualrJS не был бы фреймворком, если бы держался на паре паттернов. В него входит множество сопутствующих инструментов:

AngularJS изменил многое в мире разработки. Появилось всё больше специалистов, которые помогали компаниям ускорить разработку приложений, переписать или написать новые с помощью этого инструмента. Но AngularJS не был идеальным фреймворком и разбил много сердец.

Недостатки

AngularJS тянул с собой облегчённую версию JQuery — JQLite. Это было некоторым оверхедом для приложений, где JQuery был не нужен или у разработчиков была на него аллергия, для современных же приложений — совсем плохая практика.

Но основная проблема была в “digest loop” и его производительности. Digest loop — то, на чём держится тот самый магический two-way data binding. Этот цикл работает так: при изменении модели запускаются все слушатели и происходит сравнивание текущих значений модели с предыдущими. Если функция слушателя изменяет модель, этот цикл будет повторяться до окончания сверки, то есть пока модель не перестанет меняться. Даже если функция слушателя ничего не поменяла, цикл запустит проверку минимум один раз, чтобы убедиться в консистентности модели.

Принцип работы digest loop в AngularJS

Тут и начинается проблема производительности из-за множественного запуска цикла и частых обновлений представления и модели. Это особенно ощутили разработчики, которые работали с “realtime data” или чьи приложения содержали большие и часто изменяемые модели.

Проблему производительности так и не удалось исправить в AngularJS, ведь тогда пришлось бы переписать ядро и отказаться от обратной совместимости. Поэтому чуть позже появился Angular 2+ или просто Angular.

Работа над ошибками — Angular 2

В 2014 году в тёмных лабораториях Google неподалёку от зоны 51 (Area 51) начал создаваться новый фреймворк — Angular.

В сентябре 2016 была опубликована первая версия финального релиза. После этого — анонс Angular 4, а 3 версия была пропущена. Это смутило разработчиков — все боялись повторения опыта AngularJS, связанного с поднятием мажорных версий и отсутствием обратной совместимости. Но, напротив, 4 версия была полностью совместима со 2.

Angular начал регулярный выпуск новых версий с поддержкой обратной совместимости и добавления новой функциональности и оптимизаций. На момент написания статьи последняя версия Angular — 11.

Особенности Angular

Разработчики учли слабые места AngularJS. Изюминкой Angular 2 стал компонентный подход, которого не было в первом, добавилась изоморфность и, конечно же, — Typescript.

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

Разработчик определяет размер компонентов — это могут быть как атомарные части кода, так и большая подсистема, которая состоит из множества подкомпонентов.

Так выглядит небольшой компонент в Angular:

В Angular компоненты могут иметь собственное состояние, но если нужен глобальный state, то можно использовать сервисы и подключать их через Dependency Injection. Если поток данных более сложный и включает в себя много трансформаций, то, как правило, используют библиотеку NgRx.

Ещё несколько новых возможностей Angular по сравнению с AngularJS:

Недостатки

Typescript — не только особенность, но и недостаток Angular. Это отталкивает новичков, ведь писать без него Angular-приложения нельзя. Проблемы Typescript для обывателя: строгая типизация, ошибки, которые порой поправить очень сложно; разные концепты, такие как сложные типы, модификаторы доступа, дженерики, которые нужно понимать.

Кроме этого, Angular — фреймворк с богатыми возможностями, на изучение которых требуется время, нет, скорее, много времени. Поэтому иногда новички сдаются и переходят на более «лёгкие» фреймворки. Но те, кто упорно продолжает осваивать Angular, — редко в нём разочаровываются.

Серебряная пуля от Facebook — React

В 2011 году команда Facebook проводила эксперименты по созданию фреймворков, которые решали бы проблему производительности, а именно — каскадных обновлений. Существовавшие на тот момент решения — AngularJS, Backbone, Ember, Knockout — не давали нужного результата.

У Facebook появилось прототипное решение — FaxJS. Этот проект имел свои особенности:

Изначально на FaxJS построили Facebook Ads Org, а затем Instagram испытал его на своей ленте. Проект FaxJS был экспериментальным и дал начало знаменитому сегодня React. В 2013 React был уже представлен как open-source библиотека на JSConf US.

React — библиотека для отображения данных, которая включает в себя Virtual DOM, JSX, изоморфность и компонентный подход. Грубо говоря, React — это умный шаблонизатор.

Особенности React

Virtual DOM, или виртуальный DOM, — легковесная копия реального HTML DOM в виде JS-объекта в памяти, с которой работает приложение. Он агрегирует в себе все динамические изменения, а уже после применяет их к реальному DOM.

Основная проблема нативного HTML DOM — его скорость при работе с динамическими данными: из него дорого как читать, так и много и часто писать. Виртуальный DOM не является простым объектом, который хранит данные, он имеет эффективные и производительные алгоритмы для сравнения и группировки изменений и выборочных изменений отдельных частей HTML DOM.

Упрощённый пример виртуального DOM:

Другой новый концепт, который привнёс React, — JSX (Javascript and XML). Это синтаксический сахар или, по-другому, расширение JavaScript. JSX напоминает язык шаблонов, наделённый силой JavaScript.

Результат превращения в JS:

Мы уже говорили про архитектурные паттерны MVC и MVVM, так вот React и его компоненты — это буква “V” в MVC/MVVM, то есть view или представление. Такой подход позволяет писать переиспользуемые компоненты и собирать большие функциональные блоки с помощью композиции более мелких компонентов. Так можно описать форму, которая состоит из разных атомарных компонентов на JSX:

С помощью такого компонентного подхода и композиции можно формировать представления любой сложности.

Недостатки

React — слой представления, который не имеет никаких моделей. Иначе говоря, в нём негде хранить данные. Более того, их практически нельзя переиспользовать между компонентами, ведь передача свойств из компонента в компонент на несколько уровней ведёт к антипаттерну — prop drilling.

Проблема такого поведения в том, что при изменении этих данных — добавлении или удалении свойства — требуется пройтись по всем компонентам, где происходит передача, и сделать исправления. Кроме этого, сами свойства могут изменяться (новое имя или информация). В любом случае подход prop-drilling тратит много ресурсов разработчиков и ведёт к появлению багов.

Схема передачи свойств через множество уровней компонентов, что приводит к prop-drilling

Разработчики Facebook понимали эту проблему и добавили в экосистему React новый инструмент — Flux.

Попытка уложить всё по полочкам — Flux

Flux — не только библиотека для хранения глобального состояния приложения, но и архитектурный паттерн. Этот инструмент в первую очередь был представлен в дополнение к React, хотя сама архитектура может применяться где угодно, иначе говоря, framework-agnostic.

Особенности

Схема передачи данных между компонентами в React, как и у любого приложения, которое использует подход MVVM, выглядит так:

Обычная схема взаимодействия многих MVVM-фреймворков

Это катастрофа, которую и призван был решить Flux. Главная цель Flux — сделать движение данных в приложении предсказуемым: они всегда должны двигаться по одному пути.

Flux состоит из 4-х главных частей:

Так выглядит однонаправленный поток:

Схема движения данных во Flux-архитектуре

Недостатки

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

Поэтому в 2015 году Даниил Абрамов и Эндрю Кларк представили комьюнити новый инструмент — Redux. Он реализует Flux-архитектуру, но при этом имеет некоторые преимущества.

На этот раз получилось лучше — Redux

Redux — библиотека с простым API, хранилищем состояния приложения, или state container с однонаправленным потоком данных. Во Flux содержится множество хранилищ, в Redux — одно глобальное.

Особенности

Поток данных в React с Redux и без него имеет огромные отличия. Представьте, что вы продаёте значки: самостоятельно ищете точки сбыта через знакомых, что может быть сложно и неэффективно. Так работает React без Redux. Но стоит добавить Redux, как появляется большая площадка для сбыта — Redux store. Это можно сравнить с Wildberries или Lamoda, куда продавец выставляет товар и не тратит время на продажу самостоятельно. Так это выглядит на схеме:

Сравнение передачи данных в React с использованием Redux и без него

Схема потока данных в Redux:

Схема движения данных в Redux

Вам уже знакомы почти все элементы, кроме Reducer.

Reducer — чистая функция, которая принимает действие (Action) и изменяет состояние приложения, иначе говоря, модель. При этом она не мутирует его, а возвращает всегда новое состояние. Поэтому компоненты могут быть оповещены об изменении разных частей хранилища.

Несмотря на то, что Redux был создан с фокусом на React, он вполне нашёл себе применение с другими библиотеками и фреймворками, даже с AngularJS.

Недостатки Redux

Redux немного удручает большим количеством бойлерплейта (кода, который нужно писать, хотя он не несёт в себе логики): на каждую команду нужно написать Action (иногда асинхронный), Reducer, Selector. Чем больше кода пишешь, тем больше бандл.

Комьюнити позиционирует Redux простым инструментом, но с ним всё равно нужно «набить руку»: изучить тонкости и способы применения, научиться проектировать хранилище, а это, как правило, не всегда получается с первого раза.

На связке React и Redux пишут много проектов, поэтому Redux популярен и в 2020 году. Это не самая простая библиотека, а правильное её применение требует знаний и опыта.

От Multipage к SPA и обратно — Next.js

До этого я рассказывал про SPA-фреймворки, которые динамически могут строить страницы без перезагрузки. SPA-приложения обычно включают в себя много кода, который нужно получить при первом старте приложения. Это бьёт по быстродействию открытия страницы и конечно же влияет на UX (с англ. User Experience). Кроме этого, поисковые боты не особо расположены индексировать страницы, построенные на JS, — в 2020 году Google-Bot один из немногих, кто индексирует SPA.

Влияние скорости загрузки страницы на настроение пользователя

До новомодных SPA в тренде был подход multipage, который не имел таких проблем. При этом, чтобы отобразить новое состояние страницы, её нужно было перезагрузить.

Объединить две стратегии работы с приложением взялась компания ZEIT. Так в 2016 году был выпущен SSR (Server Side Rendering) фреймворк — Next.js. Он работает поверх React и позволяет быстро писать и разворачивать multipage приложения, а после получения страницы — работать как с полноценным SPA.

Особенности

Главная особенность Next.js — SSR. Этот фреймворк построен поверх React, поэтому вовсю использует его изоморфность, что позволяет отдавать шаблоны с преднаполненными данными. После этого на страницу добавляется скрипт, который не блокирует построение DOM, и впоследствии загружает весь необходимый JS для динамической работы со страницей. После отображения данных, пользователь взаимодействует со страницей как с полноценным SPA-приложением.

Сode-splitting (с англ. разбивка кода) — ещё одна важная особенность, которая позволяет ускорить открытие отдельных страниц. При получении отдельной странички мы передаём в качестве JS-кода не всё приложение, а лишь малую его часть. Поэтому передача данных по сети происходит быстрее — браузер выполняет код и не тянет лишние зависимости, которые не будут использоваться на нужной странице.

С Next.js можно колоссально сэкономить время на развёртывание приложения — достаточно одной команды. Кроме этого, он берёт на себя всю чёрную работу, которая не всегда приносит удовольствие.

У него есть ещё пара особенностей:

Недостатки

Идеальных решений не бывает и под все задачи просто не существует универсального инструмента. Так и Next.js заставляет разработчиков принимать свою прибитую гвоздями структуру, которая нужна для корректной сборки и работоспособности приложения.

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

Кроме этого, Next.js — большой проект, в который придётся вникать, хотя документация и комьюнити весьма хороши.

В 2015–2016 годах было много холиваров на тему SPA vs SSR. Всё новое — хорошо забытое старое, поэтому разработчики с удовольствием встретили multipage-подход, предложенный Next.js. Тем не менее SPA приложения ничуть не потеряли популярность, а, наоборот, стали дополнять SSR. В 2020 году прекрасно применяется как SPA-, так и SSR-подход — каждый из них решает свои задачи и подходит для определённых типов приложений, а количество холиваров на эту тему заметно уменьшилось.

Из Китая с любовью — Vue.js

В 2014 году React только набирал обороты, AngularJS, наоборот, утрачивал свою популярность, а Angular находился ещё в стадии активной разработки. У фронтенд-разработчика уже был большой выбор инструментов, но не все проблемы фреймворков и библиотек были разрешены. Например, сохранялись такие проблемы, как высокий порог входа, низкая скорость разработки и необходимость писать большое количество кода, чтобы приложение «взлетело». Для решения этих проблем появился новый фреймворк — Vue.js. Его создатель, бывший сотрудник Google, активно использовал AngularJS в своей работе, поэтому Vue.js синтаксически на него похож.

У Vue.js был долгий путь становления — фичи добавлялись от релиза к релизу. В начале многие предсказывали ему провал, но с выходом новых версий он только набирал популярность: последняя версия 3.0 вышла в 2020 году. В развитии ему помогло сплочённое азиатское комьюнити разработчиков, а в популяризации — евангелисты.

Довольно быстро фреймворк вошёл в топ-3 китов и стал тягаться с Angular и React:

Сравнение статистики топ-3 фреймворков на Github

Особенности

Vue позаимствовал лучшие практики из разных инструментов.

Cинтетический пример использования шаблонов:

Пользователям понравилось в этом фреймворке многое: от низкого порога входа до скорости разработки приложений.

Из особенностей Vue.js выделяют:

Vue не привнёс что-то новое, он взял уже наработанный багаж знаний из React/AngularJS/Angular и других инструментов, убрал раздутое и сложное API и привёл всё к минималистическому виду.

Vue.js — простой фреймворк, поэтому не нужно долго изучать его экосистему, искать дополнительные библиотеки и писать под него сборку. У него подробная документация, которую многие ставят в пример. На Vue можно быстро писать производительные приложения.

Недостатки

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

Хорошая новость: комьюнити выросло и появился неплохой опыт разработки на Vue.js, поэтому эти проблемы практически себя изжили.

Другой недостаток — компонентный подход не дотягивает до конкурентов вроде React по гибкости. Но в этом нет вины Vue.js, ведь это фреймворк, который предоставляет инструменты для полного цикла разработки приложения. Тогда как React — библиотека для рендеринга, которая в основном фокусируется на компонентном подходе.

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

Черная магия — Svelte

Казалось бы, топ-3 лидеров продакшена очевиден и устоялся, но комьюнити этих инструментов было недостаточно. Им нужен был быстрый и простой фреймворк, который виртуозно решает повседневные задачи, имеет всё из коробки, и его результирующий код не занимает много места. Последним не могут похвастаться ни React, ни Angular, ни Vue.

Svelte впервые презентовали сообществу в 2016 году, но первая версия особо не продвигалась. Популяризация фреймворка началась со второй версии в 2018 году, а с выходом третьей версии о нём наконец заговорили в комьюнити.

Особенности

Принцип работы Svelte: мы пишем высокоуровневый код с использованием декларативного подхода — описываем, что нужно сделать, а фреймворк уже решает, как это сделать. Иначе говоря, мы описываем результат, а не путь его достижения. На выходе Svelte отдаёт уже низкоуровневый и оптимизированный код, который эффективно работает, например, в браузере.

Как работают Svelte и React под капотом

По сути, Svelte — это компилятор, который не несёт собственный код в результирующую сборку, что выделяет его среди других инструментов. Для сравнения посмотрим на таблицу с размерами минифицированных бандлов библиотек и фреймворков без учёта кода приложения:

Со временем цифры уменьшаются, но у Svelte по-прежнему остаётся 0.

Кроме этого, Svelte может похвастаться:

Неудивительно, что Svelte активно набирает популярность с таким набором особенностей. А ещё он дружелюбен для новичков и имеет хороший интерактивный туториал.

Недостатки

Бедный CLI или, точнее, отсутствие официального поддерживаемого CLI для Svelte — ощутимый недостаток. Ведь генерация каркаса и сборка возможна только с помощью сторонних шаблонов для развёртывания проекта.

Кроме этого, у Svelte небольшая экосистема по сравнению с React, Vue и Angular. Не всегда просто найти какой-то готовый компонент или библиотеку для Svelte, как в React. Чтобы отыскать альтернативы, потребуется время. Возможно, нужно будет доработать их напильником, а в итоге может оказаться, что они не подходят из-за отсутствующей функциональности или багов.

Ещё один недостаток — небольшое комьюнити. Этот вывод можно сделать по количеству вопросов на https://stackoverflow.com/, где их заметно меньше, чем у Angular или Vue.

Фреймворк Svelte не поддерживается корпорациями, а продвигается за счёт комьюнити. Несмотря на отсутствие больших вложений в маркетинг, Svelte обзавёлся 40k stars на github. Его часто обсуждают на профессиональных конференциях и в блогах, что говорит о его потенциале.

Заключение

В 2020 году лидерами среди фреймворков и библиотек по-прежнему остаются React, Angular и Vue.

Но на горизонте за предыдущие несколько лет уже появились интересные проекты с открытым кодом и большим потенциалом, например Svelte.

Если вам захочется освежить в памяти все рассмотренные фреймворки и библиотеки из этой статьи, просмотрите таблицу:

Полезная литература

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

Источник