Knockout — в первую очередь это View. Meteor — цельный фреймфорк. В knockout повсюду торчат Observable. C Meteor / jin не работал, деталей не знаю. Сильно много «реактивно» на Knockout не попишешь — не хватает доступных методов для работы с observable — filter/combineLatest/flatMap. Да и по виду код Knockout очень слабо похож на bacon/rx/kefir — мало в нем реактивного.
По excel. Не совсем понятно условие «любое изменение не пересчитывает всю таблицу». Возможно имеется в виду ситуация, когда значение в зависимой ячейке изменилось на такое же? Для этого есть методы distinct / distinctUntilChanged, которые откидывают повторные значения (более тонкую разницу можно увидеть сравнив диаграмы или почитав http://reactivex.io/documentation/operators/distinct.html
А вот слова при «кривоватость» библиотеки настораживают… В чем кривость-то? На данный момент у RxJS самое обширное АПИ по работе с Observable.
Понятно, но не ёмко. Если так разворачивать каждое понятие, то получится простыня, которую понять еще сложнее будет. И так тема для многих сложная, поэтому кое-где приходилось идти на упрощения, которые вы и заметили.
вопрос: как из этого определения вытекает «вместо обработки событий по одному объединяешь их в поток и затем работаешь уже только с ним»?
Моё определение вытекло вовсе не из приведенного вами. Считайте это «js фронт-енд» квинтэссенцией всех определений о реактивном программировании. Вы сами обратили внимание на количество вариантов. Мы даже xkcd вставили в статью, чтобы не воспринимали это определение как единственно верное.
А есть где-нибудь how-to? Вот есть квартира, с обычной проводкой, выключателями, люстрами. Что нужно купить, чтоб завести управление светом, розетками и пр. на этот модуль?
Буквально пару таких примеров, со списком необходимого оборудования здорово бы облегчило понимание концепции. Пока что, для меня, потенциального пользователя, слишком много вопросов. Вы же знаете, в наше время покупатели обленились, хотят чтоб всё просто было. А тут вы их еще и Хоп! — примеры конфигов для конкретных сетапов.
Хвалить — достаточно просто и интуитивно понятно. Гораздо сложнее — уметь «отругать» так, чтобы человек не обиделся, понял свою ошибку и не повторял ее. По-моему, именно в принятии критики люди отличаются больше всего.
Короче, жду статью о том, как правильно критиковать :)
Обещают же 2 года после выхода версии 2 продолжать поддержку версии один. Это учитывая еще, что до релиза второй версии минимум год. Итого — три года развития текущей ветки. Вполне хватит. Что было три года назад?
Рассматривайте мой комментарий как комментарий в защиту полноценных фреймворков. Ember сюда так же подходит, но, как мне кажется, у него рамки «слабее» и наработанное комьюнити поменьше.
P.S. Кстати, framework — рамка-работа. Всё сходится :)
Вставлю несколько слов о «жестких рамках» в которые нас вставляет Ангуляр. Когда-то одна команда встала перед выбором — что взять для нового проекта? Потенциально большого. Решили — в интернете полно решений для всего:
нужны модули? require.js
нужны роуты? Crossroads.js
нужны темплейты? underscore.templates
нужны тесты? mocha+chai
И всё шло хорошо. Пока в команде было 2 разработчика. Было много code review, всё писалось в едином стиле. Но вот появляется новый разработчик. Он пишет немного по другому. Потом четвертый. Теперь все пишут по-своему.
Это первая проблема — когда рамки в проекте держатся только на code review и уровне программиста.
А вот вторая проблема — появляется новый программист. Совершенно новый. Теперь ему надо въезжать во все эти велосипеды. В случае, если б это был Ангуляр, HR отдел бы искал js-angular программиста и он бы въехал в проект гораздо быстрее.
Почему не обычная web страница с печатью в pdf?
https://developer.chrome.com/blog/headless-chrome/#create-a-pdf
https://blog.grio.com/2020/08/understanding-pdf-generation-with-headless-chrome.html
https://geektimes.ru/post/113497/
http://www.sciencedirect.com/science/article/pii/S1877042812042905
Вдруг поможет )
По excel. Не совсем понятно условие «любое изменение не пересчитывает всю таблицу». Возможно имеется в виду ситуация, когда значение в зависимой ячейке изменилось на такое же? Для этого есть методы distinct / distinctUntilChanged, которые откидывают повторные значения (более тонкую разницу можно увидеть сравнив диаграмы или почитав http://reactivex.io/documentation/operators/distinct.html
А вот слова при «кривоватость» библиотеки настораживают… В чем кривость-то? На данный момент у RxJS самое обширное АПИ по работе с Observable.
Моё определение вытекло вовсе не из приведенного вами. Считайте это «js фронт-енд» квинтэссенцией всех определений о реактивном программировании. Вы сами обратили внимание на количество вариантов. Мы даже xkcd вставили в статью, чтобы не воспринимали это определение как единственно верное.
Буквально пару таких примеров, со списком необходимого оборудования здорово бы облегчило понимание концепции. Пока что, для меня, потенциального пользователя, слишком много вопросов. Вы же знаете, в наше время покупатели обленились, хотят чтоб всё просто было. А тут вы их еще и Хоп! — примеры конфигов для конкретных сетапов.
Короче, жду статью о том, как правильно критиковать :)
P.S. Кстати, framework — рамка-работа. Всё сходится :)
И всё шло хорошо. Пока в команде было 2 разработчика. Было много code review, всё писалось в едином стиле. Но вот появляется новый разработчик. Он пишет немного по другому. Потом четвертый. Теперь все пишут по-своему.
Это первая проблема — когда рамки в проекте держатся только на code review и уровне программиста.
А вот вторая проблема — появляется новый программист. Совершенно новый. Теперь ему надо въезжать во все эти велосипеды. В случае, если б это был Ангуляр, HR отдел бы искал js-angular программиста и он бы въехал в проект гораздо быстрее.