зато на них быстро писать

Бэкенд на JS может быть не основным бекендом так-то, учитывайте У нас бэк на .NET, а нода в виде третьего слоя, на котором фронты сами пишут красивый API не дёргая бэкендщиков - красота и рай

JRuby?

Не пробовал, сейчас попробую погуглить бенчмарки

Бэкенд - бэкенду рознь.

но ноде можно какие то отдельные штуки писать

Ну да, чому бы и не написать какой-то кусок на ноде допустим

скала, С++, кложура

В кожуре нет статической типизации, не понято в чем профит

На С++ ещё кто-то пишет?

В кожуре нет статической типизации, не понято в чем профит

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

питон руби го хаскель эликсир

го - тоже не лучший выбор, только если разбить на микросервисы

Давайте может не будем изображать снобов, если уж фб в своем начале жил на php потом с hhvm и т.п., то мы тут будто бэкенд интерфейса который прям к мозгу подключается собрались писать.

JRuby?

А вот JRuby очень тормозной, там полиморфизм сделан через dynamic call site’ы

"Забавно, изначально React/Flux в Фейсбуке придумали, чтобы избежать циклических зависимостей (при рендеринге), но теперь они возвращаются" Но на mobx можно следовать методологии flux, т.е. диспатчить экшны через миддвари в рамках одностороннего потока данных, как это сделано, например, у mobx-reactor. Я не писал больших js-приложений, возможно, где-то там проблема закольцованных зависимостей может попортить жизнь, но разве это не решается на этапе проектирования системы ?

Начал гуглить про jruby, из свежего нашлось первым это :) https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/

"Забавно, изначально React/Flux в Фейсбуке придумали, чтобы избежать циклических зависимостей (при рендеринге), но теперь они возвращаются" Но на mobx можно следовать методологии flux, т.е. диспатчить экшны через миддвари в рамках одностороннего потока данных, как это сделано, например, у mobx-reactor. Я не писал больших js-приложений, возможно, где-то там проблема закольцованных зависимостей может попортить жизнь, но разве это не решается на этапе проектирования системы ?

Если есть большое приложение и там архитектурно что то плохое можно сделать — это гарантированно будет сделано. Вопрос времени

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

Я не про то во что это скомпилится, а про то ругнется ли компилятор когда я опечатался или написал ересь

Я не про то во что это скомпилится, а про то ругнется ли компилятор когда я опечатался или написал ересь

А для этого есть опциональная система типов (core.typed) Правда ничего за неё сказать не могу ибо не использовал

А для этого есть опциональная система типов (core.typed) Правда ничего за неё сказать не могу ибо не использовал

Ну вот, а я на опыте работу с большими проектами на js понял, что без типов жить тяжело

И хочется, чтоб компилятор сразу ругался на ересь

А есть здесь люди работающие с flow? Плюсы, минусы, подводные камни?

Хотя, наверное если знаешь js, то нода будет хорошим выбором

Flux Альтернатива не MVC, а архитектуре модели на обзерв. Flux предлагает cqrs

Верно, реакт позиционировался чуть ли не на всех первоначальных презентациях как альтернатива mvc/mvvm где клубок кроссзависимостей запутывается с огромной скоростью, в том числе и благодаря обзерверам во многих фрэймворках. А теперь mobx предлагает тоже самое только с реактом в качесве рендера, это забавно. Но с момента выхода реакта выросло целое поколение разработчиков, которые не сталкивались с этой проблемой mvc/mvvm и они с рвением кинулись к "новому" подходу :)

Хотя, наверное если знаешь js, то нода будет хорошим выбором

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

flow Владимир горячо реконмендовал, вот его презентация с последнего nodejs митапа http://vkurchatkin.github.io/talks/flowscript/#1

flow Владимир горячо реконмендовал, вот его презентация с последнего nodejs митапа http://vkurchatkin.github.io/talks/flowscript/#1

Спасибо!

а почему не тайпскрипт

Потому, что TS это транспилер + расширение языка от MS, а Flow - проверка типов (Flow is a static type checker )

Если нужна простая статическая типизация, Flow самое оно.

Насколько я понимаю, для ректа возможно даже лучше Flow и юзать.

http://flowtype.org/docs/react.html

Так особо нет разницы

плюс у flow - его удобно юзать прямо в babel, а у ts свой отдельный компилятор. Но у ts уже есть неплохие тулзы как-то комплитер, рефакторинг и goto

Так особо нет разницы

Есть. Flow static type checker, а TS расширение языка (транспилер в JS) со статической типизацией.

http://flowtype.org/docs/five-simple-examples.html#2-adding-type-annotations

flow тоже имеет расширение синтаксиса, и женерики там есть. Интерфейсов разве что нет)

flow тоже имеет расширение синтаксиса, и женерики там есть. Интерфейсов разве что нет)

Это все относится к статической типизации. Помимо этого в TS есть async/await и специфичные для MS фишки.

Т.е. в принципе, TS этот тот же babel.

ну, там есть некоторые фишки из stage1

декораторы и async-await

В flow?

в ts

да, я тоже считаю отдельный от babel транспилер минусом

но это единственное серьезное различие с flow

но эти async/await и декораторы вроде отрубаются или отрубались, я вот не помню(активно их юзаю, не отключал, а наоборот врубал как только добавили)

Ну так это и есть основное отличие. TS транспилер со встроенным "flow", а "flow" самостоятельная тулза, которая может быть частью экосистемы в babel.

