Динозавр осваивает Modern Web - Часть вторая

Часть вторая - Что такое Modern Web и зачем он вам?

Предыдущая статья серии: Динозавр осваивает Modern Web - Часть первая

В первой статье этого поста мы выяснили, что игнорировать веб технологии не-Microsoft более невозможно, стало быть, нужно их изучать. Более того, картина мира такова, что именно за ними будущее веба, нравится вам это, или нет. Уверен, если вы пробовали погрузиться в предметную область, вы ни раз видели высказывания вида: "Смиритесь, это будущее", или "Просто примите это". Увы, другого пути просто нет. Мир Modern Web настолько отличается от привычного нам, динозаврам, что проще вымереть, чем его принять.

Так что же это такое? Для себя я был назвал его "суммой технологий". Основой веба, как десять лет назад, так и сейчас являются три ключевых "компонента":
• HTML
• CSS
• Java Script

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

Так, ключевыми элементами процесса разработки в настоящее время являются три базовых элемента:
• Менеджер пакетов
• Рендер-препроцессор
• Сборщик

Обратите внимание, что тут нет ни фреймворка, ни компилятора, ни веб-сервера - ничего из того что было бы нам известно. Что для чего нужно?

Менеджер пакетов используется для… загрузки, установки и публикации пакетов! Логично на нахера он нужен? Тут все просто: все придумано до нас, так что если вы собираетесь писать очередного "убийцу jQuery", тогда вы, скорее всего, захотите использовать сам jQuery, или любую другую готовую библиотеку. Для этого в общем-то и нужен менеджер пакетов. Если хотите, это местный аналог NuGet.

Рендер-препроцессор. Тут сложнее. Как я уже говорил, современный веб не использует абстракцию от веб-стандартов, он их улучшает. Соответственно, никто не пишет на чистом JS - это же самоубийство! Вместо этого все пишут на ES6, TypeScript, реже Dart/CoffeScript и других аналогах, которые позже нужно будет "скомпилировать", или, если правильно выразится "транслировать" в чистый JS. Для этого и нужен Рендер-препроцессор. Попутно этот компонент может выполнять и другие задачи, например, минификацию файла, обфускацию кода и т.д.

Функции сборщика еще менее понятны нам с вами. В нашем мире есть Build/Deploy и этим все сказано. Тут хер: все сам, все сам. Задача сборщика: собрать в кучу все пакеты (библиотеки и фреймворки) которые вы используете в своем проекте (а также их собственные зависимости!), прогнать и их и ваш собственный код через все необходимые препроцессоры, после чего выложить результат в нужном виде в нужное место. Тут нужно отметить, что вам, вероятно, нужен разный вид в разных средах: например, чистовая версия для продакшена должна быть минифицирована, или должна иметь другие переменные окружения и т.д.

Феномен номер 2. Обратите внимание, что все эти инструменты призваны получить готовый сайт, а не его абстракцию. Тут нет какого-то среднего слоя, типа ASP, Java, PHP, который выполнится на сервере и высрет в сокет комплект из HTML+CSS+JS. Единственные исключения - это, конечно, бэкэнд для работы с данными и авторизация. Но суть, думаю, ясна: различия в подходе фундаментальны.

Феномен номер 3. Все ненавидят JS, но все равно на нем пишут. Ненавистью к нему пропитана документация ко всем библиотекам и фреймворкам, что вы сможете найти, но все всё равно на нем пишут. Поэтому, они написали на нем Node.js и все его плагины Хотя, как мы с вами уже выяснили, это не совсем правда: для разработки используются "улученные" версии JS, которые уже вполне годятся для промышленного использования.

Феномен номер 4. Командная строка. Как видите, круг полностью замкнулся. Мы вернулись не только к архаичным стандартам, но и подходам. Понятно, что компилятору не нужен пользовательский интерфейс и где-то там, в недрах "современных" IDE он по-прежнему вызывается из командной строки, но зачем к этому возвращаться? Все просто: командная строка - это единственный инструмент, гарантированно присутствующий на всех платформах.

Феномен номер 5. Кросс-платформенность. Независимость от платформы - это какая-то мантра, современной разработки! Нужно отметить, что в чистой "кросс-платформенности" решительно нет ничего хорошего! Все эти платформы не зря такие разные - каждой есть чем гордиться и что противопоставить конкурентам. К счастью, в современном мире речь не идет о замене ста стандартов за счет сто первого, как это было, например, с Java. Теперь принято максимально напирать на "нативный" слой и абстрагировать от платформы лишь некоторый "рантайм", которому действительно, не так важно где выполняться.

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

Причина первая. Чтобы начать что-то делать разработчику нужно глубоко погрузиться в используемые технологии. Кто-то может сказать что это минус, но я как человек повидавший немало команд разработки могу сказать, что это плюс. Эта экосистема создает своеобразный барьер вхождения для программиста. Больше нельзя прочитать "MVC для чайников" и смело начать херачить отвратительный код в Visual Studio. Придется разбираться как все это работает на нижнем уровне, так как и программировать вы будете на нем же. Отсев слабых и ленивых разработчиков несомненно является плюсом для отрасли. Это справедливо как для компаний интеграторов, так и для конечных пользователей.

Причина вторая. Если разобраться, идея писать на JS серверный код не так безумна, как может показаться на первый взгляд. Во-первых, не нужно добавлять в стек новые языки и технологии, во-вторых, сервер ничем не хуже браузера! Если рендеринг на клиенте все равно придется делать, почему бы схожим образом не делать это на сервере? Во многом, именно поэтому за ними будущее: не нужно искать оптимальный баланс при распределении задач для обработки на сервере и клиенте. Первичный рендеринг может быть выполнен на сервере, передан клиенту и обработан им еще до того как активное содержимое будет загружено в память. Далее приложение будет выполняться уже на клиенте, а сервер, как ему и положено будет обрабатывать лишь запросы контента.

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

Итак, с концепцией разобрались. Что дальше? Об этом я расскажу в следующих постах этой серии:

Динозавр осваивает Modern Web - Часть третья