Flux vs Redux

Flux - это подход к проектированию. А redux - конкретная библиотека, реализующая данный подход.

эскобар.жпг

Чувак, я неделю назад во фронт влез после бека на Python и разработке на ++

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

Я говорю вот про этот Flux

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

он тоже говорит про этот флюкс

Flux - много сторов, eventemitter, waitfor и вообще провоцирует на бойлерплейт и стрельбу по ногам, когда нужно много координированных изменений. Redux - один стор, чистые функции, бойлерплейт для сложных кейсов, но стрелять по ногам сложнее.

Но вообще используй стейт в компонентах, пока не наступит боль - потом сможешь сравнить.

килограмм пакетных менеджеров и таскранеров

Пакетные менеджеры: bower и npm, таскраннеры: grunt и gulp. Ну ок, скриптосборщиков тоже пара: browserify и webpack. Что ещё?

разработке на ++

вот там как раз целый зоопарк систем сборки: autotools, cmake, scons, qmake, qbs, jam...

Ага, но на практике же нужен только один одновременно на проект.

Я если честно не понял зачем нужны таскранеры если можно заюзать просто npm скрипты?

Ага, но на практике же нужен только один одновременно на проект.

npm, gulp, webpack :)

зачем нужны таскранеры если можно заюзать просто npm скрипты?

Примерно по той же причине, по которой для C/C++ используют системы сборки вместо просто sh-скриптов. Например, таск может включать в себя множество сабтасков, таски могут немного различаться (к примеру, таск «js:dev» может не минифицировать конечный файл), можно контролировать изменение файлов, инлайнить в css-файлы только небольшие картинки, автоматически расставлять браузерные префиксы, ну и так далее. Вдобавок, можно параллельно сгенерировать map-файлы, синхронизированные с реальными исходниками. Теоретически, всё это можно делать и шеллскриптами, но получится очень замороченно.

Сейчас вроде уже grunt и gulp никто не юзает, все на webpack сидят.

А ты пробовал? Я вот перепелил фронтенд своего проекта на redux. Получилось чертовски круто. Попробуй, ещё захочешь. Я гарантирую это.

4.2 Множество проектов как сидели на grunt и gulp, так и сидят. И никуда перебегать не собираются.

Сейчас вроде уже grunt и gulp никто не юзает, все на webpack сидят.

Бывают довольно сложные кейсы, когда одним вебпаком не обойдёшься. Например, в Angular 2 проверяется shrinkwrap-файл для текущей ветки (контроль версий пакетов в локальном node_modules). Или же, если стилевые файлы не вкомпиливаются в js-бандл, то вебпак тут мало чем поможет. Так что вебпак приходится запускать через галповый плагин.

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

Это там где шаблон прямо в коде? Не, спс.
Через пару лет какой-нибудь хипстер скажет «Мм, а было бы неплохо если бы в калбеке можно было дергать анус.
А потом десятки тысяч дергают и не понимают зачем.

Мы уже это с тобой вроде обсуждали. Не помню правда к чему пришли. Лично я считаю, что нет никакого смысла разделять жабоскрипт и разметку. Какой смысл, обмазавшись тайпскриптом, городить всякие DI контейнеры, сервисы и прочую хрень? А потом изобретать очередной недошаблонизатор, чтобы снова пихать логику в шаблоны, чего ты так не хочешь. Задача какая? Взять json с бэкэнда и показать его пользователю. С этим реакт отлично справляется, и я не вижу ни одной причины, по которой я должен использовать монструозные фреймворки типа ангуляра и прочего.

А что, ractive вдруг стал монструозным?

взять json с бэкенда и показать его пользователю

Для этого и ректал не нужен, достаточно pure js.

Там где не нужен реакт в большинстве случае и pure js не нужен, можно просто на сервере рендерить.

Слишком просто.

Наличие шаблонизатора не делает фреймворк монструозным. А вот к примеру DI фреймворк да. Зачем мне DI фреймворк на клиенте? Зачем мне нужно разделять логику и представление, блджад, в представлении?

Что касается шаблонизаторов, то польза от них весьма сомнительная. Тебе как ни крути придётся использовать JS, чтобы взаимодействовать с вёрсткой. Я не понимаю зачем при этом использовать всякие лишние абстракции, которые ничего кроме тормозов не добавляют.

в калбеке дергать анус

Но фронтенд и состоит целиком из этого, разве нет?

Зачем мне нужно разделять логику и представление, блджад, в представлении?

Недавно видел похожий бугурт от реакта, задал этот вопрос и не получил ответа. Рили интересно.

Старым проектам и нет смысла куда-то уходить. Как говорится - работает не трогай :)

Пока приложение не больше тудушки его еще как-то можно читать. Большое уже распарсить невозможно(особенно блядский jsx, который придумал какой-то версута), верстка компонента на пару экранов. Кто, что делает?
Особенно доставляет верстакам.

верстка компонента на пару экранов