Про отличие и спрашивали :)

ну, ts может компилить в es6, а дальше под нужные экосистемы с плагинами babel комплими во что угодно или оставляем под нодой

TS кстати отстает от бабеля на сегодняшний день.

мы юзаем такой флоу, меня не устраивает es5 код ts

ну, ts может компилить в es6, а дальше под нужные экосистемы с плагинами babel комплими во что угодно или оставляем под нодой

Можно и так.

ну, мы так юзаем

Для фронта я так думаю

потому что как уже заметили, отстает

Ждем 2 и 2.1 TS :)

вот бы кто запилил babel-plugin-typescript )

кстати, я же прав, что на основе flow нет еще refactoring/completer/goto решений?

В вебшторме 2016 есть, но довольно слабенькое

Для атома вроде плагин был

ну, вебшторм сам в себе, он и js мог, но не стоит)

Т.е. в принципе, TS этот тот же babel.

Мы как-то делали сравнение, к слову, и на выходе у TS какой-то более приятный код получается, и более компактный и более читабельный (хотя кому какое дело :)), так что решили его вместо babel и юзать

@StGeass а какие версии сравнивали?

Это было пару месяцев назад, так что скорей всего 6.7.x с TS 1.7

ERROR: S client not available

Народ, а какой boilerplate для react можете посоветовать?

@DenisIzmaylov "www.moscownodejs.ru took too long to respond. This site can’t be reached"

Всем привет. Подскажите пожалуйста по Draft.js: Есть форма редактирования комментариев (Editor), есть кнопка "отправить комментарий". Теперь сама проблема, как заставить все это отправлять комментарий? Не пойму как связать кнопку, editor и чтобы комментарии отправлялись.

Народ, а какой boilerplate для react можете посоветовать?

https://github.com/kriasoft/react-starter-kit

Народ, а какой boilerplate для react можете посоветовать?

http://andrewhfarmer.com/starter-project/

я написал небольшую обертку для редукса которая позволяет коннектить компонент к срезу редуксовского стейта и работать с ним в стиле чисто реактовского setState. В разы уменьшает количество бойлерплейта. Зацените https://medium.com/@nosovsh/redux-without-reducers-actions-and-constants-wat-72fcd838c641#.b14h8aadt

вроде ок, но только елси в первом примере перевести на stateless, там тоже будет локоничнее )

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

И погоди, как раз в первом примере stateless не получится, там же как раз нужен реактовский стейт))

я написал небольшую обертку для редукса которая позволяет коннектить компонент к срезу редуксовского стейта и работать с ним в стиле чисто реактовского setState. В разы уменьшает количество бойлерплейта. Зацените https://medium.com/@nosovsh/redux-without-reducers-actions-and-constants-wat-72fcd838c641#.b14h8aadt

Сам хотел что-то подобное написать :) Концепутально это похоже на линзы

Некорректное сравнение. В итоговом коде всё равно есть actions.js и прочая шняга

если я правильно понял

нет, в итогово нету

Некорректное сравнение. В итоговом коде всё равно есть actions.js и прочая шняга

А, точно.

https://gist.github.com/nosovsh/38fda16f55df6f61ca316bf1729f8163#file-myformreduceless-js

А, ну мы получается тригеря setState из компонента, диспатчится некий сгенерированный экшон, который приходит в редюсер и дальше всё как обычно?

потом редюсер из либы его перехватит и сам извенит стейт. То есть больше писать редюсеров не нужно

я написал небольшую обертку для редукса которая позволяет коннектить компонент к срезу редуксовского стейта и работать с ним в стиле чисто реактовского setState. В разы уменьшает количество бойлерплейта. Зацените https://medium.com/@nosovsh/redux-without-reducers-actions-and-constants-wat-72fcd838c641#.b14h8aadt

А эта либа подразумевает, что локального стейта вообще нет и всё в сторе? Или я что-то пропустил?

то есть если сделать setState({'value': 'blablah'}) в компоненте, который обернут в connectSlicedState('contactsPage.leftPanelWidget')(Component), то в редуксовском стейте изменится(или добавится) вот эта часть стейта: contactsPage.leftPanelWidget.value на 'blablah'

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

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

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

ща

Ну или gist хотя-бы

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

Есть ещё один подход. Но в принципе согласен, что много боилерплейта приходится писать https://github.com/erikras/ducks-modular-redux

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

эту обертку, можно так же использовать с redux-thunk или чем то еще. из асинхронных экшенов можно вызывать dispatch(setStateByPath('entities.posts.123.title', {title: 'new title'})) когда объект получен и он запишется вот в эту часть стейта полученый объект. и не нужно будет писать константы и редюсеры, что бы это отловить

Есть ещё один подход. Но в принципе согласен, что много боилерплейта приходится писать https://github.com/erikras/ducks-modular-redux

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

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

https://gist.github.com/nosovsh/bfc2e04686c391056cc2377f0ab4ff30 вот пример где оба стейта (реактовский и кусок редуксовского) живут бок о бок в одном компоненте. в комментах там описал. Если непонятно выразил свою мысль, пиши, попробую уточнить

https://gist.github.com/nosovsh/bfc2e04686c391056cc2377f0ab4ff30 вот пример где оба стейта (реактовский и кусок редуксовского) живут бок о бок в одном компоненте. в комментах там описал. Если непонятно выразил свою мысль, пиши, попробую уточнить

Понял, спасибо!