Те данные что, что считаются приватными, конечно, фильтруются перед отправкой. Плюс bugsnag, как и многие такие облачные сервисы, сертифицирован по европейским и американским стандартам приватности данных.

Вложу и свои пять копеек.

Во-первых надо думать от задачи, а не от того как выглядит код. А также учитывать какие самые важные базовые принципе заложены и продвигаются библиотекой. В случае MobX это мутируемый стейт и ссылочная целостность. В случае Redux это иммутабельные данные и сохранение истории состояний (аля граф состояний).
Соответственно, если вашей программе нужен Undo/Redo на большую глубину, сериализация состояния и истории того, как приложение в это состояние попало (например, для репортинга ошибок в сервисы вроде Bugsnag или для оффлайн работы), то берите иммутабельные библиотеки вроде Immerjs и Redux в связку. Кстати, заметьте, что Immerjs — это иммутабельная либа от того же автора что создал MobX :)
Если же у вас сложная структура данных с циклическими ссылками, таблицы на миллион строк, чарты с большим кол-вом данных, то есть все что требует сверх высокой производительности то берите MobX.

Второе это то, что обе библиотеки про стейт, а не про работу с асинхронной логикой. Поэтому приводить Redux-Saga или Redux-thunks в качестве недостатка несколько неправильно. MobX может прекрасно работать в связке с Redux-Saga или RxJS или чем-то еще. Вопрос в том на какую архитектуру вы все это положите. Можно, конечно, делать асинхронные вызовы прям из MobX классов, но это приведет ровно к тому почему Facebook изобрел Flux во-первых, и почему Redux победил конкурентов во-вторых. В Flux разделили асинхронную логику и синхронную, пропустив данные через горлышко dispatcher-а. Это позволило контролировать как обновляется стейт и позволило частично избежать гонок и каскадных обновлений, что упрощает дебагинг и контроль состояния. Но оставалась возможность подписывать одни модели на другие с помощью пресловутого waitFor, что часто приводило к тому, что вообще не было понятно кто кого и когда обновил и где спрятался баг. Именно это Redux и исправил сделав стейт предсказуемым. Даже лозунг Redux — «A Predictable State Container for JS Apps».
Поэтому на текущий момент желательно использовать MobX в той же Flux архитектуре и разделять обновление стейта и асинхронные запросы. Что возвращает нас к вопросу а что вообще будет делать ваше приложение и как вам предпочтительнее управлять состоянием?

Из своего опыта добавлю: мы запили на редаксе прекрасную централизованную систему обработки ошибок благодаря middleware и простой сериализации JSON.stringify. При любой ошибке стейт и последнии 5 экшенов логируются в SaaS Bugsnag и всегда можно проверить а в каком состоянии было приложение, что привело к ошибке.

Сейчас учиться сложно!? Да ну, сейчас легче легкого. Посмотрите, что писал тот же Абрамов по этому поводу twitter.com/dan_abramov/status/915883346772840448
Миллионы книг, туториалов, бесплатные курсы от ведущих вузов, буткампы всякие, до авторов книг можно достучатся по почте и они даже отвечают. Учись не хочу, было бы желание.

Спасибо за статью!
Очень интересно сможет ли 3D в вебе стать популярным не только в играх.
И еще любопытно будет ли 3d рынок двигаться в направлении «все делаем в unity и потом компилируем в webasm и webgl» или все так найдется место и для javascript движков вроде three.js?

Вроде facebook flow позволяет делать более гранулированный tree-shaking с помощью flow-графа даже на нетипизированном javascript. https://youtu.be/VEaDsKyDxkY?t=1535

И тут походу все забыли, что каждый разработчик хочет зарабатывать по несколько килобаксов в месяц, а еще к этому разрабу надо нанять аналитика, UX/UI спеца, дизайнера, тестировщика и тп. Все это сразу будет стоить овердохрена денег, а потом это еще и умножить на 3 мобильные платформы и присыпать веб-версией для десктопов. И тут заказчик начинает плакать потому, что стока денег нет и не предвидится. Особенно это актуально для некоммерческих проектов с ограниченным бюджетом. И хоть я не согласен с автором, что нативные приложения обречены и что не все, конечно, можно заменить вебом, но PWA при должной поддержке имеют хорошее будущее.

Спасибо за статью!

Redux хорош как раз тем, что в можно получить «срез» всего приложения в любой момент времени, взглянуть на состояние, сравнить с предыдущим, пройтись по логу экшенов и понять где ошибка. Полная предсказуемость как Redux себя и позиционирует. Если еще использовать глубокий Object.Freeze на стейт (в dev режиме, не в продакшене, чтобы не тормозило), то всякие случайные мутации вроде if (state.todo.title = 'first') ловятся на ура.

А для cайд-эффектов крайне рекомендую посмотреть redux-saga. Просто невероятно облегчает работу с асинхронными вызовами благодаря генераторам и CSP.

Как альтернатива редаксу — MobX. Авторы наоборот делают ставку на мутабельный стейт, но с фишками редакса вроде логирования изменений стейта, вывода разности между текущим и предыдущим стейтом, защиты от случайный мутаций. Основная идея в поддержке ссылочной целостности (referential equality), то есть что объект состояния всегда один и тот же и никогда не клонируется, и в подключении как можно большего числа компонентов к стейту. Это позволяет, например, обновлять содержимое ячейки таблицы вообще без перерисовки всей таблицы (я имею ввиду без захода в render компонента Table). Большой плюс к производительности и меньше мучений с shoudComponentUpdate. К недостаткам можно отнести способ подписки на изменения через get/set, а не через сравнения содержимого, что требует обязательно передачи подписчикам всего объекта подписки, а не только, допустим, его части. Поэтому нельзя наблюдать примитивные типы и т.д. Но это недостаток не в смысле реализации, а в том смысле, что можно легко ошибиться неправильно подписавшись и не понимать почему не приходят обновления. Лучше подробнее смотреть здесь http://mobxjs.github.io/mobx/best/react.html