Comments 14
Про Babel обманка, здесь у вас включен regenerator, который не очень нужен, если используется firefox > 45 или chrome > 50
Также async/await, генераторы, Promise входят в стандарт ECMAScript, и даже самый передовой async/await доступен в Node 7 и Chrome 55
А сколько кода придется писать, что бы впихнуть $mol_object в React, Vue, Angular2 и т.д.?
Лучше пускай будет +10 строчек читабельного boilerplate-кода, чем какое-нибудь скрытое непонятное нечто
Асинхронность не выпячивается наружу, а инкапсулируется внутри асинхронных модулей, делая работу с ней простой и приятной.
Не инкапсулируется, а прячется за конкретной реализацией, применимой в конкретных ситуациях, каков процент этих ситуаций?
Мало того, binding к VanilaJS становится просто невозможным (попросту не используются стандартные интерфейсы), а значит мы обязаны писать всю логику внутри и средствами $mol и возникает логичный вопрос: а зачем нам, в таком случае, бороться с JavaScript, если мы все равно пользуемся новым языком?
Начало с рассказом про атомы интересное, а вот наезды на разработчиков, не пользующихся $mol_mem странные.
Всегда можно использовать lodash.memoize или @memoize декоратор, ничего уникального здесь я не вижу
Вроде идея интересная. Что-там даже мелькает в плане сравнения с другими реализациями… Но вот метод подачи материала… Я даже не знаю как это назвать. Куча какого-то непонятного кода, куча каких-то умных фраз. Большинство текста видимо можно понять только изучив гору каких-то книг, и перековыряв внутренности других библиотек.
Что это за примеры кода? На чём они вообще написаны? Это не чистый JavaScript. TypeScript? Dart? Вы хоть объясните, на чём вы пишете свои примеры. Объясните как работают методы вашей библиотеки. Объясните что это вообще за атомы, о которых вы постоянно говорите.
Почему зарубежные авторы всегда умудряются писать ясный и простой для понимания текст, который даже после перевода приятно читать? Почему-то статьи российских разработчиков всегда ярко выделяются тем, что они пишут какую-то заумную фигню, понятную только небольшому узкому кругу таких же просвящённых, как и они сами. Они как-будто ленятся написать действительно понятную статью. Разложить по полочкам то, что они хотят донести до других. Вся суть статьи как-будто сводится к примитивному желанию показать свою крутоту и унизить все остальные инженерные решения этого мира. Непонятно за что вам ставить плюс. Непонятно за что вас благодарить. Ибо я до сих пор не понимаю 90% всего, что представляет из себя ваш фреймворк. Непонятно зачем вы вообще пишете все эти статьи.
Вы понимаете, что при таком методе подачи информации, ваш фреймворк всё равно обречён быть среди никому неизвестных аутсайдеров? Пока у вас нет нормальной документации и ясного API, пока библиотеку невозможно понять, никто не будет её использовать, никому она не будет нужна в реальной практике.
Просто смотрю на пример с гитхаба вашей библиотеки:
$my_hello $mol_viewer childs /
< namer $mol_stringer
hint \Name
value > name \
< message \Блин, ну что всё это вообще означает?) Что это за синтаксис? Как с этим работать?) Хватит хотя-бы унижать другие инженерные решения в своих статьях. По крайней мере, они в сотни раз более понятные, чем то, что придумали вы.
У автора есть статья про атомы на хабре, и только она объемнее чем эта ;]
Вы поймите на хабре ровно два человека, которые хоть как-то освещают эту тему, это vintage и Riim, за рубежом вообще никто, если не считать KO (да и то его с этой стороны не рассматривают). И да, у этих ребят есть некоторые проблемы с подачей материала и им вечно сливают карму (а зря, очень зря).
Тема сложная, чтобы её понять, наверно проще самому запрограммировать свой «атом» и пропустить через себя идею. Это не просто очередная «либа», это совсем другой уровень мышления, это не какой-нибудь Rx.
Но как бы спорно она не писали, эти ребята своей работой показывают альтернативное решение, которым практически никто не занимается и лично мне интересно наблюдать за их результатами. Потому что сам я так и не смог приручить реактивность :]
и им вечно сливают карму
Насчёт этого я полностью согласен, что просто так брать и сливать человеку карму, особенно когда он пишет действительно какие-то важные вещи — это что-то из разряда высших степеней невежества.
Тема и правда очень интересная, достаточно взять и написать самому простенькую реализацию атома на 150 строк. Штука безумно интересная для любого UI, сейчас я пытаюсь её "втянуть" в известную концепцию событий и промисов.
Примеры кода, кажется, на обычном ES2016 (или какой там сейчас, уже 2017?) — стрелочные функции, классы, декораторы. Не то чтобы совсем каждодневные фичи, конечно, но и без особой экзотики.
А как решается проблема с событиями. Не любые переходы интерфейса можно описать атомами.
Как, к примеру, будет выглядеть пример с двумя radio button-s? Т.е. есть две кнопки, каждая обернута в двусторонний биндинг atom<boolean>. Как изобразить условие, что при нажатии на свободную кнопку вторая должна быть отключена?
https://jsbin.com/ligibuqayi/1/edit?js,console,output
Открываем консоль, вводим два раза быстро Rest.resource('http://ya.ru')
После второго раза ошибка: "Cyclic atom dependency of Rest.resource(\"http://ya.ru\")"
Сыровато.
"$mol_atom_wait: get google.com
at new $mol_atom_wait (https://eigenmethod.github.io/mol/mem/-/web.js:663:25)
at Function.resource (ligibuqayi.js:42:19)
at $mol_atom.pull (https://eigenmethod.github.io/mol/mem/-/web.js:470:29)
at $mol_atom.actualize (https://eigenmethod.github.io/mol/mem/-/web.js:463:33)
at $mol_atom.get (https://eigenmethod.github.io/mol/mem/-/web.js:426:18)
at $mol_atom.value (https://eigenmethod.github.io/mol/mem/-/web.js:594:29)
at Function.descr.value (https://eigenmethod.github.io/mol/mem/-/web.js:732:29)
at eval (eval at a.eval (https://static.jsbin.com/js/prod/runner-3.40.2.min.js:1:11964), <anonymous>:1:6)
at eval (<anonymous>)
at Object.a.eval (https://static.jsbin.com/js/prod/runner-3.40.2.min.js:1:11964)"
$mol_atom: теория и практика реактивности