[Перевод - recovery mode ] Angular vs. React vs. Vue: Сравнение 2017

Понедельник, 18 Сентября 2017 г. 22:25 + в цитатник

Angular vs. React vs. Vue: Сравнение 2017

https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

Перевод
Recovery Mode

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

Итак, как же нам выбрать? Список плюсов и минусов никогда не повредит. Проделаем это в стиле моей предыдущей статьи, “9 шагов: выбор технологического стэка для вашего веб-приложения”.

Прежде чем начнем — SPA или нет?

Сперва вы должны принять четкое решение, нужно ли вам одностраничное веб-приложение(SPA), или вы предпочли бы многостраничный подход. Больше на эту тему в моем посте “Одностраничные веб-приложения(SPA) против Многостраничных веб-приложений(MPA)”(скоро выйдет, следите за обновлениями в Twitter).

Участники сегодняшнего состязания: Angular, React and Vue

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

Вопросы, которые мы сегодня рассмотрим:

Насколько зрелые эти фреймворки/библиотеки?
Будут ли эти фреймворки существовать еще какое-то время?
Насколько велики и полезны сообщества вокруг них?
Насколько легко найти разработчиков под каждый из этих фреймворков?
Каковы основные идеи этих фреймворков?
Насколько просто использовать эти фреймворки для небольших и крупных веб-приложений?
Какова кривая обучения для каждого из фреймворков?
Какую производительность вы ожидаете от этих фреймворков?
Где вы можете подробнее узнать, что у них под капотом?
Как начать разрабатывать с выбранным фреймворком?

На старт, внимание, марш!

Жизненный цикл и стратегические соображения

React vs. Angular vs. Vue

1.1 Немного истории

Angular — это JavaScript-фреймворк, основанный на TypeScript. Разработанный и поддерживаемый Google, он описывается как “Супергеройский JavaScript MVW фреймворк”. Angular(известный также как “Angular 2+”, “Angular 2” или “ng2”) — переписанный, по большей части несовместимый преемник AngularJS(известный как “Angular.js” или “AngularJS 1.x”). Хотя AngularJS(старый) был впервые выпущен в октябре 2010-го, он до сих пор получает багфиксы и т.д. Новый Angular(без JS) был представлен как версия №2 в сентябре 2016. Последний мажорный релиз — версия 4, так как версию 3 пропустили. Angular используется Google, Wix, weather.com, healthcare.gov и Forbes(в соответствии с madewithangular, stackshare и libscore.com).

React характеризуется как “JavaScript-библиотека для создания пользовательских интерфейсов”. Впервые выпущенный в марте 2013-го, React разработан и поддерживается Facebook-ом, который использует React-компоненты на нескольких страницах(однако, не являясь одностраничным веб-приложением). В соответствии с этой статьей Криса Кордла, React в Facebook применяется значительно шире, чем Angular в Google. React также используют в Airbnb, Uber, Netflix, Twitter, Pinterest, Reddit, Udemy, Wix, Paypal, Imgur, Feedly, Stripe, Tumblr, Walmart и других(в соотв. с Facebook, stackshare и libscore.com).

В данный момент Facebook работает над выпуском React Fiber. Это изменит React под капотом — в результате, рендеринг должен значительно ускориться — но обратная совместимость сохранится после изменений. В Facebook рассказывали об этих изменениях на их конференции для разработчиков в апреле 2017-го, также была опубликована неофициальная статья о новой архитектуре. Предположительно, React Fiber будет выпущен вместе с React 16.

Vue — один из самых быстроразвивающихся JS-фреймворков в 2016-м. Vue описывает себя как “Интуитивный, Быстрый и Интегрируемый MVVM для создания интерактивных интерфейсов”. Впервые он был выпущен в феврале 2014-го бывшим сотрудником Google Эваном Ю(кстати, Эван тогда написал интересный пост про маркетинговую деятельность и цифры в первую неделю после старта). Это был неплохой успех, особенно учитывая, что Vue привлекает столько внимания будучи театром одного актера, без поддержки крупной компании. На данный момент, у Эвана есть команда из дюжины основных разработчиков. В 2016 была выпущена вторая версия. Vue используют Alibaba, Baidu, Expedia, Nintendo, GitLab. Список более мелких проектов можно найти на madewithvuejs.com.

И Angular, и Vue доступны под лицензией MIT, в то время как React — под BSD3-license. Есть много обсуждений по поводу патентного файла. Джеймс Аид(бывший инженер Facebook) объясняет причины и историю, лежащую за этим файлом: Патент Facebook касается распространения их кода при сохранении возможности защитить себя от патентных исков. Файл патента обновлялся единожды и некоторые люди утверждают, что React можно использовать, если ваша компания не собирается подавать в суд на Facebook. Можете ознакомиться с обсуждением вокруг этого Github issue. Я не являюсь адвокатом, поэтому вы сами должны решить, создает ли лицензия React проблемы для вас или вашей компании. Есть еще много статей на эту тему: Дэннис Уолш пишет, почему вам не стоит бояться. Рауль Крипалани предостерегает от использования в стартапах, у него также есть обзор в формате “изложение мыслей”. Также существует недавнее оригинальное заявление от Facebook на эту тему: “Разъяснение лицензии React”.

1.2 Core development

Как было отмечено ранее, Angular и React поддерживаются и используются крупными компаниями. Facebook, Instagram и Whatsapp используют их на своих страницах. Google использует их во многих своих проектах: например, новый пользовательский интерфейс Adwords был реализован с помощью Angular и Dart. Опять же, Vue разрабатывается группой лиц, чья работа поддерживается через Patreon и другие средства спонсирования. Решайте сами, хорошо это или плохо. Маттиас Гёцке считает, что небольшая команда Vue — это плюс, потому что это ведет к более чистому коду / API, и меньшему оверинженерингу.

Посмотрим на статистику: на странице команды Angular перечислено 36 человек, у Vue — 16 человек, у React страницы команды нет. На GitHub-е у Angular больше 25 000 звезд и 463 контрибьютора, у React — больше 70 000 звезд и 1000 контрибьюторов, и у Vue почти 60 000 звезд и лишь 120 контрибьюторов. Можете также проверить страничку “Github Stars History for Angular, React and Vue”. Опять же, Vue, похоже, очень хорошо развивается. В соответствии с bestof.js, за последние три месяца Angular 2 получал в среднем 31 звезду в день, React — 74 звезды, Vue — 107 звезд.

A Github Stars History для Angular, React и Vue (Источник)

Апдейт: Спасибо Полу Хеншелю за то, что указал на npm trends. Они показывают количество скачиваний для данных npm-пакетов и даже полезнее, как чистый взгляд на звезды GitHub.

Количество скачиваний для заданных npm-пакетов в течение двух лет

1.3 Жизненный цикл на рынке

Angular, React и Vue сложно сравнить в Google Trends из-за их разнообразных имен и версий. Одним из способов получить приблизительные значения может быть поиск в категории “Internet & technologies”. Вот результат:

Ну, что ж. Vue до 2014 года не существовало — значит, тут что-то не так. La Vue по-французски — “вид”, “взгляд”, или “мнение”. Может быть, дело в этом. Сравнение “VueJS” с “Angular” или “React” несправедливо, так как у VueJS почти нет результатов, которые можно сравнить с остальными.

В таком случае, попробуем кое-что другое. Technology Radar от ThoughtWorks дает хорошее представление о том, как технологии эволюционируют в течение времени. Redux находится на стадии принятия(принятия в проектах!) и он был бесценен на ряде проектов ThoughtWorks. Vue.js на стадии испытаний(испытайте!). Его описывают, как легковесную и гибкую альтернативу Angular с более низкой кривой обучения. Angular 2 находится на стадии оценки — он успешно используется командами ThoughtWorks, но пока не имеет настоятельных рекомендаций.

В соответствии с последним опросом StackOverflow 2017, React любят 67% опрошенных разработчиков, а AngularJS — 52%. “Отсутствие интересу к продолжению разработки” регистрирует большие значения для AngularJS(48%) в сравнении с React(33%). Vue не входит в первую десятку ни в одном из случаев. Далее, есть опрос statejs.com, сравнивающий “front-end фреймворки”. Самые интересные факты: React и Angular обладают 100%-й известностью, Vue незнаком 23%-м опрошенных людей. Касательно “удовлетворенности”, React набрал 92% для варианта “использовал бы снова”, Vue — 89%, Angular 2 — только 65%.

Как насчет другого опроса об удовлетворенности пользователей? Эрик Элиотт запустил один в октябре 2016-го, чтобы оценить Angular 2 и React. Лишь 38% опрошенных людей использовали бы Angular 2 снова, в то время как 84% использовали бы снова React.

1.4 Долгосрочная поддержка и миграции

API React-а достаточно стабилен, как заявляет об этом Facebook в своих принципах проектирования. Существуют также скрипты, помогающие мигрировать с вашего текущего API на новый: попробуйте react-codemod. Миграции достаточно просты и здесь нет такой вещи(и необходимости в ней), как LTS версии. В этом посте на Reddit люди отмечают, что апгрейд на самом деле никогда не был проблемой. Команда React написала пост об их схеме версионирования. Когда они добавляют предупреждение об устаревании, они оставляют его для остальной части текущей релизной версии до того момента, пока поведение не будет изменено в следующей мажорной версии. Планов выпустить новую мажорную версию нет — v14 выпущена в октябре 2015-го, v15 опубликована в апреле 2016-го, а у v16 пока нет даты релиза. Обновление не должно стать проблемой, как недавно заметил один из основных разработчиков React.

Что касается Angular, есть пост о версионировании и релизах Angular начиная с релиза v2. Будет одно мажорное обновление каждые шесть месяцев и период устаревания(deprecation period), как минимум шесть месяцев(два мажорных релиза). Существуют экспериментальные API, помеченные в документации более коротким периодом устаревания. Официального анонса нет, но в соответствии с этой статьей, команда Angular анонсировала LTS версии начиная с Angular 4. Они будут поддерживаться как минимум год после следующего мажорного релиза. Это значит, что Angular 4 будет поддерживаться багфиксами и важными патчами как минимум до сентября 2018-го. В большинстве случаев, обновление со второй до четвертой версии Angular также просто, как обновление зависимостей Angular. Angular также предоставляет руководство с информацией о том, какие понадобятся изменения в дальнейшем.

