Comments 64
Очень неоднозначный фреймворк…
На хабре было уже как минимум 3 introduction статьи про метеор
А сложно ли с него слезть? Вот понаписал я что-то по-быстрому в качестве прототипа. А потом решил сменить среду, много ли мне придется понаписать, чтобы оторваться от зависимостей Meteor JS?
>>>Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
пффф
пффф
. Вместе эти два свойства позволяет вам творить магию: связывать куски шаблонов с данными. При этом, как только данные изменились кусок шаблона заново рендерится и клиент получает актуальное состояние вашего приложения, тогда как вы не написали ни одной лишней строчки.
Knockout.js с понтами и дифирамбами.
Вот кстати было бы интересно посмотреть, как это реализовано у них внутри, и сравнить с нокаутом.
Как известно, браузер начинает давать немалые тормоза, если модель в knockout большая, а шаблон, который нужно отобразить содержит внушительное количество связей с observables. Может быть, товарищи в meteor смогли справиться с этой задачей?
Как известно, браузер начинает давать немалые тормоза, если модель в knockout большая, а шаблон, который нужно отобразить содержит внушительное количество связей с observables. Может быть, товарищи в meteor смогли справиться с этой задачей?
А как бы они это могли сделать? Рендер куска страницы дело вообще небыстрое, так что в большом шаблоне хочешь-не хочешь, а придётся погонять процессор.
Но даже если и можно придумать какой-то обходной путь, сомневаюсь, что на данном этапе они этим вопросом сильно занимались.
Но даже если и можно придумать какой-то обходной путь, сомневаюсь, что на данном этапе они этим вопросом сильно занимались.
Ну как… как и всё, что делается быстрее. Проводятся сравнительные анализы, и — вот результат.
Надуманный пример: что проще: удалить ноду и вставить новую или обращаться к ее innerHTML? А если 10 000 раз? Думаю, таких примеров можно придумать много. Остаётся их комбинировать и jsperf.com.
Ну и не забывайте, что мы с вами про JavaScript говорим — под капотом всё не так просто :)
Надуманный пример: что проще: удалить ноду и вставить новую или обращаться к ее innerHTML? А если 10 000 раз? Думаю, таких примеров можно придумать много. Остаётся их комбинировать и jsperf.com.
Ну и не забывайте, что мы с вами про JavaScript говорим — под капотом всё не так просто :)
мне кажется их даже сравнивать не правильно, и в начале я попытался это объяснить.
А что неправильно? Для Нокаута уже сто лет в обед как есть плагин для синхронизации всего и вся — а в этом как раз и есть основная «фишечка» метеора. Причем на Нокауте это не сделано в ущерб всему остальному. И Нокаут — не единственный в этом роде. Синхронизация есть и для Backbone, и для Angular, и это только те, про кого я могу навскидку сказать.
Кроме того есть вообще такая штука: parse.com — это полный бекенд для вашего приложения. Там есть storage, user management, server-side JS, push notifications. Они в основном позиционироуют этот продукт как серверную платформу для мобильных приложений, но у них также есть и полниценный JS SDK для приложений в браузере. Есть фришная квота, вполне преемлимая, слезть с них при случае будет не сложно. Причем, в отличие от этого Метеора, который появился невесть откуда и пропал на полгода, эти ребята — устойчивый и приносящий прибыль бизнес.
Кроме того есть вообще такая штука: parse.com — это полный бекенд для вашего приложения. Там есть storage, user management, server-side JS, push notifications. Они в основном позиционироуют этот продукт как серверную платформу для мобильных приложений, но у них также есть и полниценный JS SDK для приложений в браузере. Есть фришная квота, вполне преемлимая, слезть с них при случае будет не сложно. Причем, в отличие от этого Метеора, который появился невесть откуда и пропал на полгода, эти ребята — устойчивый и приносящий прибыль бизнес.
Окей, вы безусловно правы и оень логичны. У меня закончились аргументы.
Кстати, нашел интересную ссылку в инернете meteor.com/blog/2012/07/25/meteors-new-112-million-development-budget
Аргумент ожидался.
И что? В результате ребята, вместо того, чтобы обкатывать проект на реальном приложении (а-ля Basecamp в случае с Ruby-on-Rails), сидят и пилят его непонятно для кого. У них есть фреймворк, который создается без цели и без «боевого крещения» — ребята просто просиживают денежки в надежде на aquihiring.
Те же авторы Angular рассказывали, как их фреймворк вырос из реального проекта внутри Google, а автор Knockout вообще перерабаотывал его три раза в течение нескольких лет.
И что? В результате ребята, вместо того, чтобы обкатывать проект на реальном приложении (а-ля Basecamp в случае с Ruby-on-Rails), сидят и пилят его непонятно для кого. У них есть фреймворк, который создается без цели и без «боевого крещения» — ребята просто просиживают денежки в надежде на aquihiring.
Те же авторы Angular рассказывали, как их фреймворк вырос из реального проекта внутри Google, а автор Knockout вообще перерабаотывал его три раза в течение нескольких лет.
Не то чтобы mongo плохая БД, но уже не модная.Адский довод. Надо будет в копилку аргументов добавить (сарказм).
Знаете, почему, например, под Unix системы какую-то «модель» можно реализовать очень многими способами? Потому что каждая часть самостоятельная, можно быстро заменить одну другой (в случае неотказоустачивойсти, например).
Насколько просто можно в данном фреймворке одну часть заменить другой?
Насколько просто можно в данном фреймворке одну часть заменить другой?
В одном с прошлых топиков жаловались на то, что он делает POST запрос на бекенд каждую секунду, это исправилось?
Вообще, он с сервером общается через веб-сокеты, если они есть. С фолбэком на AJAX.
А почему на AJAX, а не, скажем, comet?
Ну, сейчас начнётся холивар :) Ребята выбрали сокет, вероятно, оставили вам возможность написать другой транспорт.
А что вы имеете ввиду под comet?
http://en.wikipedia.org/wiki/Comet_(programming)
Бомбить запросы каждую секунду ну как-то уж совсем некрасиво.
Бомбить запросы каждую секунду ну как-то уж совсем некрасиво.
реализация с iframe — это не хорошо, потому что мы занимаем целый коннекшн, для node.js — это очень плохо. То же самое с long-polling. Не забывайте, что мы работаем на одном ядре. А так, WebSockets — это самый правильный Comet, и так.
А с другой стороны, пользователи мобильного интернета, зашедшие браузером который не поддерживает WebSocket'ы просто вас проклянут.
А можно по подробней про nodejs, целый 'коннекшн', WebSocket, одно ядро и почему же всё таки MongoDB 'не модно'.
Meteor(а в целом и nodejs) работает в одном потоке, слышали? Не модно — значит не модно, такое мое субъективное мнение. WebSockets — почитайте тут ru.wikipedia.org/wiki/WebSocket
Спасибо за содержательный ответ.
Nodejs.
Ваш код в nodejs работает в одном потоке. Сам nodejs является отдельным процессом.
Про одно ядро я бы не стал вообще упоминать тут.
Вы улавливаете разницу между потоком, процессом и ядром?
Если да, то пожалуйста расскажите не поленитесь, я думаю
многим будет интересно, мне точно, особенно в контексте
javascript-а.
MongoDB.
Хорошо ваше право считать что MongoDB не модно.
Но хотелось бы услышать альтернативы.
И почему у вас сформировалось такое мнение про MongoDB,
возможно после того как вы опишите те проблемы с которыми
вы столкнулись в MongoDB мне тоже покажется
что это не модно.
WebSocket.
Спасибо за ссылку про WebSocket, прочитал.
Но появились вопросы:
— Что для вас означает 'коннекшн'?
— Как nodejs-у мешает 'коннекшн'?
— Как вас спасает WebSocket от 'коннекшн'-а?
Спасибо.
Nodejs.
Ваш код в nodejs работает в одном потоке. Сам nodejs является отдельным процессом.
Про одно ядро я бы не стал вообще упоминать тут.
Вы улавливаете разницу между потоком, процессом и ядром?
Если да, то пожалуйста расскажите не поленитесь, я думаю
многим будет интересно, мне точно, особенно в контексте
javascript-а.
MongoDB.
Хорошо ваше право считать что MongoDB не модно.
Но хотелось бы услышать альтернативы.
И почему у вас сформировалось такое мнение про MongoDB,
возможно после того как вы опишите те проблемы с которыми
вы столкнулись в MongoDB мне тоже покажется
что это не модно.
WebSocket.
Спасибо за ссылку про WebSocket, прочитал.
Но появились вопросы:
— Что для вас означает 'коннекшн'?
— Как nodejs-у мешает 'коннекшн'?
— Как вас спасает WebSocket от 'коннекшн'-а?
Спасибо.
Node.js использует событийный ввод/вывод (epoll, kqueue, select) и работает на EventLoop и является одним процессом, который может держать большое число соединений за счет снижения накладных расходов.
За всю сессию работы WebSocket поднимает только одно соединение на ввод и вывод в отличии от LongPolling где каждый запрос — новое соединение (новые соединения — это порты, а они кончаются порою быстрее, чем уходит память).
За всю сессию работы WebSocket поднимает только одно соединение на ввод и вывод в отличии от LongPolling где каждый запрос — новое соединение (новые соединения — это порты, а они кончаются порою быстрее, чем уходит память).
Однако, как оказалось, это не решает проблемы, а лишь позволяет программистам, освоившим это дао, ехидно посмеиваясь, отправлять своим коллегам код с предложением проверить и принять пуллреквест.И как же после этого абзаца следует понимать примеры на кофескрипте вместо джаваскрипта? Чувствую,
Пытаюсь евангилизировать потихоньку
(для тех, кто не видел) ссылка на легендарный пуллреквест в nodejs
Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
Что за выводы такие? Манна небесная, что ле этот ваш фреймворк? И как раньше без него приложения делали, даже не знаю. Наверно сейчас они все развалятся.
Что за выводы такие? Манна небесная, что ле этот ваш фреймворк? И как раньше без него приложения делали, даже не знаю. Наверно сейчас они все развалятся.
На мой взгляд knockout, meteor и другие аналогичные фреймворки очень уж сильно пытаются упростить жизнь, дико ее усложняя своими внутренними процессами. Пробовал все, но лучше backbone не нашел – все под контролем программиста, гибко и красиво; жизнь упрощает, но не слишком.
Мне очень грустно, что я не смог донести до аудитории, что meteor — это не про MVC, это про реактивность, а backbone в meteor интегрируется одной командой.
А knockout про что?
Вот тут неплохая статья есть habrahabr.ru/post/124731/
Фреймворков этих наплодилась тьма. Выбрать нужный поможет взгляд на решение одной и той же задачи на каждом из фреймворков. Например, тут: addyosmani.github.com/todomvc/ реализация TODO приложения
Делают гении: meteor.com/about/peopleНе, не слышал.
Если честно я так и не понял, на кой черт эта штука нужна, и что она делает. Это потому что метеор это что-то очень крутое, для очень крутых? Или все причина в другом?
Сплошь из гениев — это, видимо, типа того, но хз, больше похоже на «маркетинг» с целью выбить миллиард на инвестиции из доверчивых вкладчиков (что уже, по-моему, и было сделано).
Сам ни разу не пользовался этим фреймворком, и пока не собираюсь, т.к. в нём нет ничего, что было бы мне нужно (как в твиттере или фейсбуке).
Единственная вещь, которая меня в нём заинтересовала — это вот это: «Вы меняете коллекцию на клиенте и она тут же через веб-сокеты синхронизируется с сервером.»
Как так?
Как они это сделали?
Я продумывал в своё время такую схему на MongoDB, и не пришёл к решению.
Просто решил, что это пока невозможно.
Если у них идеально рабочее решение, и не костыль с багами, то это будет круто.
Исходники их читать неохота, поэтому если кто-то подробно объяснит, в чём состоит алгоритм их чудо-синхронизации — буду благодарен.
Сам ни разу не пользовался этим фреймворком, и пока не собираюсь, т.к. в нём нет ничего, что было бы мне нужно (как в твиттере или фейсбуке).
Единственная вещь, которая меня в нём заинтересовала — это вот это: «Вы меняете коллекцию на клиенте и она тут же через веб-сокеты синхронизируется с сервером.»
Как так?
Как они это сделали?
Я продумывал в своё время такую схему на MongoDB, и не пришёл к решению.
Просто решил, что это пока невозможно.
Если у них идеально рабочее решение, и не костыль с багами, то это будет круто.
Исходники их читать неохота, поэтому если кто-то подробно объяснит, в чём состоит алгоритм их чудо-синхронизации — буду благодарен.
Sign up to leave a comment.
Thinking Reactively. Meteor JS