Carduelis Jul 10 2017 at 11:46

Почему я перешел с React на Cycle.js

9 min

18K

JavaScript*ReactJS*

Recovery Mode

Translation

+20

Comments 24

napa3um Jul 10 2017 at 13:07

RxJS + React дадут примерно то же самое, правильно понимаю? Ну и таки кажется, что без хранения состояния в явном виде всё равно в приложении не получится, без модели не обойтись (именно она и будет синхронизироваться с персистентными хранилищами и внешними ресурсами). Грубо говоря, Цикл.ЖС — это не фреймворк, а библиотека привязки ДОМа к модели через концепцию потоков событий. Примерно так видится ниша Цикла.

Carduelis Jul 10 2017 at 13:33

Возможно вы и правы, но сами создатели позиционируют его как фреймворк:

A functional and reactive JavaScript framework for predictable code.

napa3um Jul 10 2017 at 13:34

(Называть Цикл.ЖС фреймворком или библиотекой мне не очень принципиально, хотелось бы подтверждения остальным догадкам, чтобы понять для себя, есть ли смысл «погружаться глубже» :).)

Arinteck Jul 10 2017 at 13:18

К сожалению, остались не ясны плюсы перехода на Cycle.js. В качестве примера автор говорит о сотне компонентов в сотне контейнеров. Разве это минус реакта? Как описываемый инструмент позволит сделать работу с большой кодовой базой проекта проще? Аналогично и про потоки данных (да, действительно в реакте их нет, так реакт — это лишь библиотека для рендера).

Сам же фреймворк лично у меня оставил впечатление jQuery в который добавили стримы и реактивности.

Carduelis Jul 10 2017 at 13:21

Сотни компонентов и контейнеров действительно тяжело поддерживать из-за того, что все это раскидано по директориям, об этом и говорит автор. Вопрос в том, насколько это решается в Cycle.js — вопрос открытый. Если вы имеете опыт в Cycle.js, было бы здорово, если бы вы им поделились ;)

Arinteck Jul 10 2017 at 13:31

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

Amareis Jul 10 2017 at 13:25

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

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

evilelf Jul 10 2017 at 13:36

Есть у cicle.js что-то типо react-native?

Carduelis Jul 10 2017 at 13:38

Есть драйвер, но в экспериментальном режиме пока: @cycle.js/react-native, github

dem0n3d Jul 10 2017 at 14:04

Мне кажется, что старое доброе приложение-счетчик, будет идеальным для этого примера.

Обожаю такие обороты. Очевидно, оно идеально, потому что на чем-то более приближенном к действительности (сложном) cycle.js уже показывает себя не так выгодно?

vintage Jul 10 2017 at 15:17

А я не поленился и добавил todomvc на нём в бенчмарк. Как-то он не показывает себя особо шустрым даже в таком тривиальном приложении. Не говоря уж о том, что ручное управление потоками — отстой.

RubaXa Jul 11 2017 at 12:45

Так Cycle.js очень медленный, впрочем как и любой код на FRP ;]
Кстати, а вы не пробовали, ради развлечения, на базе ваших атомов сделать rx-like либу?

vintage Jul 11 2017 at 14:08

Эм… а зачем?

RubaXa Jul 11 2017 at 14:16

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

vintage Jul 11 2017 at 14:54

С чего бы ей быть шустрее, если вручную оптимально заоркестировать потоки крайне сложно? Разве что за счёт автоматического distinctUntilChanged и debounce.

napa3um Jul 11 2017 at 15:14

А ваши Атомы похожи на обсерваблы и трассировку зависимостей Нокаута? (Я, возможно, уже спрашивал, но вот сейчас появилась необходимость в такой библиотеке вне контекста привязки к DOM'у, возможно, имеет смысл взять вашу реализацию).

vintage Jul 11 2017 at 15:39

Да, под его впечатлением и создавалось, но с более эффективным механизмом актуализации.

napa3um Jul 11 2017 at 15:43

(Спасибо, интересно, гляну в ближайшее время.)

pm_wanderer Jul 10 2017 at 16:38

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

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

React, Angular, Backbone, Ember, Extjs и т.д.
Добавьте сюда еще различные инструменты сборки и языки, компилируемые в JS.

Черт, когда я встречаю фронтендера, то мне неочем с ним говорить — его стек инструментов и технологий настолько далек от того что мне знакомо и понятно))

Carduelis Jul 10 2017 at 16:40

Всегда можно поговорить о функциональном, реактивном, объектно-ориентированном подходах, как организовывать архитектуру директорий и файлов и прочем общем ;)

Odrin Jul 10 2017 at 16:59

Так их и есть всего 2 авторитетных: Angular и React. Backbone — умер в ходе эволюции. Ember еще пытается подавать признаки жизни, но популярность его падает. Ext JS стоит денег и ставить его сюда в один ряд не совсем корректно. Ну можно еще Vue.js сюда записать.

Реально живых языка тоже всего два: TypeScript и Dart. Все остальное умирает без надобности.

vba Jul 11 2017 at 11:01

Cycle.js. Она содержит 26 методов и весит 30kb. Это одна из самых быстрых библиотек для реактивного программирования на JS

Интересный у вас подход в определении производительности библиотек.

Я уже работал с RxJs, и нашел ее лишь бледным подобием RxJava. Скажите как обстоят дела у Cycle.js с поддержкой back pressure?

JSmitty Jul 11 2017 at 14:36

Для любителей FP и FRP есть Elm, у которого синтаксис несколько более приспособлен к функциональщине (хаскель на JS).

bano-notit Jul 12 2017 at 10:04

Всегда прикалывал такой подход: скажем что у фреймворка А есть такие то минусы, а потом скажем что у фреймворка Б есть такие то плюсы.
Где же само сравнение? Я вот так и не понял, почему это с Cycle.js кода в большом проекте будет меньше? Почему недоООП, которое разрабами представляется как функциональное — проблема?

Show the best of all time