Pull to refresh

Comments 31

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