Pull to refresh

Comments 31

Вот вы бы хоть немного написали о том, что это за фреймворк, какие плюсы и минусы и порадовали новой версией. А так, вы принуждаете идти в поиск. Лень штука хорошая, но все должно быть в меру…
Лень автора vs Лень тысяч просмотревших
<кэп>
Наша должна пересилить путём минусования статьи или плюсования первого комментария, дабы склонить автора к правильному решению
</кэп>
Бесплатно доступна книга Discover Meteor

Бесплатно доступна Starter Edition. Обычная стоит $30, Full edition $70
book.discovermeteor.com/chapter/github — отсюда начинаются платные главы, т.е. бесплатных там четыре главы включая введение.

Вот я все хочу попробовать, но никак не могу побороть ощущение, что это такая «вещь в себе»
Был очень удивлен, когда узнал сколько они нашли денег на разработку
Переодически попадался на глаза еще до того как плотно сел за node.js, но руки все не доходили.
Сейчас ознакомился с довольно краткой вводной в wiki и «принципами» из документации, вроде довольно интересная вещь и как следнует из вики в каком-то виде использует ресурс node.js.
Коллеги, если у вас найдется время и желание не могли бы вы буквально «в двух словах» о нем рассказать, в первую очередь в со стороны node.js + socket.io(?)? В чем именно он не node.js и в чем его преимущество в зависимости от сферы применения?
«Из коробки» реактивность и data-binding — если данные в базе меняются, страницы (блоки), которые связаны с этими данными перерисовываются.

Использует свой пакетный менеджер (уже третий по счёту, по-моему), пакетов уже довольно много.

Годится для быстрого прототипирования.
Годится для быстрого прототипирования.

А для продакшена, если не годится то из-за стабильности работы, стабильности изменений(обратная совместимость и «устоявшийся» ядро) или по другим причинам?

Использует свой пакетный менеджер

Опять велосипед?
А для продакшена, если не годится то из-за стабильности работы, стабильности изменений(обратная совместимость и «устоявшийся» ядро) или по другим причинам?

Я бы не рекомендовал. Хотя, может, с релизом всё будет постабильнее.

Опять велосипед?

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

Опять велосипед?

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

Пока этого не будет о продакшене полноценном не может идти и речи.

где использовать пакет

Хм, интересная фитча, то есть как я понимаю в теории можно все приложение собрать допустим на стороне клиента, а потом в зависимости от неких предпочтений/обстоятельств неким образом безболезненно распределить?
Хм, интересная фитча, то есть как я понимаю в теории можно все приложение собрать допустим на стороне клиента, а потом в зависимости от неких предпочтений/обстоятельств неким образом безболезненно распределить?

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

Достаточно пощупать их коллекции что бы проникнуться. Всю бизнес логику модели можно описать в общей директории, а потом как на клиенте так и на сервере использовать это без ограничений, вплоть до запросов в бд с клиента.
Кстати про запросы к бд с клиента, я как бы был всегда противником подобных решений в плане безопасности, серверная прослойка(написанная не кривыми руками), по моему мнения, всегда надежнее, чем прямые обращения.
Как у них обстоит дело с этим аспектом?
Без проблем, простыми правилами можно описать политики доступа к данным.
upd.
Также с помощью дополнительных пакетов можно контролировать чуть ли не каждое поле.

И на крайний случай можно вообще запретить, например, все запросы на изменение данных, а вместо этого сделать серверные методы.
Я примерно про подобный подход и думал. Спасибо за ваш ответ.
Full-stack фреймворк — это хорошо, но по-моему для его кастомизации на реальном среднем или крупном проекте уйдёт очень много сил (больше или очень сравнимо, чем писать с нуля)
Он достаточно просто кастомизируется (если не пытаться менять основные его вещи, типа работы через монгу и т.п.).
Не подскажете, можно ли его использовать вместе с Сordova на телефончиках? Спасибо.
Он это из коробки умеет. Посмотрите на их сайте пример с localmarket
Спасибо, последний раз когда я смотрел — он не умел.
Все ради ionic. Пока это лучшее что я смог найти из mobile web ui.
Кстати ребята, которые сделали Ionic Framework, до него делали такие штуки как Codiqa и Jetstrap. Правда после того как подняли $1M на Ionic похоже на эти проекты подзабили и даже убрали ссылки на них со своего сайта. А теперь у них еще Ionic Creator и Ionic IO, т.е. прощай Codiqa. В вообще да, ребята умеют делать продукты и Ionic о
Я пока отложу знакомство с Meteor; это оттого, что он «из коробки» не поддерживает Windows.
Sign up to leave a comment.

Articles