Процесс обновления с Vue 1.x до 2.0 должен быть простым для небольшого приложения — команда разработчиков утверждает, что 90% API осталось без изменений. Имеется приятный инструмент для диагностики обновления и помощи во время миграции, работающий из консоли. Один из разработчиков отметил, что обновление с v1 до v2 до сих пор не приносит особого удовольствия на больших приложениях. К сожалению, roadmap-а для следующего мажорного релиза или информации о планах создания LTS версий нет.

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

1.5 Кадровые ресурсы и найм

Если у вас есть HTML-разработчики, которые не хотят углубляться в JavaScript, вам лучше выбрать Angular или Vue. React повлечет за собой увеличение количества JavaScript-а(позже мы поговорим об этом).

У вас есть дизайнеры, работающие в непосредственной близости с кодом? Пользователь “pier25” отмечает в своем Reddit-посте, что выбирать React имеет смысл, если вы работаете в Facebook, где каждый разработчик — супергерой. В реальном мире, вы не всегда найдете дизайнера, способного модифицировать JSX — по существу, работать с HTML-шаблонами будет намного проще.

Хорошая новость относительно Angular это то, что новый Angular 2-разработчик из другой компании сможет быстро ознакомиться со всеми необходимыми соглашениями. Каждый проект на React отличается в плане архитектурных решений и разработчикам нужно будет знакомиться с настройками конкретного проекта.

Angular также хорош, если у вас есть разработчики с ООП-бэкграундом или те, кто не любят JavaScript. Чтобы заострить на этом внимание, цитата Манеша Чанда:

“Я не JavaScript-девелопер. Мой бэкграунд — создание крупномасштабных корпоративных систем с использованием “настоящих” платформ для разработки ПО. Я начинал в 1997-м, разрабатывая приложения на C, C++, Pascal, Ada и Fortran. (...) Я могу точно сказать, что JavaScript для меня просто белиберда. Будучи MVP в Microsoft и экспертом, я хорошо понимаю TypeScript. Я также не рассматриваю Facebook, как компанию-разработчика ПО. Однако, Google и Microsoft уже крупнейшие инноваторы в этой сфере. Я чувствую себя более комфортно, работая с продуктом, у которого есть хорошая поддержка от Google или Microsoft. Также (...) с моим бэкграундом, я знаю, что у Microsoft даже большие планы для TypeScript”

Ну… Видимо, я должен упомянуть, что Манеш Чанд является региональным директором в Microsoft.

Сравнение React, Angular и Vue

2.1 Компоненты

Все обсуждаемые фреймворки основаны на компонентах. Компонент получает что-то на вход и после внутренних вычислений возвращает отрендеренный шаблон UI(область входа / выхода с сайта или элемент списка to-do) на выходе. Определенные компоненты должно быть легко переиспользовать на веб-странице или в других компонентах. Например, у вас мог бы быть компонент сетки(состоящий из шапки и нескольких компонентов для рядов) с разнообразными свойствами(колонки, информация о шапке, data rows, и т.д.) и возможностью переиспользования этого компонента с разными данными на другой странице. Вот всеобъемлющая статья о компонентах на тот случай, если вам захочется изучить их получше.

И React, и Vue превосходно подходят для работы с “тупыми” компонентами: небольшие функции, не имеющие состояния, которые получают что-то на вход и возвращают элементы на выходе.

2.2 TypeScript vs ES6 vs. ES5

React фокусируется на использовании JavaScript ES6. Vue использует JavaScript ES5 либо ES6.

Angular зависит от TypeScript. Это дает большую консистентность в примерах и в опенсорсных проектах(примеры React можно найти в ES5 или в ES6). Это также вводит такие понятия, как декораторы или статическая типизация. Статическая типизация полезна для инструментов для анализа кода, типа автоматического рефакторинга, перехода к определению и т.д. — они должны уменьшить количество багов в приложении, хотя консенсус по поводу их использования, определенно, не достигнут. Эрик Элиот не согласен с этим в своей статье “Шокирующий секрет статических типов”. Дэниэл С Вонг говорит, что использование статических типов не вредит и что хорошо иметь разработку через тестирование(TDD) и статическую типизацию одновременно.

Вам, вероятно, следует знать о том, что вы можете использовать Flow, чтобы включить проверку типов в React. Это инструмент для статической проверки типов, разработанный Facebook для JavaScript. Flow также можно интегрировать в VueJS.

Если вы пишете код на TypeScript, вы уже не пишете стандартный JavaScript. Несмотря на рост, у TypeScript до сих пор крошечное число пользователей, по сравнению со всем языком JavaScript. Один из рисков может заключаться в том, что вы будете двигаться в неверном направлении, поскольку TypeScript может — хотя и вряд ли — исчезнуть со временем. Помимо того, TypeScript создает приличный оверхед на проектах(на обучение) — можете больше почитать об этом в Сравнении Angular 2 и React от Эрика Элиотта.

Апдейт: Джеймс Рейвенскрофт написал к этой статье комментарий о том, что у TypeScript первоклассная поддержка JSX — компоненты можно легко проверить на соответствие типу. Так что, если вам нравится TypeScript и вы хотите использовать React, это не должно быть проблемой.

2.3 Шаблоны — JSX или HTML

React нарушает устоявшиеся best practices. Десятилетиями разработчики пытались разделить шаблоны и встроенную джаваскриптовую логику, но в JSX они опять перемешаны. Может быть, это звучит ужасно, но вам следует послушать речь Питера Ханта “React: Переосмысление best practices”(от октября 2013-го). Он указывает на то, что разделение шаблонов и логики — это просто разделение технологий, а не ответственности. Вы должны создавать компоненты вместо шаблонов. Компоненты переиспользуемы, интегрируемы и удобны для unit-тестирования.

JSX — это опциональный препроцессор с HTML-подобным синтаксисом, который затем компилируется в JavaScript. Отсюда некоторые странности — например, вам нужно использовать className вместо class, потому что последний является в JavaScript зарезервированным ключевым словом. JSX — большое преимущество для разработки, так как у вас все будет в одном и том же месте, а также быстрее будут работать автокомплит и проверки на стадии компиляции. Когда вы допускаете ошибку в JSX, React не компилирует код и выводит номер строки, в которой допущена ошибка. Angular 2 тихо падает в рантайме(возможно, этот аргумент некорректен, если вы пользуетесь AOT с Angular).

JSX подразумевает, что все в React = JavaScript — он используется и для JSX-шаблонов, и для логики. Кори Хаус указывает в своей статье от января 2016-го: “Angular 2 продолжает внедрять ‘JS’ в HTML. React внедряет ‘HTML’ в JS”. Это хорошо, потому что JavaScript мощнее, чем HTML.

Шаблоны в Angular представляют собой усовершенствованный HTML со специальным языком Angular(штуки, вроде ngIf или ngFor). В то время, как React требует знания JavaScript, Angular заставляет вас учить специфичный для Angular синтаксис.

Vue предлагает “однофайловые компоненты”. Это похоже на компромисс относительно разделения ответственности — шаблоны, скрипты и стили в одном файле, но в трех различных, упорядоченных секциях. Это значит, что вы получаете подсветку синтаксиса, поддержку CSS и возможность легко использовать препроцессоры типа Jade или SCSS. Я прочитал в других статьях, что JSX проще дебажить, потому что Vue не показывает синтаксические ошибки в HTML. Это не так, поскольку Vue конвертирует HTML в render-функции — поэтому ошибки показываются без проблем(Спасибо Винициусу Рейзу за комментарий и поправки!).

Примечание: Если вам нравится задумка с JSX и вам хочется использовать его в Vue, вы можете использовать babel-plugin-transform-vue-jsx.

2.4 Фреймворки против библиотек

Angular — больше фреймворк, чем библиотека, так как предоставляет убедительные предложения о том, как ваше приложение должно быть структурировано, а также имеет больше функционала из коробки. Angular — это “цельное решение” — включены “батарейки” и вам предоставляется возможность удобного старта. Вам не нужно проводить анализ библиотек, решать вопрос с роутингом и т.п. — вы можете просто начать работать.

React и Vue, с другой стороны, универсально гибки. Их библиотеки можно совмещать с любого рода пакетами(их достаточно много для React в npm, но у Vue пакетов меньше, так как он еще достаточно молод). Используя React, вы можете даже заменить саму библиотеку на ее API-совместимую альтернативу, такую как Inferno. С большей гибкостью, однако, появляется большая ответственность — для React не существует правил и и ограничительных рекомендаций. Каждый проект требует принятия решения относительно его архитектуры, и все может легко пойти не так, как планировалось.

С другой стороны, Angular поставляется с запутанным клубком систем для сборки, бойлерплейтов, линтеров и других пожирателей времени, с которыми придется иметь дело. Это верно и для React в случае использования стартер-китов или бойлерплейтов. Конечно, они очень полезны, React работает из коробки, и это, может быть для вас способ его изучить. Иногда разнообразие инструментов, необходимых для работы в JavaScript-окружении называют “усталостью от JavaScript”. Вот статья Эрика Клеммонса, который сказал следующее:

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

Vue кажется самым чистым и легким из трех фреймворков. У GitLab есть пост о принятии решения в пользу Vue.js(октябрь 2016-го):

Vue.js прекрасно поставляется отлично сбалансированным в плане того, что он может сделать для вас и того, что вам нужно делать самостоятельно. (...) Vue.js всегда находится в пределах досягаемости; прочная, но гибкая сетка готова помочь сохранить эффективность вашего программирования и свести связанные с DOM страдания к минимуму.

Им нравится простота и легкость использования — исходный код очень читабелен и документация или внешние библиотеки не нужны. Все достаточно просто. Vue.js “не делает далекоидущих предположений о большей части чего-либо”. Имеется также подкаст о решении GitLab.

Другой пост о переходе на Vue от Pixeljets. React “был большим шагом вперед для мира JS в плане state-awareness, и он показал множеству людей реальное функциональное программирование хорошим, практичным способом”. Одним из серьезных минусов React по сравнению с Vue является проблема разбиения компонентов на более мелкие компоненты из-за ограничений JSX. Вот цитата из статьи:

Для меня и моей команды важна читабельность кода, но также крайне важно то, чтобы написание кода приносило удовольствие. Нет ничего приятного в том, чтобы создать 6 компонентов, если вы разрабатываете простенький виджет-калькулятор. Во многих ситуациях это также плохо в плане поддержки, модификаций или визуальной переработки какого-то виджета, так как вам надо перемещаться по множеству файлов/функций и по-отдельности проверять каждый маленький кусочек HTML. Опять же, я не предлагаю писать монолиты — я предлагаю использовать в повседневной разработке компоненты вместо микрокомпонентов.

На Hacker news и Reddit есть интересные дискуссии об этом посте — в наличии аргументы от недовольных и дальнейших сторонников Vue.

2.5 Управление состоянием и связывание данных

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

Как это работает? Компоненты описывают UI в определенный момент времени. Когда данные изменяются, фреймворк перерисовывает UI-компонент целиком — отображаемые данные всегда актуальны. Мы может назвать эту идею “UI как функция”.

React часто работает в паре с Redux. Redux описывает себя в трех фундаментальных принципах:

Единственный источник правды
Состояние доступно только для чтения
Изменения делаются с помощью чистых функций

Другими словами: состояние приложения целиком находится в дереве объектов внутри единого хранилища. Это помогает отлаживать приложение и кое-какая функциональность становится проще для реализации. Состояние в read-only режиме и может быть изменено только через “экшены”, чтобы избежать состояния гонки(также полезно для отладки). “Редьюсеры” пишутся, чтобы указать, как “экшены” могут трансформировать состояние.

Большая часть туториалов и бойлерплейтов включают в себя Redux, но вы можете использовать React без него(или вам может быть вообще не нужен Redux в вашем проекте). Redux добавляет сложность и достаточно серьезные ограничения для вашего кода. Если вы изучаете React, вам стоит подумать об изучении чистого React перед тем, как вы перейдете к Redux. Вам определенно стоит прочесть “Вам может быть не нужен Redux” Дэна Абрамова.

Некоторые разработчики предлагают использовать Mobx вместо Redux. Можете думать о нем, как о “автоматическом Redux”, который упрощает использование и понимание с самого начала. Если хотите посмотреть, вам стоит начать с введения. Вы можете также почитать это полезное сравнение Redux и MobX от Робина. Тот же автор также предлагает информацию о переходе с Redux на MobX. Этот список полезен, если вы хотите проверить другие Flux-библиотеки. И, если вы пришли из мира MVC, вы захотите прочесть статью “Философия Redux (если вы уже знаете MVC)” Михаила Левковского.

Vue можно использовать с Redux, но он предлагает Vuex как свое собственное решение.

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

Оба подхода имеют плюсы и минусы. Вам нужно понять эти идеи и определить, влияют ли они на ваше решение о выборе фреймворка. И статья “Двустороннее связывание: Angular 2 и React”, и этот вопрос на StackOverflow предоставляют хорошие объяснения. Здесь вы можете найти интерактивные примеры кода(возрастом в 3 года, только для Angular 1 и React). Последнее, но тем не менее важное: Vue поддерживает и одностороннее, и двустороннее связывание(одностороннее по-умолчанию).

Если хотите почитать больше, имеется длинная статья о различных типах состояния и управлении состоянием в Angular-приложениях(от Виктора Савкина).

2.6 Другие концепции программирования

Angular включает в себя dependency injection, паттерн, в котором один объект(сервис) предоставляет зависимости другому объекту(клиенту). Это дает большую гибкость и более чистый код. Статья “Понять dependency injection” в деталях объясняет эту идею.

Паттерн Модель-Вид-Контроллер(MVC) делит проект на три части — модель, вид и контроллер. У Angular, как у MVC-фреймворка, имеется поддержка MVC из коробки. У React есть лишь V — что будет M и C нужно решить вам самим.

2.7 Гибкость и переход к микросервисам

Вы можете работать с React или Vue просто добавляя JavaScript-библиотеку к исходникам. Это невозможно с Angular, потому что он использует TypeScript.

Мы все больше движемся в сторону микросервисов и микроприложений. React и Vue предоставляют вам полный контроль над размером приложения, позволяя включить только те вещи, которые действительно нужны. Они дают больше гибкости при переходе от SPA к микросервисам, используя части бывшего приложения. Angular лучше подходит для SPA, так как для использования в микросервисах он, вероятно, слишком раздут.

Как отмечает Кори Хаус:

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

Некоторые люди также используют React для не-SPA вебсайтов(например, для сложных форм или мастеров). Даже Facebook использует React не для главной страницы, а, скорее, для определенных страниц и возможностей.

2.8 Размер и производительность

Обратная сторона функциональности: Angular довольно-таки раздут. Размер сжатого gzip-ом файла — 143кб, по сравнению с 23кб Vue и 43кб React.

И у React, и у Vue есть Virtual DOM, который должен увеличивать производительность. Если вам интересно, можете почитать об отличиях между Virtual DOM и DOM, а также о реальных преимуществах Virtual DOM в React. Один из авторов Virtual DOM также отвечает на вопросы, связанные с производительностью на StackOverflow.

Чтобы проверить производительность, я посмотрел великолепный js-framework-benchmark. Вы можете сами скачать и запустить его или посмотреть на интерактивную таблицу с результатами. Перед тем, как проверить результаты, вам нужно знать, что фреймворки обманывают бенчмарки — такие замеры производительности не должны быть основой принятия решений.

Производительность Angular, React и Vue (Источник)

Выделение памяти в Мб (Источник)

Чтобы подытожить: у Vue прекрасная производительность и лучшее распределение памяти, но все фреймворки действительно довольно рядом друг с другом, по сравнению с особенно медленными или особенно быстрыми фреймворками(типа Inferno). Еще раз: тесты производительности следует рассматривать как побочные данные, не для вынесения вердикта.

2.9 Тестирование

Facebook использует Jest, чтобы тестировать свой код на React. Здесь есть сравнение Jest и Mocha, и есть статья о том, как использовать Enzyme с Mocha. Enzyme — библиотека для тестирования, написанная на JavaScript, используемая Airbnb(в сочетании с Jest, Karma и другими тест-раннерами). Если вы хотите почитать побольше, имеются старые статьи про тестирование в React(здесь и здесь).

Далее, существует Jasmine, как тестовый фреймворк для Angular 2. В статье Эрика Элиотта говорится о том, что Jasmine “приводит к миллионам способов написания тестов и утверждений, нуждающихся в тщательном прочтении каждого из них, чтобы понять, что он делает”. Вывод также раздут и труден для чтения. Есть несколько информативных статей про интеграцию Angular 2 с Karma и Mocha. Также есть старое видео(от 2015-го) о тестовых стратегиях в Angular 2.

У Vue есть недостатки в тестировании, но Эван написал в своем превью от 2017-го, что команда планирует поработать над этим. Они рекомендуют использовать Karma. Vue работает с Jest, также есть тестовая утилита avoriaz.

2.10 Универсальные и нативные приложения

Универсальные приложения внедряются в веб, на десктопы, а также в мир нативных приложений.

И React, и Angular поддерживают нативную разработку. У Angular есть NativeScript(при поддержке Telerik) для нативных приложений и Ionic Framework для гибридных приложений. С React вы можете попробовать react-native-renderer, чтобы разрабатывать кроссплатформенные приложения для iOS или Android, или react-native для нативных приложений. Большое число приложений(включая Facebook; за подробностями на Showcase) сделаны с помощью react-native.

JavaScript-фреймворки рендерят страницы на клиенте. Это плохо для воспринимаемой производительности, пользовательского опыта в целом и SEO. Серверный рендеринг — это плюс. У всех трет фреймворков имеются библиотеки, чтобы помочь с этим. Для React это next.js, у Vue есть nuxt.js, и у Angular есть… Angular Universal.

2.11 Кривая обучения

У Angular, определенно, крутая кривая обучения. Он обладает всеобъемлющей документацией, но иногда это может вас расстраивать, потому что ряд вещей сложнее, чем кажется. Даже если вы глубоко понимаете JavaScript, вам нужно изучить, что происходит под капотом фреймворка. Вначале установка магическая, предлагает большое число встроенных пакетов и кода. Это можно рассматривать, как минус из-за большой, сразу существующей экосистемы, которую вам нужно со временем изучить. С другой стороны, это может и хорошо в определенных ситуациях, поскольку многие решения уже приняты. С React вам, скорее всего, придется принять множество внушительных решений относительно использования third-party библиотек. Существует 16 различных flux-пакетов для управления состоянием, которые можно выбрать для React.

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

Некоторые люди утверждают, что то, что они сделали на React было бы написано лучше с использованием Vue. Если вы — неопытный JavaScript разработчик — или в последние 10 лет работали в основном с jQuery — вам стоит подумать об использовании Vue. Сдвиг парадигмы более выражен при переходе на React. Vue выглядит больше как чистый JavaScript в тоже время привнося некоторые новые идеи: компоненты, событийная модель и однонаправленный data-flow. Также у него небольшой размер.

Тем временем, у Angular и React свой собственный подход к вещам. Они могут мешать вам, потому что вам нужно приспосабливаться под них, чтобы заставить их работать. Это может быть вредно из-за меньшей гибкости и крутой кривой обучения. Это также может быть и полезно, поскольку вас заставляют изучать правильные подходы в процессе изучения технологии. С Vue вы можете работать в стиле старомодного JavaScript. Это может быть проще вначале, но может стать проблемой в долгосрочной перспективе, если все сделать не верно.

Когда речь заходит об отладке, плюс React и Vue в меньшем количестве магии. Охота на баги проще, потому что есть лишь несколько мест, куда нужно смотреть, и у стектрейсов лучше видны отличия между собственным кодом и исходниками библиотеки. Работающие с React сообщают, что им никогда не требовалось читать исходный код библиотеки. Однако, отлаживая ваш код вашего приложения на Angular, вам часто нужно отлаживать внутренности Angular, чтобы понять лежащую в его основе модель. С другой стороны, сообщения об ошибках должны стать более чистыми и информативными начиная с Angular 4.

2.12 Под капотом Angular, React и Vue

Хотите проверить исходники самостоятельно? Хотите увидеть, как все складывается?

Возможно, вам стоит сначала проверить вот эти GitHub-репозитории: React(github.com/facebook/react), Angular(github.com/angular/angular) и Vue(github.com/vuejs/vue).

Как выглядит синтаксис? ValueCoders сравнивают синтаксис Angular, React и Vue.

Хорошо бы также увидеть все на продакшене — вместе с исходным кодом, на котором все основано. На TodoMVC есть список из десятков вариантов одного и того же Todo-приложения, написанного на различных JavaScript-фреймворках — можете сравнить решения на Angular, React и Vue. RealWorld разрабатывает реальное приложение(клон Medium) и у них есть готовые решения для Angular(4+) и React(с Redux). Для Vue работа в процессе.