Шаблоны на пару экранов, сорцы какой-нибудь софтины на любом ЯП с файлами размером в 1к строк и более, тоже самое, не? Словом, плохой аргумент. Если структурировать не как мудак, то всё будет нормально.

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

На мои вопросы, я так понимаю, у тебя ответов нет, верно? Т.е., как ты выразился, в калбеке дергаешь анус и не понимаешь зачем, верно? Лёл.

Ах структурировать надо уметь, ясн.
Это не первое впечатление, jsx ужасен.
Какие вопросы? Про диай и прочие? Хз, не пользуюсь.

Ах структурировать надо уметь, ясн.

Нужно просто не быть идиотом и не месить по тыще строк в одном файле. Это же очевидно.

Это не первое впечатление, jsx ужасен.

Так же, как и HTML, XML. Что же там такого, что тебя от него так воротит, я понять не могу?

Какие вопросы? Про диай и прочие? Хз, не пользуюсь.

Чёрт с ними с паттернами. Ты мне вот что скажи:

Зачем мне нужно разделять логику и представление, блджад, в представлении?

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

Я хотел услышать ответ на вопрос: почему я должен разделять javascript и html, используя при этом костыли в виде шаблонизаторов? В итоге всё равно получится лапша из js и html, но с лишней абстракцией. Это разделение технологий, а не ответственности. Никакой пользы в этом нет совершенно. Зато головной боли прибавится.

И никакой захардкоженной параши у меня почему-то нет. У меня есть глобальное состояние, которое обновляется в зависимости от действий пользователя. А всё, что делает react, так это просто рендерит данные, собственно, для чего он и предназначен.

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

В итоге всё равно получится лапша из js и html

Не получится.

Я сделал тодо)) Для большего он к сожалению не годится.

HTML отвечает за то, как показывать. Часть логики в жаваскрипте отвечает за то, как это должно работать. Почему ты считаешь, что это нельзя смешивать? Представим, что есть компонент вида: `кнопка: текст`. При клике по кнопке текст меняет свой цвет. Так логика, которая отвечает за обработку события и обновление стиля текста, следуя твоей логике, является бизнес-логикой и должна быть отделена от представления, я всё правильно понял?

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

Конечно. А что если по нажатию кнопки тебе захотелось еще и дернуть анус. Придется же лезть в эту парашу и вилкой..

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

Ты где так упоролся? Анус можешь дёргать себе где угодно. Я пытаюсь понять, почему ты решил, что логика работы с DOM должна быть независима. Никто не говорит, что получение и преобразование данных должно быть в компонентах. А вот то, что отвечает за поведение компонентов, тому там самое место. Всё, что я услышал от тебя, так это то, что ты яростно наяриваешь анусы. Зачем — не понятно.

Я вообще ничего про логику работы с DOM не говорил. Да и вообще зачем в данном случае работать с деревом напрямую если можно просто изменять состояние?

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

Да

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

Поведение ну никак не изменится после рендеринга. Все события будь то click или hover вообще не отреагируют на изменение шаблона.

Ещё раз

будут аргументы за разделение или можно считать, что ты просто так думаешь, потому что это делает большинство?

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

И в чём же заключается это удобство? Переключаться между шаблоном и js файлом по сто раз туда сюда? Или изобретать прелоадеры, чтобы юзер не видел сырого шаблона, пока эта хрень будет два часа рендерить его? А может изобретать наркоманские директивы как в ангуляре? Давай по пунктам «это удобно, потому что: 1. ... 2. ... 3. ... ...».

Реакт компонент по сути тот же шаблон, только выполненный в js. Шустрее работает. Не нужно изучать нового синтаксиса. Меньше нужно париться о том, когда надо что-то показать, другое надо скрыть. У тебя просто есть стейт и/или набор параметров, по которым всё будет рендериться. Ты можешь сразу увидеть, как будет отрендерен компонент. Отлаживать всё это дело очень просто.

Рекомендую глянуть http://www.youtube.com/watch?v=YJNUK0EA_Jo

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

Зачем переключаться

У тебя html отдельно, js отдельно. В разных файлах. Допустим, тебе нужно навесить обработчики событий. Ты делаешь это либо в шаблоне, либо в js файле. При ковырянии в этом говне тебе так или иначе придётся втыкать то туда, то сюда. Хрен с ним. Это не такая уж и большая проблема. Хотя отлаживать это говно то ещё удовольствие.

Юзер не увидит никаких шаблонов т.е он либо загружается динамически, либо уже в теле. И лол, как будто это избавляет ректал от прелоада. Он ему так же нужен как и всем.

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

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

Вообще это зависит от объёма данных и подхода к рендерингу (перерисовывать всё полностью или вычислять изменения и перерисовывать только то, что изменилось например). Я не хочу спорить на эту тему. Ты так и не сказал, в чём конкретно профит. Всё, что я услышал, так это «так удобнее дергать анус в калбэке, ко-ко-ко».

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

Ты так говоришь, как будто это что-то плохое.

еще и реквесты сами делают

Не делают. Бизнес-логика отдельно. Представление отдельно. Всё как у людей.