Thinking Reactively. Meteor JS

[Istergul]

Очень неоднозначный фреймворк…

[Terminal]

Почему же?

[Istergul]

да хотя бы потому что авторы клали на REST.

[Terminal]

А, ну ладно.

[zw0rk]

Еще более неоднозначная преамбула к посту.

[modernstyle]

На хабре было уже как минимум 3 introduction статьи про метеор

[Terminal]

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

[azproduction]

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

[Terminal]

Примерно так же просто как слезть с RoR

[Terminal]

А, если серьезно, то все зависит от кол-ва smart packages, которые вы используете

[greengarlic]

>>>Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
пффф

[qrazydraqon]

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

Knockout.js с понтами и дифирамбами.

[likhter]

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

Как известно, браузер начинает давать немалые тормоза, если модель в knockout большая, а шаблон, который нужно отобразить содержит внушительное количество связей с observables. Может быть, товарищи в meteor смогли справиться с этой задачей?

[qrazydraqon]

А как бы они это могли сделать? Рендер куска страницы дело вообще небыстрое, так что в большом шаблоне хочешь-не хочешь, а придётся погонять процессор.

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

[likhter]

Ну как… как и всё, что делается быстрее. Проводятся сравнительные анализы, и — вот результат.
Надуманный пример: что проще: удалить ноду и вставить новую или обращаться к ее innerHTML? А если 10 000 раз? Думаю, таких примеров можно придумать много. Остаётся их комбинировать и jsperf.com.

Ну и не забывайте, что мы с вами про JavaScript говорим — под капотом всё не так просто :)

[Terminal]

мне кажется их даже сравнивать не правильно, и в начале я попытался это объяснить.

[alist]

А что неправильно? Для Нокаута уже сто лет в обед как есть плагин для синхронизации всего и вся — а в этом как раз и есть основная «фишечка» метеора. Причем на Нокауте это не сделано в ущерб всему остальному. И Нокаут — не единственный в этом роде. Синхронизация есть и для Backbone, и для Angular, и это только те, про кого я могу навскидку сказать.

Кроме того есть вообще такая штука: parse.com — это полный бекенд для вашего приложения. Там есть storage, user management, server-side JS, push notifications. Они в основном позиционироуют этот продукт как серверную платформу для мобильных приложений, но у них также есть и полниценный JS SDK для приложений в браузере. Есть фришная квота, вполне преемлимая, слезть с них при случае будет не сложно. Причем, в отличие от этого Метеора, который появился невесть откуда и пропал на полгода, эти ребята — устойчивый и приносящий прибыль бизнес.

[Terminal]

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

[Terminal]

Кстати, нашел интересную ссылку в инернете meteor.com/blog/2012/07/25/meteors-new-112-million-development-budget

[alist]

Аргумент ожидался.

И что? В результате ребята, вместо того, чтобы обкатывать проект на реальном приложении (а-ля Basecamp в случае с Ruby-on-Rails), сидят и пилят его непонятно для кого. У них есть фреймворк, который создается без цели и без «боевого крещения» — ребята просто просиживают денежки в надежде на aquihiring.

Те же авторы Angular рассказывали, как их фреймворк вырос из реального проекта внутри Google, а автор Knockout вообще перерабаотывал его три раза в течение нескольких лет.

[Terminal]

И это доказывает, что Meteor — ерунда?

[bolk]

Не то чтобы mongo плохая БД, но уже не модная.

Адский довод. Надо будет в копилку аргументов добавить (сарказм).

[Terminal]

Я надеюсь, мой сарказм вы тоже уловили.

[malex]

А какая сейчас модная?

[likhter]

Знаете, почему, например, под Unix системы какую-то «модель» можно реализовать очень многими способами? Потому что каждая часть самостоятельная, можно быстро заменить одну другой (в случае неотказоустачивойсти, например).

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

[Terminal]

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

[likhter]

А что входит у них в ядро?

[Terminal]

github.com/meteor/meteor/tree/master/app/meteor

[AndryX]

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

[Terminal]

Вообще, он с сервером общается через веб-сокеты, если они есть. С фолбэком на AJAX.

[GeorP]

А почему на AJAX, а не, скажем, comet?

[likhter]

Ну, сейчас начнётся холивар :) Ребята выбрали сокет, вероятно, оставили вам возможность написать другой транспорт.

[GeorP]

С сокетами как раз все понятно, вопрос был почему фолбэк на AJAX а не на comet

[likhter]

Ну что вы, в самом деле. Автор топика — не разработчик. На остальное ответ такой:
Ребята выбрали AJAX, оставив вам возможность реализовать через Comet.

[Terminal]

А что вы имеете ввиду под comet?

[GeorP]

http://en.wikipedia.org/wiki/Comet_(programming)
Бомбить запросы каждую секунду ну как-то уж совсем некрасиво.

[Terminal]

