Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 64

Очень неоднозначный фреймворк…
Всего голосов 10: ↑7 и ↓3+4
Почему же?
Всего голосов 3: ↑1 и ↓2-1
да хотя бы потому что авторы клали на REST.
Всего голосов 3: ↑2 и ↓1+1
А, ну ладно.
Всего голосов 4: ↑1 и ↓3-2
Еще более неоднозначная преамбула к посту.
Всего голосов 1: ↑0 и ↓1-1
На хабре было уже как минимум 3 introduction статьи про метеор
Всего голосов 2: ↑2 и ↓0+2
А можно статью на хабре, где не просто перевод главной страницы или анонс новой версии? Я пользовался поиском, но ничего не нашел?
Всего голосов 1: ↑1 и ↓0+1
А сложно ли с него слезть? Вот понаписал я что-то по-быстрому в качестве прототипа. А потом решил сменить среду, много ли мне придется понаписать, чтобы оторваться от зависимостей Meteor JS?
Всего голосов 8: ↑8 и ↓0+8
Примерно так же просто как слезть с RoR
Всего голосов 7: ↑7 и ↓0+7
А, если серьезно, то все зависит от кол-ва smart packages, которые вы используете
Всего голосов 1: ↑0 и ↓1-1
>>>Если вы еще не слышали про meteor, значит вы вообще не следите за миром JavaScript, не интересуетесь вебом и непонятно каким образом сюда попали.
пффф
Всего голосов 38: ↑33 и ↓5+28
. Вместе эти два свойства позволяет вам творить магию: связывать куски шаблонов с данными. При этом, как только данные изменились кусок шаблона заново рендерится и клиент получает актуальное состояние вашего приложения, тогда как вы не написали ни одной лишней строчки.

Knockout.js с понтами и дифирамбами.
Всего голосов 4: ↑3 и ↓1+2
Вот кстати было бы интересно посмотреть, как это реализовано у них внутри, и сравнить с нокаутом.

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

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

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

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

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

Те же авторы Angular рассказывали, как их фреймворк вырос из реального проекта внутри Google, а автор Knockout вообще перерабаотывал его три раза в течение нескольких лет.
Всего голосов 1: ↑1 и ↓0+1
И это доказывает, что Meteor — ерунда?
Всего голосов 1: ↑0 и ↓1-1
Не то чтобы mongo плохая БД, но уже не модная.
Адский довод. Надо будет в копилку аргументов добавить (сарказм).
Всего голосов 18: ↑16 и ↓2+14
Я надеюсь, мой сарказм вы тоже уловили.
Всего голосов 3: ↑2 и ↓1+1
А какая сейчас модная?
Комментарий пока не оценивали0
Знаете, почему, например, под Unix системы какую-то «модель» можно реализовать очень многими способами? Потому что каждая часть самостоятельная, можно быстро заменить одну другой (в случае неотказоустачивойсти, например).

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

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

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

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

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

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

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

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

я хотелось бы побольше живых примеров.
Всего голосов 1: ↑1 и ↓0+1
в следующей статье будет живой пример
Всего голосов 2: ↑1 и ↓10
НЛО прилетело и опубликовало эту надпись здесь
Сплошь из гениев — это, видимо, типа того, но хз, больше похоже на «маркетинг» с целью выбить миллиард на инвестиции из доверчивых вкладчиков (что уже, по-моему, и было сделано).

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

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

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

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

Публикации

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr