Pull to refresh

Comments 64

да хотя бы потому что авторы клали на REST.
Еще более неоднозначная преамбула к посту.
На хабре было уже как минимум 3 introduction статьи про метеор
А можно статью на хабре, где не просто перевод главной страницы или анонс новой версии? Я пользовался поиском, но ничего не нашел?
А сложно ли с него слезть? Вот понаписал я что-то по-быстрому в качестве прототипа. А потом решил сменить среду, много ли мне придется понаписать, чтобы оторваться от зависимостей Meteor JS?
Примерно так же просто как слезть с RoR
А, если серьезно, то все зависит от кол-ва smart packages, которые вы используете
>>>Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
пффф
. Вместе эти два свойства позволяет вам творить магию: связывать куски шаблонов с данными. При этом, как только данные изменились кусок шаблона заново рендерится и клиент получает актуальное состояние вашего приложения, тогда как вы не написали ни одной лишней строчки.

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

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

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

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

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

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

Те же авторы Angular рассказывали, как их фреймворк вырос из реального проекта внутри Google, а автор Knockout вообще перерабаотывал его три раза в течение нескольких лет.
И это доказывает, что Meteor — ерунда?
Не то чтобы mongo плохая БД, но уже не модная.
Адский довод. Надо будет в копилку аргументов добавить (сарказм).
Я надеюсь, мой сарказм вы тоже уловили.
А какая сейчас модная?
Знаете, почему, например, под Unix системы какую-то «модель» можно реализовать очень многими способами? Потому что каждая часть самостоятельная, можно быстро заменить одну другой (в случае неотказоустачивойсти, например).

Насколько просто можно в данном фреймворке одну часть заменить другой?
У авторов изначальо стояла задача максимально облегчить ядро фрэймворка, поэтому если вы заглянете в их репозиторий, то увидите, что основной код находится в в packages, которые можно включать и отключать.
А что входит у них в ядро?
В одном с прошлых топиков жаловались на то, что он делает POST запрос на бекенд каждую секунду, это исправилось?
Вообще, он с сервером общается через веб-сокеты, если они есть. С фолбэком на AJAX.
А почему на AJAX, а не, скажем, comet?
Ну, сейчас начнётся холивар :) Ребята выбрали сокет, вероятно, оставили вам возможность написать другой транспорт.
С сокетами как раз все понятно, вопрос был почему фолбэк на AJAX а не на comet
Ну что вы, в самом деле. Автор топика — не разработчик. На остальное ответ такой:
Ребята выбрали AJAX, оставив вам возможность реализовать через Comet.
А что вы имеете ввиду под comet?
реализация с iframe — это не хорошо, потому что мы занимаем целый коннекшн, для node.js — это очень плохо. То же самое с long-polling. Не забывайте, что мы работаем на одном ядре. А так, WebSockets — это самый правильный Comet, и так.
А с другой стороны, пользователи мобильного интернета, зашедшие браузером который не поддерживает WebSocket'ы просто вас проклянут.
Пускай часть пользователей будут недовольны, зато сервер будет жить.
Отличный подход: переложить проблемы на пользователей, ли ж бы нам было хорошо :)
Ничего личного, но я считаю такую концепцию ущербной.
Остается молится о скором вымирании старых браузеров.
Я говорю о том, что если выбирать между тем, чтобы сервис вообще не работал и тем, чтобы у части пользователей были проблемы (кстати, когда тестил в ie8, никаких неудобств серьезны не заметил), лучше выбрать второй вариант.
Либо другой фреймворк ;)
А можно по подробней про nodejs, целый 'коннекшн', WebSocket, одно ядро и почему же всё таки MongoDB 'не модно'.
Спасибо за содержательный ответ.

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

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

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

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

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

За всю сессию работы WebSocket поднимает только одно соединение на ввод и вывод в отличии от LongPolling где каждый запрос — новое соединение (новые соединения — это порты, а они кончаются порою быстрее, чем уходит память).
Насчет того, что LongPolling на каждый запрос создаёт новое TCP соединение — далеко не факт. man keep-alive, как говорится.
Насчет того, что новые соединения это новые порты — это вы о чём вообще???
Однако, как оказалось, это не решает проблемы, а лишь позволяет программистам, освоившим это дао, ехидно посмеиваясь, отправлять своим коллегам код с предложением проверить и принять пуллреквест.
И как же после этого абзаца следует понимать примеры на кофескрипте вместо джаваскрипта? Чувствую, что Terminal похихикал злоехидно.
Пытаюсь евангилизировать потихоньку
Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.

Что за выводы такие? Манна небесная, что ле этот ваш фреймворк? И как раньше без него приложения делали, даже не знаю. Наверно сейчас они все развалятся.
На мой взгляд knockout, meteor и другие аналогичные фреймворки очень уж сильно пытаются упростить жизнь, дико ее усложняя своими внутренними процессами. Пробовал все, но лучше backbone не нашел – все под контролем программиста, гибко и красиво; жизнь упрощает, но не слишком.
Мне очень грустно, что я не смог донести до аудитории, что meteor — это не про MVC, это про реактивность, а backbone в meteor интегрируется одной командой.
Фреймворков этих наплодилась тьма. Выбрать нужный поможет взгляд на решение одной и той же задачи на каждом из фреймворков. Например, тут: addyosmani.github.com/todomvc/ реализация TODO приложения
Вы правы, это объективный показатель.
Если честно я так и не понял, на кой черт эта штука нужна, и что она делает. Это потому что метеор это что-то очень крутое, для очень крутых? Или все причина в другом?
Вот я тоже прочитал, и понял что это типа что такое, после изучения которого можно будет не боясь ходить в темном переулке и рассказывать какой я крутой)

я хотелось бы побольше живых примеров.
в следующей статье будет живой пример
UFO just landed and posted this here
Сплошь из гениев — это, видимо, типа того, но хз, больше похоже на «маркетинг» с целью выбить миллиард на инвестиции из доверчивых вкладчиков (что уже, по-моему, и было сделано).

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

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

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

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

Articles