Александр Прозоров

Вам нужно сделать API, которое будет отдавать определенное кол-во записей. Поясню: вам нужно сделать backend, так сказать. Можно написать на node.js / php / python / и т.д. Возможно, есть какой-то готовый сервис для подобных вещей, но я не искал.

Например: GET запрос на api/loadjson?limit=100&offset=0 (выдай 100, отступ 0, потом будет запрос выдай 100 - отступ 100, выдай 100 отступ 200 и тд), т.е. в теории дело обстоит так: вы загружаете первые N записей и устанавливаете обработчик на window.onscroll (пример тут), далее выбираете через какой интервал в пикселях вы планируете подгружать еще и загружаете еще N записей и так далее.

Подгрузку осуществляете с помощью xhr (или, если угодно - ajax) запросов (мне нравится isomorphic-fetch)

Из готовых компонентов, рекомендую react-virtualized. Настройка сперва выглядит трудновато, но это одна из лучших библиотек в плане документации, которую я видел. Есть все! На всякий случай - gitter чат, где есть и сам разработчик (язык EN).

просто бывают такие люди, которые в этот автозапускаемый файл пихают трояна...

Никак.

Вам нужен слушательль на отправку формы.

[].forEach.call(document.querySelectorAll("form"), function(e)
{
    e.addEventListener("submit", function() 
    { 
        this.removeAttr('target');
    });
});

В двух словах: для всех форм на странице добавляется событие при подтверждении.

Не согласен с предыдущим оратором (@geeek), в частности с утверждением

В общем если хочешь быть в тренде - бери

- Meteor совсем не в тренде.

Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.

Docker хоть 50 запускай.

настройка express-subdomain

Как понять что стоит использовать MongoDB?

Алгоритм очень прост:

1. Уяснить, чем Mongo отличается от обычных реляционных БД, какие у неё сильные и слабые стороны.
   
2. Сформулировать требования, которые диктует текущая задача.
   
3. Оценить, насколько Mongo удовлетворяет этим требованиям.
   
4. Если удовлетворяет в достаточной степени - использовать. Иначе - не использовать.
   

Внимательный читатель может заметить, что если в этом алгоритме заменить Mongo на %любой инструмент%, а реляционные БД на %любой другой инструмент%, то этот алгоритм становится Универсальным Алгоритмом Выбора Инструмента. Ещё более внимательный читатель может заметить, что УАВИ применим к абсолютно любой человеческой деятельности.

P.S. Вчера на DUMP Олег Бунин сказал, что не встречал ни одной задачи, где бы необходимо было использовать NoSQL БД. Некоторые люди ему бурно апплодировали.