Стефан помогает разработчикам стать агностиками фреймворков. Если вы найдете его содержание полезным, вы можете купить ему кофе здесь и получить его эксклюзивную электронную книгу 10 причин отказаться от фреймворков бесплатно!
Я веб-разработчик с 2003 года и видел, как много технических стеков приходят и уходят. Тогда не было такой вещи, как JavaScript-фреймворк, и язык не был таким продвинутым, как сегодня. Он даже считался второстепенным языком по сравнению с Java и C (хотя на самом деле это совсем другое). С появлением таких фреймворков, как React, Angular и VueJs, JavaScript, наконец, стал мейнстримом, и теперь Интернет зависит от него.
Сегодняшнюю сеть невозможно представить без фреймворков JavaScript. Создание приложений JavaScript с помощью фреймворка дает множество преимуществ, например:
- Экономьте энергию. Современные фреймворки JavaScript содержат передовой опыт, инструменты для создания шаблонов, парадигмы и отраслевые стандарты, которые позволяют разработчикам создавать приложения в кратчайшие сроки. Это позволяет разработчикам сосредоточиться на разработке реального приложения вместо необходимых инструментов и архитектуры.
- Повторно используемый код. Компоненты, созданные с помощью платформы JavaScript, взаимозаменяемы, поэтому командам не нужно дважды изобретать квадратное колесо.
- Общий язык для команд. Использование фреймворка JavaScript приводит к общему пониманию как внешних, так и внутренних разработчиков. Все говорят на одном общем языке.
Именно из-за этих преимуществ почти все команды фронтенд-разработки используют фреймворки JavaScript для создания приложений.
Другая сторона медали ...
За время работы в качестве веб-разработчика я работал над множеством проектов, и каждый новый проект всегда начинается с выбора подходящего фреймворка JavaScript. Какой отличный способ начать проект! Фреймворк решит все мои проблемы и сэкономит мне много времени и сил! Другие товарищи по команде и даже другие команды полностью поймут архитектуру и компоненты, которые я создал, верно?
Приведу 3 реальных примера компаний, в которых я работал:
- Раньше я работал в компании размера предприятия, где несколько команд фронтенд-разработки работали над разными частями приложения. Все команды выбирают Angular в качестве предпочитаемой среды JavaScript. Вместе они создали библиотеку общих компонентов в Angular (v2), чтобы сэкономить время, деньги и энергию, но здесь была одна загвоздка. Вышел Angular (v4), и несколько команд выполнили обновление. Новая версия содержит некоторые критические изменения, и команды быстро поняли, что общие компоненты стали бесполезными. Идея библиотеки общих компонентов заключалась в экономии времени, денег и энергии, но на самом деле все было наоборот. Команды должны вкладывать дополнительное время, деньги и энергию в обновление библиотеки общих компонентов; Расточительство и источник разочарования.
- Другой проект, над которым я работал, был для другой корпоративной компании, которая разработала приложение на AngularJs. Это все еще работает, но ответственная команда ушла и выполнила другие проекты, как и их технический стек. Они пошли дальше и перешли на Angular в качестве предпочитаемой среды JavaScript. Наняты новые члены команды, и от них больше не ожидается, что они будут изучать AngularJs. Но знаете что? Это приложение, построенное на AngularJs, которое все еще набирает обороты, нуждается в новой функции, чтобы обеспечить лучший пользовательский интерфейс для клиентов.
- Я работал в компании, где несколько команд фронтенд-разработчиков с разными техническими стеками работали над разными частями приложения. Команды известны своей самоуправляемостью и очень автономными. Задача для компаний, которые хотят обеспечить единообразный пользовательский интерфейс и внешний вид для конечных пользователей. Большая проблема для команд (и компании) заключается в том, что компоненты не подлежат замене между командами, что требует очень много времени и затрат.
Общая тема этих примеров из реального мира - неэффективность, и я уверен, что это происходит и в вашей компании.
Задача компании состоит в том, чтобы повысить автономию внутри команд и предоставить им свободу выбора в стеке, который они делают, но в то же время вы также хотите производить высококачественные продукты, не неся слишком больших затрат.
Проблема для команд разработчиков не в том, чтобы их сдерживали устаревшие или технические стеки, которые не подходят для работы команды. Чтобы создавать приложения высокого качества, разработка должна доставлять удовольствие команде.
Компании, в которых команды разработчиков создают приложения с использованием современных фреймворков JavaScript, таких как Angular, React или VueJs, столкнутся со следующими проблемами:
- Перенос приложений на другие платформы или даже их обновление занимает очень много времени, очень дорого и очень утомительно.
- Компоненты нельзя обменивать между командами, что приводит к необходимости изобретать колесо несколько раз, что приводит к потере времени, денег и энергии.
- Обеспечение общего внешнего вида между различными частями приложения, разработанного несколькими командами с разным техническим стеком, требует очень много времени, а значит, и пустой траты денег и энергии.
Как противостоять этим вызовам?
Привет, веб-компоненты, не зависящие от фреймворка!
Примечание. Если вы не знакомы с веб-компонентами, не зависящими от фреймворка, есть очень хорошее введение, которое вы можете прочитать здесь.
Библиотеки компонентов, не зависящих от платформы, позволят решить описанные выше проблемы. Идея библиотек компонентов, не зависящих от фреймворка, довольно проста, но довольно сложна в реализации. Команды разработчиков по-прежнему могут выбрать стек технологий, соответствующий их потребностям, и разработать свою часть приложения. Таким образом гарантируется автономия команд и повышается производительность. В то же время компания разрабатывает независимую от фреймворка библиотеку компонентов, компоненты которой взаимозаменяемы между командами разработчиков. Ключ к успеху - это взаимозаменяемость команд и независимость компонентов.
3 причины, по которым вам следует перейти на библиотеки компонентов, не зависящих от фреймворка
Вот почему вам следует перейти на библиотеки компонентов, не зависящих от фреймворка:
- Больше никакого устаревшего кода. Перенести или обновить стек очень легко, потому что все компоненты библиотеки не зависят от платформы. Следовательно, совместим со всеми технологиями.
- Больше не нужно изобретать квадратное колесо снова и снова. Компоненты совместимы с каждым стеком, поэтому нет необходимости создавать одинаковые с разными техническими стеками. Только представьте, сколько времени, денег и разочарований вы сэкономите!
- С помощью общих компонентов легко обеспечить единообразный внешний вид приложения, созданного несколькими командами с разными техническими стеками.
Об авторе
☞ Если вам понравился этот пост, вы можете купить мне кофе.
☞ Стефан в настоящее время предлагает CFP для #ReactiveConf. Встретиться и послушать, как он говорит: 🌟🌟🌟 это суть.
☞ Стефан читает каждый ответ на Medium или ответ в Twitter, поэтому не стесняйтесь сообщать ему, что вы думаете.
☞ Чтобы услышать от автора сообщения в будущем, ознакомьтесь с его сутью или подпишитесь на него в Twitter.
☞ Нажмите «♥ ︎», чтобы рассказать об этом произведении другим.
Подробнее откуда это взялось
Эта история публикуется в журнале Noteworthy, куда ежедневно приходят тысячи людей, чтобы узнать о людях и идеях, формирующих наши любимые продукты.
Следите за нашей публикацией, чтобы увидеть больше историй о продуктах и дизайне, представленных командой Journal.