реализация с iframe — это не хорошо, потому что мы занимаем целый коннекшн, для node.js — это очень плохо. То же самое с long-polling. Не забывайте, что мы работаем на одном ядре. А так, WebSockets — это самый правильный Comet, и так.

[GeorP]

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

[Terminal]

Пускай часть пользователей будут недовольны, зато сервер будет жить.

[GeorP]

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

[Terminal]

Я говорю о том, что если выбирать между тем, чтобы сервис вообще не работал и тем, чтобы у части пользователей были проблемы (кстати, когда тестил в ie8, никаких неудобств серьезны не заметил), лучше выбрать второй вариант.

[GeorP]

Либо другой фреймворк ;)

[maksimr]

А можно по подробней про nodejs, целый 'коннекшн', WebSocket, одно ядро и почему же всё таки MongoDB 'не модно'.

[Terminal]

Meteor(а в целом и nodejs) работает в одном потоке, слышали? Не модно — значит не модно, такое мое субъективное мнение. WebSockets — почитайте тут ru.wikipedia.org/wiki/WebSocket

[maksimr]

Спасибо за содержательный ответ.

Nodejs.
Ваш код в nodejs работает в одном потоке. Сам nodejs является отдельным процессом.
Про одно ядро я бы не стал вообще упоминать тут.

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

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

WebSocket.
Спасибо за ссылку про WebSocket, прочитал.
Но появились вопросы:
— Что для вас означает 'коннекшн'?
— Как nodejs-у мешает 'коннекшн'?
— Как вас спасает WebSocket от 'коннекшн'-а?

Спасибо.

[azproduction]

Node.js использует событийный ввод/вывод (epoll, kqueue, select) и работает на EventLoop и является одним процессом, который может держать большое число соединений за счет снижения накладных расходов.

За всю сессию работы WebSocket поднимает только одно соединение на ввод и вывод в отличии от LongPolling где каждый запрос — новое соединение (новые соединения — это порты, а они кончаются порою быстрее, чем уходит память).

[seriyPS]

Насчет того, что LongPolling на каждый запрос создаёт новое TCP соединение — далеко не факт. man keep-alive, как говорится.
Насчет того, что новые соединения это новые порты — это вы о чём вообще???

[Mithgol]

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

И как же после этого абзаца следует понимать примеры на кофескрипте вместо джаваскрипта? Чувствую, что Terminal похихикал злоехидно.

[Terminal]

Пытаюсь евангилизировать потихоньку

[Lockal]

(для тех, кто не видел) ссылка на легендарный пуллреквест в nodejs

[NekR]

Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.

Что за выводы такие? Манна небесная, что ле этот ваш фреймворк? И как раньше без него приложения делали, даже не знаю. Наверно сейчас они все развалятся.

[maxmert]

На мой взгляд knockout, meteor и другие аналогичные фреймворки очень уж сильно пытаются упростить жизнь, дико ее усложняя своими внутренними процессами. Пробовал все, но лучше backbone не нашел – все под контролем программиста, гибко и красиво; жизнь упрощает, но не слишком.

[Terminal]

Мне очень грустно, что я не смог донести до аудитории, что meteor — это не про MVC, это про реактивность, а backbone в meteor интегрируется одной командой.

[Infernal]

А knockout про что?

[Terminal]

Вот тут неплохая статья есть habrahabr.ru/post/124731/

[Sirian]

Фреймворков этих наплодилась тьма. Выбрать нужный поможет взгляд на решение одной и той же задачи на каждом из фреймворков. Например, тут: addyosmani.github.com/todomvc/ реализация TODO приложения

[Sannis]

Делают гении: meteor.com/about/people

Не, не слышал.

[Terminal]

Вы правы, это объективный показатель.

[leMar]

Если честно я так и не понял, на кой черт эта штука нужна, и что она делает. Это потому что метеор это что-то очень крутое, для очень крутых? Или все причина в другом?

[Terminal]

Возможны оба варианта.

[cachealot]

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

я хотелось бы побольше живых примеров.

[Terminal]

в следующей статье будет живой пример

[kuchumovn]

Сплошь из гениев — это, видимо, типа того, но хз, больше похоже на «маркетинг» с целью выбить миллиард на инвестиции из доверчивых вкладчиков (что уже, по-моему, и было сделано).

Сам ни разу не пользовался этим фреймворком, и пока не собираюсь, т.к. в нём нет ничего, что было бы мне нужно (как в твиттере или фейсбуке).

Единственная вещь, которая меня в нём заинтересовала — это вот это: «Вы меняете коллекцию на клиенте и она тут же через веб-сокеты синхронизируется с сервером.»

Как так?
Как они это сделали?

Я продумывал в своё время такую схему на MongoDB, и не пришёл к решению.
Просто решил, что это пока невозможно.
Если у них идеально рабочее решение, и не костыль с багами, то это будет круто.
Исходники их читать неохота, поэтому если кто-то подробно объяснит, в чём состоит алгоритм их чудо-синхронизации — буду благодарен.