Также есть некоторые реальные приложения, на которые вы можете посмотреть. Решения на базе React:

Do (приятное приложение для управления заметками, построенное с помощью React и Redux)
sound-redux (клиент для Soundcloud на базе React и Redux)
Brainfock (решение для управления проектами и командами на базе React)
react-hn и react-news (клоны Hacker news)
react-native-whatsapp-ui + туториал (клон Whatsapp на React Native)
phoenix-trello (клон Trello)
slack-clone + другой туториал (клоны Slack)

Приложения на Angular:

angular2-hn & hn-ng2 (клоны Hacker News + неплохой туториал о создании еще одного от Эшвина Сурешкумара)
Redux-and-angular-2 (клон Twitter)

А также решения на Vue:

vue-hackernews-2.0 и Loopa news (клоны Hacker News)
vue-soundcloud (демо от Soundcloud)

Заключение

Выберите фреймворк сейчас

И React, и Angular, и Vue достаточно круты, и никого из них нельзя поставить сильно выше остальных. Доверьтесь своему нутру. Эта последний кусочек развлекательного цинизма может помочь вам принять решение:

Грязный маленький секрет — “современная JavaScript-разработка” не имеет ничего общего с созданием веб-сайтов — это создание пакетов, которые могут использоваться людьми, создающими библиотеки, которые могут использоваться людьми, создающими фреймворки, которым люди, пишущие туториалы и ведущие курсы могут обучать. Не уверен, что кто-то действительно что-то создает для настоящих пользователей.

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

Что я должен выбрать?

Если вы работаете в Google: Angular
Если вы любите TypeScript: Angular(или React)
Если вам нужно руководство, структура и рука помощи: Angular
Если вы работаете в Facebook: React
Если вам нравится гибкость: React
Если вы любите большие экосистемы: React
Если вам нравится выбирать из десятков пакетов: React
Если вы любиле JS и подход “все-есть-JavaScript”: React
Если вам нравится действительно чистый код: Vue
Если вы хотите простейшая кривую обучения: Vue
Если вы хотите самый легковесный фреймворк: Vue
Если вам хочется разделения ответственности в пределах одного файла: Vue
Если вы работаете один или в небольшой команде: Vue(или React)
Если ваше приложение имеет тенденцию разрастаться: Angular(или React)
Если вы хотите иметь большой пул девелоперов: Angular или React
Если вы работаете с дизайнерами и вам нужны чистые HTML-файлы: Angular или Vue
Если вам нравится Vue, но пугает ограниченная экосистема: React
Если вы не можете решить, изучите сначала React, затем Vue, затем Angular

Итак, вы приняли решение?

Дааа, вы его приняли!

Отлично! Читайте о том, как начать разрабатывать с Angular, React или Vue (скоро, подписывайтесь на меня в Twitter для обновлений).

Дополнительные ресурсы

React JS, Angular & Vue JS — Quickstart & Comparison (восьмичасовое введение и сравнение трех фреймворков)
Angular vs. React (vs. Vue) — the DEAL breaker (короткое, но превосходное сравнение от Доминика Т)
Angular 2 vs. React — the ultimate dance off (неплохое сравнение от Эрика Элиотта)
React vs. Angular vs. Ember vs. Vue.js (сравнение трех фреймворков в форме заметок от Гекана Сари)
React vs. Angular (понятное сравнение двух фреймворков)
Can Vue fight for the Throne with React? (приятное сравнение с большим количеством примеров кода)
10 reasons, why I moved from Angular to React (еще одно неплохое сравнение от Робина Вируча)
All JavaScript frameworks are terrible (большая заметка обо всех основных фреймворках от Мэтта Берджесса)

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338068/

Метки: author Synoptic reactjs javascript angularjs framework react.js angular vue comparison

Комментарии (0)

Постъядерный караван в 35 килобайт

Понедельник, 18 Сентября 2017 г. 20:15 + в цитатник

Zoolander сегодня в 20:15 Разработка

Постъядерный караван в 35 килобайт

35 килобайт минифицированного кода на обычном JavaScript, семь городов, пустоши, радиоактивные гекконы, съедобные кактусы, встречные караваны и бандиты. Что это? Это небольшая игра, которая запускается в браузере. Ее принципы довольно просты для повторения и в самой примитивной версии ее можно воссоздать, наверное, на любом устройстве, если там есть устройство вывода и генератор случайных чисел. Но сегодня я хочу рассказать, как я реализовал ее для современных браузеров.

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

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

Возможности игры

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

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

Функционал можно легко расширить, харизму и другие настоящие ролевые факторы добавить самим. Даже если вы не хотите программировать — можно просто открыть файлы с набором событий в Notepad и добавить новые события, изменить баланс или даже полностью переписать мир и лор, превратив путешествие по постъядерной пустыне в приключения караванщика Лютика в стране эльфов. Или в странствия космического корабля между разными звездными системами (правда, придется выбросить съедобные кактусы, попадающиеся по дороге).

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

Основная идея и логика программы

Базовая идея игры очень проста — мы запускаем бесконечный цикл, внутри которого выполняется четыре базовых операции:

Движение к заданной точке
Отсчет дней
Потребление еды
Проверка на вероятность для события, которое нас ждет в пустоши

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

Как это происходит? Очень просто — каждое событие просто меняет числовые параметры каравана или мира, а затем сообщает об этом в лог. И вот тут возникает магия — параметры могут быть одними и теми же, но сообщать можно о совершенно разных причинах. Минус несколько единиц еды? Это могут быть нападения крыс, выпадение радиоактивных осадков или голодных бродяг. Плюс несколько единиц еды? Значит, ваши люди нашли съедобный кактус, раскопали в придорожных руинах довоенные консервы или нашли на дороге замечательные кожаные сапоги с мягкой подошвой.

Первая версия, с которой я начал экспериментировать, выглядела чистой иллюстрацией описанного алгоритма:

Я сделал этот прототип как ремейк игры про орегонский караван из этого туториала.

Одномерный прототип — караван для js13kGames

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

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

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

Список изменений

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

Движок каравана и архитектура

Игра, как уже было сказано, сделана на чистом JavaScript без использования сторонних библиотек (вы можете сами добавить их, если сочтете нужным). Для отображения карты мира и интерфейса используется обычный HTML и CSS. Чтобы изменять их, используются базовые операции с DOM и классическая операция document.getElementById

Пример отображения количества игроков в караване

this.view = {}; // объект для хранения элементов DOM
this.view.crew = document.getElementById('game-stat-crew'); // находим элемент при запуске игры
// ...
this.view.crew.innerHTML = world.crew; //  записываем число людей в караване как обычный html

WorldState — модель мира

Мир в игре — это класс WorldState. Он хранит в себе все важные параметры и не содержит никакой логики. Логику мы привяжем потом, за счет плагинов.

function WorldState(stats) {
    this.day = 0;           // текущий день, с десятичными долям
    this.crew = stats.crew; // количество людей
    this.oxen = stats.oxen; // количество быков
    this.food = stats.food; // запасы еды
    this.firepower = stats.firepower; // единиц оружия
    this.cargo = stats.cargo;   // товаров для торговли
    this.money = stats.money;   //деньги

    // лог событий, содержит день, описание и характеристику
    //  { day: 1, message: "Хорошо покушали", goodness: Goodness.positive}
    this.log = [];

    // координаты каравана, пункта отправления и назначения
    this.caravan = { x: 0, y: 0};
    this.from = {x: 0, y: 0};
    this.to = {x: 0, y: 0};

    this.distance = 0; // сколько всего пройдено

    this.gameover = false;  // gameover
    this.stop = false;    // маркер для обозначения того, что караван стоит
    this.uiLock = false; // маркер для блокировки интерфейса
}

Game — создание мира и игровой цикл

Игровой цикл запускается и управляется объектом Game. Этот же объект создает мир. Обратите внимание на поле plugins — по умолчанию это пустой массив. Game ничего не знает о плагинах, кроме двух вещей — у них должна быть функция инициализации init(world) и функция обновления update.

Game = {
    plugins: [],  // генераторы событий, 
};

Game.init = function () {
    // создаем мир по стартовому состоянию которое хранится в отдельном файле
    // в объекте StartWorldState в директории data
    this.world = new WorldState(StartWorldState);

    var i;
    for (i = 0; i < this.plugins.length; i++) {
        this.plugins[i].init(this.world);
    }
};

// добавление плагинов
Game.addPlugin = function (plugin) {
    this.plugins.push(plugin);
};

// игровой цикл
Game.update = function () {
    if (this.world.gameover) return; // никаких действий
    var i;
    for (i = 0; i < this.plugins.length; i++) {
        this.plugins[i].update();
    }
};

Game.resume = function () {
    this.interval = setInterval(this.update.bind(this), GameConstants.STEP_IN_MS);
};

Game.stop = function () {
    clearInterval(this.interval);
};

Game.restart = function () {
    this.init();
    this.resume();
};

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

Ешь, живи, двигайся — CorePlugin

Самые базовые действия каравана — перемещение, отсчет времени и потребление пищи — реализованы в объекте CorePlugin:

исходный код CorePlugin

CorePlugin = {};

CorePlugin.init = function (world) {
    this.world = world; // запоминаем world
    this.time = 0; // общее время с начала игры, в миллисекундах
    this.dayDelta = GameConstants.STEP_IN_MS / GameConstants.DAY_IN_MS; // сколько дней в одном шаге игру
    this.lastDay = -1;  // отслеживаем наступление нового дня
    this.speedDelta = Caravan.FULL_SPEED - Caravan.SLOW_SPEED; // разница между полной и минимальной скоростью
};

CorePlugin.update = function () {
    if (this.world.stop) return; // если стоим - никаких изменений
    this.time += GameConstants.STEP_IN_MS; // увеличение времени
    this.world.day = Math.ceil(this.time / GameConstants.DAY_IN_MS); // текущий день, целый

    // Движение каравана в зависимости от того, сколько дней прошло
    this.updateDistance(this.dayDelta, this.world);

    // события связанные с наступлением нового дня
    if (this.lastDay < this.world.day) {
        this.consumeFood(this.world);
        this.lastDay = this.world.day;
    }
};

// еда выдается один раз в день
CorePlugin.consumeFood = function (world) {
    world.food -= world.crew * Caravan.FOOD_PER_PERSON;
    if (world.food < 0) {
        world.food = 0;
    }
};

