Для описания программного обеспечения используется много слов: фреймворк, прогрессивный, модульный, многоразовый, расширяемый, масштабируемый, простой, до бесконечности. Поработав и написав ряд веб- и мобильных проектов, мне было любопытно: какие слова составляют коллективный лексикон разработчиков и на что они были ответом?
Чтобы решить эту проблему, я написал некоторый код Python для очистки и анализа README из 2000 лучших репозиториев GitHub, получивших наибольшее количество звезд. Я ожидал, что будет много модных словечек, но обнаружил, что лучшие README написаны для своей аудитории, других разработчиков. Многие из наиболее часто используемых слов касаются установки, модификации и документации: как быстро и эффективно приступить к работе.
Задний план
TL;DR
- Гипотеза: библиотеки стали большими, поэтому разработчики создали альтернативы
- Файлы README – важный инструмент для обнаружения проекта.
- Разработчикам нужны фреймворки, которые просты в использовании и ремиксах.
jQuery
Возможно, тенденции в разработке программного обеспечения с открытым исходным кодом развиваются как великая гегелевская диалектика, состоящая из тезиса, антитезиса и синтеза. По мере того, как используемые нами фреймворки становились больше и монолитнее, естественной реакцией некоторых было упрощение и создание меньших, более модульных фреймворков. Возьмем пример jQuery:
С течением времени jQuery росла и в то же время становилась менее необходимой (хотя благодаря технологии сжатия фактические байты, отправляемые по сети, росли гораздо медленнее). Ответ?
- Каковы некоторые эмпирические технические причины не использовать jQuery?
- Вам действительно не нужен jQuery
- Вам может не понадобиться jQuery
- Почему новичкам не стоит изучать JavaScript с помощью jQuery
Некоторые разработчики считают, что jQuery защищает нас от великого демона несовместимости браузеров, хотя, по правде говоря, после IE8 с браузерами довольно легко справиться самостоятельно. Вам может не понадобиться jQuery.
jQuery был создан в 2006 году, и спустя 12 лет он все еще жив! Это, несомненно, основная библиотека javascript, и первые несколько лет она была не чем иным, как незаменимой. Но по мере принятия стандартов ECMA и усложнения веб-приложений это постепенно стало обузой.
Основные критические замечания заключались в том, что разработчики используют только небольшое подмножество функций, бесполезно тратя байты неиспользуемых функций, что абстрагированная совместимость больше не является проблемой для большинства проектов, и что предоставляемые им инструменты были ортогональны задачам, с которыми инженеры сталкиваются сегодня. Введите Реакт.
Реагировать
По мере усложнения веб-приложений возникла новая проблема. Из Самая глубокая причина, по которой существуют современные JavaScript-фреймворки:
Основная проблема, которую решают современные фреймворки JavaScript, — синхронизация пользовательского интерфейса с состоянием.
Спустя более десяти лет после запуска jQuery мы находимся в том же месте и решаем другую проблему. Будь то виртуальный DOM React и алгоритмы сравнения или двусторонняя привязка данных Vue.js, все фреймворки пытаются решить эту проблему синхронизации того, что вы видите, с данными.
Кажется, сегодня мы сталкиваемся с теми же проблемами. Фреймворки решают общие проблемы, что всегда влечет за собой компромисс между функциональностью и размером. Чем более общий фреймворк и чем больше функций он включает, тем больше он становится. Возьмем, к примеру, React:
Похоже на траекторию jQuery. Ответ?
- Как я вдвое сократил размер пакета React Javascript с помощью 3 строк кода
- Два быстрых способа уменьшить размер приложения React в продакшене
- Есть ли причина, по которой размер файла [React] взорвался?
Одним из главных преимуществ React было то, что он был намного меньше, чем Angular/Ember/Backbone и т. д., но я не уверен, что этот аргумент можно использовать дальше. – coltonv
Итак, мы здесь, пресловутые дебаты бушуют между размером и функциональностью. Только сегодня у нас есть еще одна проблема: парадокс выбора. С чего вообще начать при выборе JavaScript Framework?
Фрэнк Чимеро написал фантастическую статью Всё, что легко, снова сложно, в которой выразил разочарование ростом сложности при создании современных веб-сайтов и приложений. Его мнение разделяют многие.
просто npm ваш веб-пакет через grunt с vue babel или bower, чтобы отреагировать asdfjkl;lkdhgxdlciuhw
Это возвращает нас к словам.
Слова
Я ожидал увидеть такие слова, как облегченный и прогрессивный среди наиболее часто встречающихся, но вместо этого обнаружил вот что:
Как и большинство людей, разработчики ищут что-то легкое, простое и автоматическое. Частью успеха любого проекта с открытым исходным кодом является возможность обнаружения. Наиболее функциональным проектам по-прежнему необходимо решать проблемы своих пользователей, и им по-прежнему нужны участники для их поддержки и улучшения. Слова, извлеченные из GitHub README, хорошо сочетаются с советами, такими как Руководство для начинающих по написанию Kickass README. Любому большому проекту необходимо:
- Скриншоты. Большинство посетителей просматривают и уходят в течение нескольких секунд
- Демонстрации и примеры. Покажите посетителям реальный проект
- Документация. Расскажите посетителям, как легко установить и адаптировать
Такие слова, как автоматически, доступно, поддерживается, установлено и просто, рисуют картину. того, как лучшие проекты привлекают новых пользователей.
Дополнительные сведения о коде и процессе см. в разделе Слова с открытым исходным кодом — часть 1.
Код и данные доступны на GitHub: Tombarr/open-source-words