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

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

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

Увеличение диверсификации потребительских устройств

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

Что все это значит для нас, веб-разработчиков? Большее разнообразие устройств означает большее разнообразие платформ, а также типов и форм входов и выходов. Давно прошли времена единого веб-приложения (или веб-сайта) для ограниченного круга устройств.

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

Веб-разработчик слишком дорог

Разработчики программного обеспечения стоят дорого. Хороших разработчиков не хватает, и спрос на них продолжает расти. Прогнозируется, что к 2026 году только в США будет создано более 253 000 новых ролей разработчиков программного обеспечения. Это означает больше денег, потраченных на очень дорогую рабочую силу.

Пока что рынок отреагировал несколькими ограниченными действиями. Мы видели рост платформ типа drag-n-drop-low-code, которые ориентированы на неопытных программистов или разработчиков. Google App Maker, приложения Microsoft Power Apps и платформы веб-дизайна, такие как Wix, - вот лишь несколько примеров.

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

Написать хороший код не каждый сможет

Мы уже обсудили две основные проблемы:

• С ростом диверсификации устройств становится все сложнее и сложнее
• Как и у любого другого природного ресурса, у нас заканчиваются разработчики  

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

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

Почему создание веб-приложений такая сложная задача?

Написание веб-приложения требует огромной работы. Есть так много разных частей, которые нужно учитывать, каждая из которых может привести к сбою всего приложения. Как писал Питер Джанг в своем блоге («Современный JavaScript, объясняем динозавру»):

"Мы перешли от простого HTML и JS к использованию диспетчера пакетов для автоматической загрузки пакетов сторонних производителей, упаковщика модулей для создания единого файла сценария, транспилятора для использования будущих функций JavaScript и обработчика задач для автоматизации различных частей процесса сборки."

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

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

Компоненты всему голова

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

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

Позвольте мне привести слова Эдди Османи, известного автора:

«Если вы создаете компоненты для совместного использования, спросите себя, будут ли функции в вашем API использовать 90% пользователей. Если это так, то это скорее всего функциональность ядра должна остаться. Если эта функция будет использоваться 10%, это, вероятно, должен быть отдельный компонент или модуль. Избегайте раздувания кода».

Давайте пройдемся по списку всего хорошего в написании компонентного кода:

• Компоненты позволяют разделять задачи. Написание кода в виде компонентов делает разделение задач естественным делом. Каждый компонент заботится об одной задаче или функции. Это позволяет загружать обновления чаще. 
• Компоненты облегчают тестирование и поддержку вашего кода. Написание одноцелевых, небольших и простых кусочков кода делает понимание, тестирование, изменение и замену вашего кода намного проще.
• Компоненты допускают более абстрактное кодирование. Это означает, что для использования компонентов не требуется понимания фрагментов кода. Хороший компонент - это абстрактная сущность, которая готова к использованию в стиле API.
• Компоненты позволяют более надежную разработку. Куски кодов могут быть легко переданы, повторно использованы, изменены и заменены. Это означает, что адаптировать ваше приложение к чему-либо гораздо проще. 

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

От инженеров до архитекторов?

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

React и друзья

React, конечно, не нуждается в представлении, но несправедливо не упомянуть его в списке технологий, которые «продвигают концепцию компонентов». React это ультра-легкий каркас внешнего интерфейса. Он настолько легкий, что его сложно рассматривать как полноценную основу.

Процитируем официальный блог React:

«React не является основой MVC. React - это библиотека для создания компонуемых пользовательских интерфейсов. Он поощряет создание повторно используемых компонентов пользовательского интерфейса, которые представляют данные, которые меняются со временем».

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

Bit

«В философии Bit, компоненты - это строительные блоки, а вы - архитектор… »

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

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

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

Framer

Framer - отличный инструмент для разработки прототипов приложений. Он уникален по своему ландшафту, потому что позволяет создавать реальные компоненты, написанные на реальном JS/TS. Он привносит новую модульность в мир веб-дизайна, разумно используя компоненты для создания новых возможностей для разработки приложений.

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

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

Заключение

Заглядывая в прошлое, мы прошли путь от JQuery до React и сейчас находимся на пороге эры веб-компонентов и модулей ES.

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

Это будущее мира с постоянно ускоряющейся разработкой программного обеспечения.

Источник: hackernoon.com