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

по сравнению с жс это может и плюс, но жс вообще никакой

а без продвижения он скорее всего так и останется где он сейчас

а он не нужен никакой конторе

жсу пытается тайпскрипт помочь

и у них это хорошо получается

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

так себе плюс. это с любой развитой системой типов так будет и даже при наличии null/nil

Нет. NULL давно признан ошибкой. Не нужен он просто

не нужен — не юзай этот тип и нуллабл типы

таких языков овер9000

код функциональный работает на удвиление более надежно, не замечали?

вроде бы ту же задачу решает

код функциональный работает на удвиление более надежно, не замечали?

не вижу в этом ничего удивительного

сложнее написать, чтобы работало, но если работает - то правильно

я имею ввиду, что это прямо по ощущению проходит

например, кто на cycle пробовал писать - чувствуют что легче и надежнее работает, но написать сложнее

даже те кто, вообще не в теме

такое практически иррациональное ощущение)

не нужен — не юзай этот тип и нуллабл типы

Не работает так мозг программиста - если есть API и написанно не использовать - оно туже будет внедренно в ядро всех либ и компонентов... вспоминаем React router

Null нужно выпиливать на уровне языка

)

если императивщика спросить чем заменить NULL, то он скорее всего не сможет ответить

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

а какое-нибудь процессирование задач на node

очень удобно

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

видимо, мне нужно цайкл перечитать, какие-то новые слова появились :)

недостаток, что нужны более высоуровневые абстракции

типа redux - который по сути там реализуется в пару строк

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

самое главное в cycle - уже сразу говая архитектура/инфраструктуа для динамической обарботки сигналов

и четкое разделение ответственности между логикой и эффектами

кстати, тестирвание очень удобно, тестируете только логику - а это соответсвие выходных сигналов входным

не надо никаких особых моков

точно то же самое можно и про реакт сказать

можно, реакт мнее унивесальная штука это чисто DOM

и это хорошо

вот в штальца почему-то больше верится чем в элм

заряженный он какой-то

когда у тебя появляются всякие эффекты доп типа звук и прочее, тут появляются приемущества у более общей архитектуры

главное что cycle - это очень простая штука

реально

и для того, чтобы эффекты подключить нужные не нужно особо ничего

что у него порог вхождения ниже чем в реакт — это точно

обвязка - превращение какой-то либы в драйвер делается довольно просто всегда

рили?

в cycle&

нет не ниже)

конечно не ниже

т.к. ттут потоки

сразу еж

и плюс к отму нет нормальных описанных практик как делать можно и как нельзя

просто cycle 100 строк кода

причём из-за RX у тебя сразу покрывается куча кейсов из-за которых в реакте и редаксе ты будешь велосипедить

и в итоге новый программист придет на проект с сайклом и сделает кучу маленьких говносайклов и событийный ад

и в итоге новый программист придет на проект с сайклом и сделает кучу маленьких говносайклов и событийный ад

зато все это в рамках универсальной композируемо архитектуры

и унивесальных инфраструктурных методов (rx)

например

то же самое с реактом можно

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

реакт для DOM

исправить не факт что легче

а вот другие эффекты подключать - тоже каша может начаться

реакт для дом, но ничего не мешает юзать rxjs

(я и юзаю)

кстати, по идее можно думаю было написать react driver для cycle

и это работало бы как типа в recompose

только в рамках cycle

не думаю, что это было бы полезно. вообще там можно jsx заюзать

в сайкле

я не люблю jsx

мне кажется hyperscript значительно более чистым и композируемым

а реакт компоненты там и не нужны

и события реактовые тоже

это да

поэтому особо нет смысла, ну разве что хуки

так что подключение jsx имеет смысл, а реакта не особо

didMount и прочее

кстати вот был вопрос поо повод jquery

там та же самая ситуация что и в react

абсолютно

вообще snabbdom это более легкий реакт, с богатым API

нет

чем нет?

апи у снаббдома менее богатое

ну так а нафига оно большое?

https://github.com/paldepind/snabbdom#hooks

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

все события нужные есть

и чтобы свои компоненты на нем построить придется чушь писать

да, там все нужное есть

но апи не такое удобное как у реакта

чем?

тем, что оно “менее богатое” (выше ты это плюсом снаббдома называл, а потом “ну и нафиг оно нужно богатое”)

и про апдейты я выше писал

я имел ввиду больше в сравнении с другими vdom

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

типа virtual-dom с убогим API

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

не, ну я по факту знаю, в virtual-dom не хватало нормально управления циклом жизни элемента