// обновить пройденный путь в зависимости от потраченного времени в днях
CorePlugin.updateDistance = function (dayDelta, world) {
    var maxWeight = getCaravanMaxWeight(world);
    var weight = getCaravanWeight(world);

    // при перевесе - Caravan.SLOW_SPEED
    // при 0 весе - Caravan.FULL_SPEED
    var speed = Caravan.SLOW_SPEED + (this.speedDelta) * Math.max(0, 1 - weight/maxWeight);

    // расстояние, которое может пройти караван при такой скорости
    var distanceDelta = speed * dayDelta;

    // вычисляем расстояние до цели
    var dx = world.to.x - world.caravan.x;
    var dy = world.to.y - world.caravan.y;

    // если мы находимся около цели - останавливаемся
    if(areNearPoints(world.caravan, world.to, Caravan.TOUCH_DISTANCE)){
        world.stop = true;
        return;
    }

    // до цели еще далеко - рассчитываем угол перемещения
    // и получаем смещение по координатам
    var angle = Math.atan2(dy, dx);
    world.caravan.x += Math.cos(angle) * distanceDelta;
    world.caravan.y += Math.sin(angle) * distanceDelta;
    world.distance += distanceDelta;
};

// регистрируем плагин в игре
Game.addPlugin(CorePlugin);

Тут все элементарно. Сначала при запуске игры у нас вызывается init, который позволит сохранить ссылку на модель мира. Затем в игровом цикле у нас будет вызываться update, который будет менять мир к лучшему, как любят говорить персонажи из сериала «Силиконовая долина». Шутка — меняться мир будет во все стороны.

Наш базовый плагин отсчитывает время в миллисекундах, переводит их в дни, а затем обновляет дистанцию и запасы еды. В принципе, объект плагина просто должен содержать функции init(world) и update(), а делать он может что угодно. Можно даже просто вызывать какую-нибудь другую игру на HTML5 или создавать диалоговое окно.

Чтобы подключить плагин, надо добавить его код между определением объекта Game и первым вызовом Game.restart(). Примерно так, как это сделано сейчас в index.html:

Итак, как сделать игру про караван

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

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

Существующие плагины можно отключать (убирая их исходный код из index.html или закомментировав строку с Game.addPlugin(SomePlugin) в конце их кода). Они ничего не знают друг о друге и просто меняют модель мира или интерфейс игры.

Ну и последний вариант, для писателей — просто открывать файлы в директории data и редактировать описания событий и константы. Хотя это те же JavaScript-исходники, они довольны просты для изменений. Особенно тексты. Чтобы доказать это, я вкратце расскажу, как устроены другие плагины в текущей версии.

Случайные события

Все примитивные случайные события лежат в файле data/RandomEvents.js в переменной RandomEvents в таком формате:

var RandomEvents = [
    {
        goodness: Goodness.negative,
        stat: 'crew',
        value: -4,
        text: 'На караван напал смертокогть! Людей: -$1'
    },
    {
        goodness: Goodness.negative,
        stat: 'food',
        value: -10,
        text: 'Кротокрысы на привале сожрали часть еды. Пропало пищи: -$1'
    },
  {
        goodness: Goodness.positive,
        stat: 'money',
        value: 15,
        text: 'У дороги найден мертвый путешественник. На теле найдены монеты. Денег: +$1'
    },
    {
        goodness: Goodness.positive,
        stat: 'crew',
        value: 2,
        text: 'Вы встретили одиноких путников, которые с радостью хотят присоединиться к вам. Людей: +$1'
    },

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

Первое поле — goodness- означает позитивную, негативную и нейтральную окраску сообщения в логе. Второе поле — stat — содержит название параметра WorldState, который должен меняться. Value — это среднее значение для изменения этого параметра. Последнее поле — должно содержать любой произвольный текст, описывающий произошедшее. Вместо символом $1 в текст будет подставлено реальное изменение параметра, которое выпадет в игре.

Случайные события проверяются на выпадение в объекте RandomEventPlugin и радуют взгляд игрока в логе:

Последнее примечание: в RandomEvents.js вы найдете переменную с константой вероятности выпадения случайного события. Она задается как среднее число событий на один игровой день каравана. Когда я экспериментировал с разными значениями, то обнаружил, что слишком много случайных событий, на которые нельзя никак повлиять, начинают дико раздражать. Отсутствие интерактива — это главный минус этих простых событий. Вот почему я почесал голову и решил сделать универсальный модуль диалогов, который можно вызывать из других плагинов.

Как написать или отредактировать диалог

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

var DeathDialogs = {
    "start": {
        icon: "images/pic_death.jpg", // ссылка на url картинки
        title: "Погибший в пустоши", // заголовок диалога
        desc: "",                                // статический текст диалога
        desc_action: function (world, rule) { // функция для создания вычисляемого текста диалога
            var desc = " Причина смерти: "+rule.text+". Вы сумели пройти "+Math.floor(world.distance) + " миль и накопить "+Math.floor(world.money) + " денег";
            desc += "Может быть, следующим караванщикам повезет больше?"
            return desc;
        },
        choices:[  // массив выборов
            {
                text: 'Начать новую игру', // текст на кнопке
                action: function () { return "stop"; }  // функция, возвращающая тег следующего диалога
            }
        ]
    },
};

В диалогах смерти только один вариант, описанный как поле «start». Но таких вариантов может быть бесконечно много. К примеру, в диалогах бандитов я реализовал 12 развилок. Как происходит переход между ними? Наш универсальный объект DialogWindow при вызове функции show сохраняет у себя список переданных диалогов и показывает тот, который определен в поле «start».

При отображении очередного диалога его массив choices отображается как набор кнопок, в атрибуты которых записывается номер выбора. А все функции action из choices записываются во внутренний массив dialogActions. При клике мышкой на кнопке выбора универсальный обработчик определяет номер функции в dialogActions и вызывает ее, попутно передавая два аргумента, которые мы решили использовать в этом диалоге. Таким образом, в диалогах с бандитами функция action в конкретном choice может принимать состояние мира (world) и описание текущих бандитов (bandits). А в диалогах к другим плагинам — другие параметры. Да можно и вообще без них, особенно, если смысл выбора — просто закончить диалог, как при геймувере.

Чтобы диалог закончился и игрок вернулся к карте мира, надо, чтобы функция action в объекте choice возвращала один из зарезервированных тегов «finish»,«exit»,«stop». Вообще смысл этой функции в том, чтобы возвращать имя следующей развилки. Но до этого заветного return-a можно и порой нужно вставить любую логику, любые вычисления, которые позволят выбрать следующую развилку — «run», «fight» или, быть может, даже «love».

Как вызвать диалог из плагина

В любой момент времени в update любого работающего плагина можно вызвать диалог следующим образом:

    // ... где-то в недрах update у объекта-плагина
    // останавливаем караван, аналог паузы
    world.stop = true; 
   // просим показать диалог с набором развилок из DeathDialogs
   // в развилки будут передаваться аргументы world и rule
    DialogWindow.show(DeathDialogs, world, rule, this);

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

DeathCheck.onDialogClose = function () {
    Game.restart();
};

Краткое описание существующих плагинов

В текущей версии игры используются следующие плагины:

Map2DPlugin — перемещение каравана по карте. Поиск городов, которые задаются в index.html как обычные div с параметрами top и left. Здесь же определяется прибытие в город и происходит автоматическая торговля.

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

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

DropPlugin — плагин перегруза. В прототипе из туториала про орегонский караван игра сама автоматически сбрасывала вещи — сначала оружие, а потом еду. Это было не очень комфортно и вызывало недоумение — как так-то? Ведь с оружием можно добыть еду, а «жареным мясом нельзя убить врага» (с) один известный стрим по Fallout 4. Так что я решил сделать диалог, в котором ты просто выбираешь, от чего избавиться.

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

WorldViewPlugin — интерфейсный плагин. Он просто обновляет интерфейс, показывая текущие параметры мира. Возможно, эта идея покажется кому-то странной — самостоятельный объект интерфейса, который отслеживает в цикле обновления изменения переменных. Но зато благодаря этой странной идее мы избавились от многочисленных updateUi и получили независимость между блоками разной логики.

Небольшие советы по текущей игре и балансу

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

Второй жизненно важный параметр — количество людей в караване. Они должны быть. Если всех людей выбивают — игра заканчивается.

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

Ссылки и дистрибутивы

Я использовал графику с лицензией Creative Common 0 с ресурсов pixabay.org и opengameart.org, так что и графика, и код распространяется на этих условиях — свободное копирование и использование, без каких-либо обязательств.

Исходный код можно взять с GitHub или скачать zip-архивом отсюда. Первый вариант предпочтительнее, так как чаще обновляется.

Для тестирования даже на локальном компьютере достаточно открыть index.html в браузере — там не используются функции, которым обязательно требуется сервер.

Живой билд игры можно потестить здесь. Верстка рассчитана на обычные мониторы, не на мобильные экраны.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/336724/

Метки: author Zoolander разработка игр javascript html html5 текстовые игры fallout игровая механика игростроение

Комментарии (0)

Постъядерный караван в 35 килобайт

Понедельник, 18 Сентября 2017 г. 20:15 + в цитатник

Zoolander сегодня в 20:15 Разработка

Постъядерный караван в 35 килобайт

35 килобайт минифицированного кода на обычном JavaScript, семь городов, пустоши, радиоактивные гекконы, съедобные кактусы, встречные караваны и бандиты. Что это? Это небольшая игра, которая запускается в браузере. Ее принципы довольно просты для повторения и в самой примитивной версии ее можно воссоздать, наверное, на любом устройстве, если там есть устройство вывода и генератор случайных чисел. Но сегодня я хочу рассказать, как я реализовал ее для современных браузеров.

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

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

Возможности игры

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

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

Функционал можно легко расширить, харизму и другие настоящие ролевые факторы добавить самим. Даже если вы не хотите программировать — можно просто открыть файлы с набором событий в Notepad и добавить новые события, изменить баланс или даже полностью переписать мир и лор, превратив путешествие по постъядерной пустыне в приключения караванщика Лютика в стране эльфов. Или в странствия космического корабля между разными звездными системами (правда, придется выбросить съедобные кактусы, попадающиеся по дороге).

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

Основная идея и логика программы

Базовая идея игры очень проста — мы запускаем бесконечный цикл, внутри которого выполняется четыре базовых операции:

Движение к заданной точке
Отсчет дней
Потребление еды
Проверка на вероятность для события, которое нас ждет в пустоши

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

Как это происходит? Очень просто — каждое событие просто меняет числовые параметры каравана или мира, а затем сообщает об этом в лог. И вот тут возникает магия — параметры могут быть одними и теми же, но сообщать можно о совершенно разных причинах. Минус несколько единиц еды? Это могут быть нападения крыс, выпадение радиоактивных осадков или голодных бродяг. Плюс несколько единиц еды? Значит, ваши люди нашли съедобный кактус, раскопали в придорожных руинах довоенные консервы или нашли на дороге замечательные кожаные сапоги с мягкой подошвой.

Первая версия, с которой я начал экспериментировать, выглядела чистой иллюстрацией описанного алгоритма:

Я сделал этот прототип как ремейк игры про орегонский караван из этого туториала.

Одномерный прототип — караван для js13kGames

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

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

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

Список изменений

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

Движок каравана и архитектура

Игра, как уже было сказано, сделана на чистом JavaScript без использования сторонних библиотек (вы можете сами добавить их, если сочтете нужным). Для отображения карты мира и интерфейса используется обычный HTML и CSS. Чтобы изменять их, используются базовые операции с DOM и классическая операция document.getElementById

Пример отображения количества игроков в караване

this.view = {}; // объект для хранения элементов DOM
this.view.crew = document.getElementById('game-stat-crew'); // находим элемент при запуске игры
// ...
this.view.crew.innerHTML = world.crew; //  записываем число людей в караване как обычный html

WorldState — модель мира

Мир в игре — это класс WorldState. Он хранит в себе все важные параметры и не содержит никакой логики. Логику мы привяжем потом, за счет плагинов.

function WorldState(stats) {
    this.day = 0;           // текущий день, с десятичными долям
    this.crew = stats.crew; // количество людей
    this.oxen = stats.oxen; // количество быков
    this.food = stats.food; // запасы еды
    this.firepower = stats.firepower; // единиц оружия
    this.cargo = stats.cargo;   // товаров для торговли
    this.money = stats.money;   //деньги

    // лог событий, содержит день, описание и характеристику
    //  { day: 1, message: "Хорошо покушали", goodness: Goodness.positive}
    this.log = [];

    // координаты каравана, пункта отправления и назначения
    this.caravan = { x: 0, y: 0};
    this.from = {x: 0, y: 0};
    this.to = {x: 0, y: 0};

    this.distance = 0; // сколько всего пройдено

    this.gameover = false;  // gameover
    this.stop = false;    // маркер для обозначения того, что караван стоит
    this.uiLock = false; // маркер для блокировки интерфейса
}

Game — создание мира и игровой цикл

Игровой цикл запускается и управляется объектом Game. Этот же объект создает мир. Обратите внимание на поле plugins — по умолчанию это пустой массив. Game ничего не знает о плагинах, кроме двух вещей — у них должна быть функция инициализации init(world) и функция обновления update.

Game = {
    plugins: [],  // генераторы событий, 
};

Game.init = function () {
    // создаем мир по стартовому состоянию которое хранится в отдельном файле
    // в объекте StartWorldState в директории data
    this.world = new WorldState(StartWorldState);

    var i;
    for (i = 0; i < this.plugins.length; i++) {
        this.plugins[i].init(this.world);
    }
};

// добавление плагинов
Game.addPlugin = function (plugin) {
    this.plugins.push(plugin);
};

// игровой цикл
Game.update = function () {
    if (this.world.gameover) return; // никаких действий
    var i;
    for (i = 0; i < this.plugins.length; i++) {
        this.plugins[i].update();
    }
};

Game.resume = function () {
    this.interval = setInterval(this.update.bind(this), GameConstants.STEP_IN_MS);
};

Game.stop = function () {
    clearInterval(this.interval);
};

Game.restart = function () {
    this.init();
    this.resume();
};

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

Ешь, живи, двигайся — CorePlugin

Самые базовые действия каравана — перемещение, отсчет времени и потребление пищи — реализованы в объекте CorePlugin:

исходный код CorePlugin

CorePlugin = {};

CorePlugin.init = function (world) {
    this.world = world; // запоминаем world
    this.time = 0; // общее время с начала игры, в миллисекундах
    this.dayDelta = GameConstants.STEP_IN_MS / GameConstants.DAY_IN_MS; // сколько дней в одном шаге игру
    this.lastDay = -1;  // отслеживаем наступление нового дня
    this.speedDelta = Caravan.FULL_SPEED - Caravan.SLOW_SPEED; // разница между полной и минимальной скоростью
};

CorePlugin.update = function () {
    if (this.world.stop) return; // если стоим - никаких изменений
    this.time += GameConstants.STEP_IN_MS; // увеличение времени
    this.world.day = Math.ceil(this.time / GameConstants.DAY_IN_MS); // текущий день, целый

    // Движение каравана в зависимости от того, сколько дней прошло
    this.updateDistance(this.dayDelta, this.world);

    // события связанные с наступлением нового дня
    if (this.lastDay < this.world.day) {
        this.consumeFood(this.world);
        this.lastDay = this.world.day;
    }
};

// еда выдается один раз в день
CorePlugin.consumeFood = function (world) {
    world.food -= world.crew * Caravan.FOOD_PER_PERSON;
    if (world.food < 0) {
        world.food = 0;
    }
};

// обновить пройденный путь в зависимости от потраченного времени в днях
CorePlugin.updateDistance = function (dayDelta, world) {
    var maxWeight = getCaravanMaxWeight(world);
    var weight = getCaravanWeight(world);

    // при перевесе - Caravan.SLOW_SPEED
    // при 0 весе - Caravan.FULL_SPEED
    var speed = Caravan.SLOW_SPEED + (this.speedDelta) * Math.max(0, 1 - weight/maxWeight);

    // расстояние, которое может пройти караван при такой скорости
    var distanceDelta = speed * dayDelta;

    // вычисляем расстояние до цели
    var dx = world.to.x - world.caravan.x;
    var dy = world.to.y - world.caravan.y;

    // если мы находимся около цели - останавливаемся
    if(areNearPoints(world.caravan, world.to, Caravan.TOUCH_DISTANCE)){
        world.stop = true;
        return;
    }

    // до цели еще далеко - рассчитываем угол перемещения
    // и получаем смещение по координатам
    var angle = Math.atan2(dy, dx);
    world.caravan.x += Math.cos(angle) * distanceDelta;
    world.caravan.y += Math.sin(angle) * distanceDelta;
    world.distance += distanceDelta;
};

// регистрируем плагин в игре
Game.addPlugin(CorePlugin);

Тут все элементарно. Сначала при запуске игры у нас вызывается init, который позволит сохранить ссылку на модель мира. Затем в игровом цикле у нас будет вызываться update, который будет менять мир к лучшему, как любят говорить персонажи из сериала «Силиконовая долина». Шутка — меняться мир будет во все стороны.

Наш базовый плагин отсчитывает время в миллисекундах, переводит их в дни, а затем обновляет дистанцию и запасы еды. В принципе, объект плагина просто должен содержать функции init(world) и update(), а делать он может что угодно. Можно даже просто вызывать какую-нибудь другую игру на HTML5 или создавать диалоговое окно.

Чтобы подключить плагин, надо добавить его код между определением объекта Game и первым вызовом Game.restart(). Примерно так, как это сделано сейчас в index.html:

Итак, как сделать игру про караван

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

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

Существующие плагины можно отключать (убирая их исходный код из index.html или закомментировав строку с Game.addPlugin(SomePlugin) в конце их кода). Они ничего не знают друг о друге и просто меняют модель мира или интерфейс игры.

Ну и последний вариант, для писателей — просто открывать файлы в директории data и редактировать описания событий и константы. Хотя это те же JavaScript-исходники, они довольны просты для изменений. Особенно тексты. Чтобы доказать это, я вкратце расскажу, как устроены другие плагины в текущей версии.

Случайные события

Все примитивные случайные события лежат в файле data/RandomEvents.js в переменной RandomEvents в таком формате:

var RandomEvents = [
    {
        goodness: Goodness.negative,
        stat: 'crew',
        value: -4,
        text: 'На караван напал смертокогть! Людей: -$1'
    },
    {
        goodness: Goodness.negative,
        stat: 'food',
        value: -10,
        text: 'Кротокрысы на привале сожрали часть еды. Пропало пищи: -$1'
    },
  {
        goodness: Goodness.positive,
        stat: 'money',
        value: 15,
        text: 'У дороги найден мертвый путешественник. На теле найдены монеты. Денег: +$1'
    },
    {
        goodness: Goodness.positive,
        stat: 'crew',
        value: 2,
        text: 'Вы встретили одиноких путников, которые с радостью хотят присоединиться к вам. Людей: +$1'
    },

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

Первое поле — goodness- означает позитивную, негативную и нейтральную окраску сообщения в логе. Второе поле — stat — содержит название параметра WorldState, который должен меняться. Value — это среднее значение для изменения этого параметра. Последнее поле — должно содержать любой произвольный текст, описывающий произошедшее. Вместо символом $1 в текст будет подставлено реальное изменение параметра, которое выпадет в игре.

Случайные события проверяются на выпадение в объекте RandomEventPlugin и радуют взгляд игрока в логе:

Последнее примечание: в RandomEvents.js вы найдете переменную с константой вероятности выпадения случайного события. Она задается как среднее число событий на один игровой день каравана. Когда я экспериментировал с разными значениями, то обнаружил, что слишком много случайных событий, на которые нельзя никак повлиять, начинают дико раздражать. Отсутствие интерактива — это главный минус этих простых событий. Вот почему я почесал голову и решил сделать универсальный модуль диалогов, который можно вызывать из других плагинов.

Как написать или отредактировать диалог

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

var DeathDialogs = {
    "start": {
        icon: "images/pic_death.jpg", // ссылка на url картинки
        title: "Погибший в пустоши", // заголовок диалога
        desc: "",                                // статический текст диалога
        desc_action: function (world, rule) { // функция для создания вычисляемого текста диалога
            var desc = " Причина смерти: "+rule.text+". Вы сумели пройти "+Math.floor(world.distance) + " миль и накопить "+Math.floor(world.money) + " денег";
            desc += "Может быть, следующим караванщикам повезет больше?"
            return desc;
        },
        choices:[  // массив выборов
            {
                text: 'Начать новую игру', // текст на кнопке
                action: function () { return "stop"; }  // функция, возвращающая тег следующего диалога
            }
        ]
    },
};

В диалогах смерти только один вариант, описанный как поле «start». Но таких вариантов может быть бесконечно много. К примеру, в диалогах бандитов я реализовал 12 развилок. Как происходит переход между ними? Наш универсальный объект DialogWindow при вызове функции show сохраняет у себя список переданных диалогов и показывает тот, который определен в поле «start».

При отображении очередного диалога его массив choices отображается как набор кнопок, в атрибуты которых записывается номер выбора. А все функции action из choices записываются во внутренний массив dialogActions. При клике мышкой на кнопке выбора универсальный обработчик определяет номер функции в dialogActions и вызывает ее, попутно передавая два аргумента, которые мы решили использовать в этом диалоге. Таким образом, в диалогах с бандитами функция action в конкретном choice может принимать состояние мира (world) и описание текущих бандитов (bandits). А в диалогах к другим плагинам — другие параметры. Да можно и вообще без них, особенно, если смысл выбора — просто закончить диалог, как при геймувере.

Чтобы диалог закончился и игрок вернулся к карте мира, надо, чтобы функция action в объекте choice возвращала один из зарезервированных тегов «finish»,«exit»,«stop». Вообще смысл этой функции в том, чтобы возвращать имя следующей развилки. Но до этого заветного return-a можно и порой нужно вставить любую логику, любые вычисления, которые позволят выбрать следующую развилку — «run», «fight» или, быть может, даже «love».

Как вызвать диалог из плагина

В любой момент времени в update любого работающего плагина можно вызвать диалог следующим образом:

    // ... где-то в недрах update у объекта-плагина
    // останавливаем караван, аналог паузы
    world.stop = true; 
   // просим показать диалог с набором развилок из DeathDialogs
   // в развилки будут передаваться аргументы world и rule
    DialogWindow.show(DeathDialogs, world, rule, this);

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

DeathCheck.onDialogClose = function () {
    Game.restart();
};

Краткое описание существующих плагинов

В текущей версии игры используются следующие плагины:

Map2DPlugin — перемещение каравана по карте. Поиск городов, которые задаются в index.html как обычные div с параметрами top и left. Здесь же определяется прибытие в город и происходит автоматическая торговля.

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

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

DropPlugin — плагин перегруза. В прототипе из туториала про орегонский караван игра сама автоматически сбрасывала вещи — сначала оружие, а потом еду. Это было не очень комфортно и вызывало недоумение — как так-то? Ведь с оружием можно добыть еду, а «жареным мясом нельзя убить врага» (с) один известный стрим по Fallout 4. Так что я решил сделать диалог, в котором ты просто выбираешь, от чего избавиться.

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

WorldViewPlugin — интерфейсный плагин. Он просто обновляет интерфейс, показывая текущие параметры мира. Возможно, эта идея покажется кому-то странной — самостоятельный объект интерфейса, который отслеживает в цикле обновления изменения переменных. Но зато благодаря этой странной идее мы избавились от многочисленных updateUi и получили независимость между блоками разной логики.

Небольшие советы по текущей игре и балансу

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

Второй жизненно важный параметр — количество людей в караване. Они должны быть. Если всех людей выбивают — игра заканчивается.

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

Ссылки и дистрибутивы

Я использовал графику с лицензией Creative Common 0 с ресурсов pixabay.org и opengameart.org, так что и графика, и код распространяется на этих условиях — свободное копирование и использование, без каких-либо обязательств.

Исходный код можно взять с GitHub или скачать zip-архивом отсюда. Первый вариант предпочтительнее, так как чаще обновляется.

Для тестирования даже на локальном компьютере достаточно открыть index.html в браузере — там не используются функции, которым обязательно требуется сервер.

Живой билд игры можно потестить здесь. Верстка рассчитана на обычные мониторы, не на мобильные экраны.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/336724/

Метки: author Zoolander разработка игр javascript html html5 текстовые игры fallout игровая механика игростроение

Комментарии (0)

GeekUniversity открывает набор на факультет разработки игр

Понедельник, 18 Сентября 2017 г. 18:59 + в цитатник

mary_arti сегодня в 18:59 Разработка

GeekUniversity открывает набор на факультет разработки игр

В нашем онлайн-университете для программистов открылся новый факультет разработки игр. За год обучения студенты научатся писать игры на C#, достигнув уровня middle.

GeekUniversity — совместный образовательный проект Mail.Ru Group и IT-портала GeekBrains. Программу обучения и спецкурсы для факультета разрабатывают Avito, Альфа-банк, МТС, Тинькофф, DeliveryClub.

Чтобы поступить на факультет разработки игр, необходимо сдать тест по теории языка C#. Тем, кто не справится с вступительным испытанием, предложат пройти подготовительные курсы — восемь занятий, за которые можно освоить объектно-ориентированное программирование и базовые конструкции C#. Программа факультета рассчитана на год, а интенсивность занятий составляет три-четыре раза в неделю. В ходе учебы студенты реализуют ряд проектов, которые смогут добавить в свое портфолио.

В рамках обучения студенты освоят C#, SQL, классические алгоритмы и структуры данных, пройдут курсы по дополненной реальности, архитектурам и шаблонам проектирования, а также изучат основы 3D-моделирования — это позволит им создавать простые модели и переносить их в Unity3D. В ходе курса учащиеся разработают свою первую игру на C# Unity3D – «Танки» (желающие смогут предложить и реализовать собственный игровой проект), создадут мобильный 3D-шутер, спроектируют и реализуют многопользовательскую стратегию.

Оставить заявку и получить подробную консультацию можно здесь.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338200/

Метки: author mary_arti разработка игр блог компании mail.ru group mail.ru обучение программированию geekuniversity

Комментарии (0)

GeekUniversity открывает набор на факультет разработки игр

Понедельник, 18 Сентября 2017 г. 18:59 + в цитатник

mary_arti сегодня в 18:59 Разработка

GeekUniversity открывает набор на факультет разработки игр

В нашем онлайн-университете для программистов открылся новый факультет разработки игр. За год обучения студенты научатся писать игры на C#, достигнув уровня middle.

GeekUniversity — совместный образовательный проект Mail.Ru Group и IT-портала GeekBrains. Программу обучения и спецкурсы для факультета разрабатывают Avito, Альфа-банк, МТС, Тинькофф, DeliveryClub.

Чтобы поступить на факультет разработки игр, необходимо сдать тест по теории языка C#. Тем, кто не справится с вступительным испытанием, предложат пройти подготовительные курсы — восемь занятий, за которые можно освоить объектно-ориентированное программирование и базовые конструкции C#. Программа факультета рассчитана на год, а интенсивность занятий составляет три-четыре раза в неделю. В ходе учебы студенты реализуют ряд проектов, которые смогут добавить в свое портфолио.

В рамках обучения студенты освоят C#, SQL, классические алгоритмы и структуры данных, пройдут курсы по дополненной реальности, архитектурам и шаблонам проектирования, а также изучат основы 3D-моделирования — это позволит им создавать простые модели и переносить их в Unity3D. В ходе курса учащиеся разработают свою первую игру на C# Unity3D – «Танки» (желающие смогут предложить и реализовать собственный игровой проект), создадут мобильный 3D-шутер, спроектируют и реализуют многопользовательскую стратегию.

Оставить заявку и получить подробную консультацию можно здесь.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338200/

Метки: author mary_arti разработка игр блог компании mail.ru group mail.ru обучение программированию geekuniversity

Комментарии (0)

[Из песочницы] Что такое dinghy или как ускорить docker

Понедельник, 18 Сентября 2017 г. 18:39 + в цитатник

Разработка веб-сайтов

jesprider сегодня в 18:39 Разработка

Что такое dinghy или как ускорить docker

Разработка веб-сайтов

Из песочницы

Однажды я заглянул на Хабр, чтобы посмотреть как разработчики используют динги (dinghy) и вообще ускоряют работу докера на маке. На моё удивление по запросу динги я нашёл ровно ноль статей. Было бы нечестно не упомянуть, что тот же запрос вывел 4 комментария. С другой стороны этот факт не изменил картины в целом.

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

Производительность докера на osx
Запуск нескольких контейнеров, которые работают на порте 80

Под катом более подробное описание вышеперечисленных проблем, а так же способы их решения.

Проблема 1: низкая производительность докера на маке

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

Docker toolbox

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

В моём случае тулбокс оказался достаточно медленным. Данный инструмент хорошо подходит для запуска «статических» контейнеров. Когда же нужно интенсивно разрабатывать приложение, необходимо создавать mounted volumes (уже давно пытаюсь найти русский эквивалент, есть идеи?) вашей рабочей директории, то есть директории с кодом вашего приложения. И вот тут начинаются проблемы. Выяснив, что тулбокс не использует ни NFS ни rsync, я стал искать другие решения.

Преимущества:
— легко устанавливается и настраивается
Недостатки:
— медленный при разработке больших проектов

Docker for mac

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

К сожалению, докер для мака оказался ещё медленней. Никакого очевидного (и неочевидного) способа как ускорить сие приложение я не нашёл.

Преимущества:
— ещё легче устанавливается и настраивается
Недостатки:
— ужасно медленный
— только одна виртуальная машина, настраиваемся самим приложением

docker-osx-dev

Хорошее решение для ускорения работы на локальных машинах при работе с тулбоксом. Docker-osx-dev использует rsync, что значительно ускоряет отправку изменений в контейнер. Недостатком данного решения можно назвать «раздутый» размер контейнера, поскольку сами файлы копируются в контейнер.

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

Преимущества:
— значительно ускоряет перенос файлов в контейнер
Недостатки:
— висящий процесс
— раздувает размер контейнера

Dinghy

Dinghy — это надстройка над докер машиной (docker-machine), которая включает в себя NFS и proxy (о котором мы поговорим чуть позже, cейчас нас интересует проблема производительности). А насколько мне известно, ничего быстрее NFS (в данном контексте) ещё не придумали.

Теперь, вместо создания и использования дефолтной или бут ту докер виртуальной машины, мы создаём динги машину. По умолчанию в ней уже будет включен NFS. Если вы не хотите использовать прокси, то можно его отключить в настройках динги, поставив соответствующий флаг в true:

cat ~/.dinghy/preferences.yml
:preferences:
  :proxy_disabled: false
  :fsevents_disabled: false
  :create:
    provider: virtualbox
    disk: 30000

Недостаток: поскольку вы явным образом импортируете переменные окружения (например export DOCKER_MACHINE_NAME=dinghy и пр.), то использование обычных докер машин параллельно с динги может принести много хлопот.

Преимущества:
— скорость работы
— никаких дополнительных процессов
Недостатки:
— возможно потребуются дополнительные конфиги (docker-compose.yml)
— конфликт DOCKER_MACHINE_NAME с обычной докер машиной

Проблема 2: приложения на 80 порту

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

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

169b86af85da        codekitchen/dinghy-http-proxy:2.5   "/app/docker-entry..."    4 hours ago         Up 4 hours          0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 19322/tcp, 0.0.0.0:19322->19322/udp   dinghy_http_proxy

Этот контейнер слушает на 80 порту и принимает все запросы на себя. Внутри этого контейнера имеется nginx сервер, который автоматически создаёт виртуальные сервера исходя из вашего docker-compose файла. Всё, что вам нужно, указать hostname в этом файле. Далее, при обращении на данный хост, динги найдёт нужную запись и перенаправит на нужный контейнер. Профит.

Заключение

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

Если у вас возник интерес по техническим деталям, оставляйте комментарии, постараюсь на всё ответить.

Спасибо за внимание.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338198/

Метки: author jesprider разработка веб-сайтов docker dinghy docker for mac docker toolbox docker-machine docker-osx-dev

Комментарии (0)

[Из песочницы] Что такое dinghy или как ускорить docker

Понедельник, 18 Сентября 2017 г. 18:39 + в цитатник

Разработка веб-сайтов

jesprider сегодня в 18:39 Разработка

Что такое dinghy или как ускорить docker

Разработка веб-сайтов

Из песочницы

Однажды я заглянул на Хабр, чтобы посмотреть как разработчики используют динги (dinghy) и вообще ускоряют работу докера на маке. На моё удивление по запросу динги я нашёл ровно ноль статей. Было бы нечестно не упомянуть, что тот же запрос вывел 4 комментария. С другой стороны этот факт не изменил картины в целом.

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

Производительность докера на osx
Запуск нескольких контейнеров, которые работают на порте 80

Под катом более подробное описание вышеперечисленных проблем, а так же способы их решения.

Проблема 1: низкая производительность докера на маке

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

Docker toolbox

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

В моём случае тулбокс оказался достаточно медленным. Данный инструмент хорошо подходит для запуска «статических» контейнеров. Когда же нужно интенсивно разрабатывать приложение, необходимо создавать mounted volumes (уже давно пытаюсь найти русский эквивалент, есть идеи?) вашей рабочей директории, то есть директории с кодом вашего приложения. И вот тут начинаются проблемы. Выяснив, что тулбокс не использует ни NFS ни rsync, я стал искать другие решения.

Преимущества:
— легко устанавливается и настраивается
Недостатки:
— медленный при разработке больших проектов

Docker for mac

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

К сожалению, докер для мака оказался ещё медленней. Никакого очевидного (и неочевидного) способа как ускорить сие приложение я не нашёл.

Преимущества:
— ещё легче устанавливается и настраивается
Недостатки:
— ужасно медленный
— только одна виртуальная машина, настраиваемся самим приложением

docker-osx-dev

Хорошее решение для ускорения работы на локальных машинах при работе с тулбоксом. Docker-osx-dev использует rsync, что значительно ускоряет отправку изменений в контейнер. Недостатком данного решения можно назвать «раздутый» размер контейнера, поскольку сами файлы копируются в контейнер.

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

Преимущества:
— значительно ускоряет перенос файлов в контейнер
Недостатки:
— висящий процесс
— раздувает размер контейнера

Dinghy

Dinghy — это надстройка над докер машиной (docker-machine), которая включает в себя NFS и proxy (о котором мы поговорим чуть позже, cейчас нас интересует проблема производительности). А насколько мне известно, ничего быстрее NFS (в данном контексте) ещё не придумали.

Теперь, вместо создания и использования дефолтной или бут ту докер виртуальной машины, мы создаём динги машину. По умолчанию в ней уже будет включен NFS. Если вы не хотите использовать прокси, то можно его отключить в настройках динги, поставив соответствующий флаг в true:

cat ~/.dinghy/preferences.yml
:preferences:
  :proxy_disabled: false
  :fsevents_disabled: false
  :create:
    provider: virtualbox
    disk: 30000

Недостаток: поскольку вы явным образом импортируете переменные окружения (например export DOCKER_MACHINE_NAME=dinghy и пр.), то использование обычных докер машин параллельно с динги может принести много хлопот.

Преимущества:
— скорость работы
— никаких дополнительных процессов
Недостатки:
— возможно потребуются дополнительные конфиги (docker-compose.yml)
— конфликт DOCKER_MACHINE_NAME с обычной докер машиной

Проблема 2: приложения на 80 порту

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

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

169b86af85da        codekitchen/dinghy-http-proxy:2.5   "/app/docker-entry..."    4 hours ago         Up 4 hours          0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 19322/tcp, 0.0.0.0:19322->19322/udp   dinghy_http_proxy

Этот контейнер слушает на 80 порту и принимает все запросы на себя. Внутри этого контейнера имеется nginx сервер, который автоматически создаёт виртуальные сервера исходя из вашего docker-compose файла. Всё, что вам нужно, указать hostname в этом файле. Далее, при обращении на данный хост, динги найдёт нужную запись и перенаправит на нужный контейнер. Профит.

Заключение

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

Если у вас возник интерес по техническим деталям, оставляйте комментарии, постараюсь на всё ответить.

Спасибо за внимание.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338198/

Метки: author jesprider разработка веб-сайтов docker dinghy docker for mac docker toolbox docker-machine docker-osx-dev

Комментарии (0)

Результаты опроса «Каким бы вы хотели видеть Toster.ru?»

Понедельник, 18 Сентября 2017 г. 18:13 + в цитатник

toster сегодня в 18:13 Управление

Результаты опроса «Каким бы вы хотели видеть Toster.ru?»

Всем привет от команды Тостера! Работая над улучшением нашего сервиса, мы постоянно изучаем данные веб-аналитики, собираем обратную связь от пользователей через службу поддержки или через вопросы, которые задают по тегу «Toster.ru». А когда нам нужно принять более сложное решение или поглубже разобраться в поведении и предпочтениях пользователей, мы проводим опросы. Сегодня как раз хотим поделиться с вами результатами одного из опросов, который провели совсем недавно.

Мы спросили пользователей о некоторых принципиальных нововведениях, которые планируем ввести на сервисе, а также попросили сравнить Toster.ru и Stackoverflow.com по ряду параметров. В опросе приняли участие более 2.5 тысяч человек, из которых две трети являются разработчиками (причём 39% имеют уровень квалификации Senior или Lead, 38% — Middle, и 23% — Junior или Intern).

Новые возможности Тостера

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

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

Пользуясь случаем, мы предложили несколько вариантов разделения вопросов по сложности:

С небольшим отрывом победил вариант разделения вопросов по сложностям от Intern до Senior. То есть в том же стиле, в каком принято сейчас делить самих разработчиков по их квалификации.

Результаты опроса убедили нас в том, что делить вопросы по сложности надо. Надеемся, уже в скором времени вы сможете увидеть воплощение этой идеи на «Тостере».

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

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

Так что о введении отрицательных отметок мы ещё хорошенько подумаем. Для начала посмотрим — вдруг введение разделения вопросов по вопросов избавить от желания минусовать?

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

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

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

Дальше мы поинтересовались, хотели бы пользователи увидеть на «Тостере» конкурсные вопросы с денежным призом, который получал бы тот, чей ответ был первым признан решением?

Тут пользователи оказались более единодушны: более половины встретили эту идею тепло, лишь каждому пятому эта затея не понравилась.

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

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

Интеграция «Тостера» с другими сервисами TM

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

67% опрошенных хотело бы иметь возможность получить полноценный аккаунт на Хабрахабре за свою активность на «Тостере»;
56% согласились с тем, что за должную активность на «Тостере» было бы неплохо получить возможность бесплатно пользоваться сервисом «Фрилансим»: размещать заказы или откликаться на них;
46% согласилось с тем, что клёво иметь возможность не просто помогать людям находить решения, но и, в качестве бонуса, бесплатно размещать вакансии на Моём круге!
Против таких возможных бонусов высказалось не более 10%.

Мы не будем до конца открывать завесу тайны над будущим «Тостера», однако, хотим отметить, что ваше мнение нам очень помогло скорректировать вектор дальнейшего развития проекта.

Тостер и StackOverflow

Поскольку нас частенько сравнивают со Stackoverflow, мы решили не упускать возможности и поинтересовались у пользователей, в чём преимущества «Тостера» над Stackoverflow и наоборот, в чём преимущества Stackoverflow над «Тостером»?

Большинство (порядка 40%) считает, что задать вопрос или дать ответ одинаково просто (сложно) на обоих ресурсах. Мнение оставшихся разделилось так, что вдвое большее число ответивших считают, что проще задать вопрос или дать ответ на «Тостере». А вот аудиторию Stackoverflow считают более дружелюбной, нежели на «Тостере».

Вопрос о преимуществах «Тостера» и StackOverflow мы оставили открытым, дав возможность самостоятельной формулировки. Не будем приводить здесь все ответы, ведь их огромное множество (и спасибо вам за это!), но топ самых популярных ответов выглядит так:

Основные преимущества «Тостера»:

Русский язык
Более приятный интерфейс
Возможность создавать дискуссионные вопросы
Более широкая тематика
Можно просматривать все вопросы
Локализация (специфичный софт вроде 1С)
Рассылка дайджеста (это нас удивило)
Низкий порог входа

Основные преимущества SO:

Более сложные вопросы

Большая аудитория
Больше готовых решений
Отсутствие дискуссий
Лучшая модерация
Англоязычное коммьюнити

Мы ни в коем случае не стремимся сделать из Тостера второй StackOverflow, но из ответов мы увидели, что у нашего сервиса есть свои убедительные преимущества, которые мы будем развивать и поддерживать дальше. Прежде всего, мы и дальше будем стараться создавать место, где IT-специалисты смогут получать ответы на самые разные вопросы, касающиеся их деятельности: как простые, так и сложные; как имеющие однозначное решение, так и затрагивающие более широкую дискуссионную проблематику или обмен опытом.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338196/

Метки: author toster управление сообществом блог компании тостер тостер toster.ru amp;a вопросы и ответы it опрос