Автомобиль — источник повышенной опасности несмотря на то, кто или что им управляет. Люди, садящиеся в машину, должны понимать это. Соответственно, при прочих равных их и должны пускать в расход. Тем более юридически это можно организовать подписанием пользовательского соглашения.
Возможно, под миграцией исполняемого кода вы понимаете hot code push. Это технология, позволяющая обновлять версию клиентского и серверного приложения прямо во время работы с сохранением состояния клиента. Она в Meteor есть и позиционируется как одна из основных фич, но, я бы сказал, что использовать её надо с большой осторожностью.
Ничего удивительного. Просто надо знать как работает используемая технология. И приоритетом установить избегание конструкций, которые не читаются с первого раза.
По примеру 1. Вы Array.prototype.slice никогда не встречали? Очень распространённый приём в js.
По примеру 2. do в coffeescript принимает функцию аргументом и выполняет её. Поскольку функция передана аргументом, информация о родительском объекте (контексте) теряется. do надо использовать в comprehension'ах для изоляции контекста и/или создания замыканий, а не так как у вас в примере.
Это избавляет от шума (явные импорты и экспорты в каждом файле CommonJS) и упрощает конфигурацию (все зависимости явны и инкапсулированы в одном файле конфигурации). В итоге это просто удобно. Я бы объяснил это естественной эволюцией, ведь npm, bower, yeoman и проч. тоже не сразу появились.
И такую штуку провернуть можно. Для этого нужно сгенерировать клиентский bundle метеором и чем-либо отдавать его клиенту (по идее можно даже через Cloudflare/Cloudfront). Для взаимодействия с клиентской частью сервер должен поддерживать протокол DDP (есть на почти всех языках). Такой абстрактный сервер сможет работать с любой БД. Но насколько это удобно?
Обратное (сервер — Meteor, клиент — абстрактное приложение) тоже возможно, и до появлении поддержки cordov'ы все так и делали с мобильными приложениями. Мы, например, свои мобильные клиенты на cordov'у не перевели и пока не собираемся.
У нас сейчас в разработке самое крупное (или одно из самых) Meteor-приложение. Именно с архитектурными ограничениями пока не столкнулись. Самое главное «ограничение», как я писал выше, — высокий порог входа. Постоянно приходится выгребать за ньюкамерами тонны г.на.
Про фейлы пока не слышал, но первая версия Meteor появилась только на прошлой неделе, так что всё впереди.
Во-первых. На сайте cordov'ы есть страничка /apps, где [смеющиеся] сомневающиеся могут посмотреть на разработанные на текущий момент приложения.
Во-вторых, далеко не всем нужны «сложные» мобильные приложения. Особенно в начале бизнеса. После получения $M инвестиций можно хоть на C++ всё переписать.
В-третьих, посмотрим на это с другой стороны. Интерфейс веба состоит из блоков, собранных из html и css. Пользователям веба этого вполне достаточно. Так почему же пользователям мобильных при адекватном подходе к построению интерфейса будет плохо?
В-четвёртых, унификация кодирования, возможно (и даже вероятно), сделает сложные мобильные приложения проще.
В-пятых, естественно, мы не лезем на поляну сложных графических 2D и 3D приложений. Область применения любой технологии ограничена, и это абсолютно нормально.
Можно, но детали зависят от того, что вы имеете в виду под клиентской частью.
Если клиентская часть — это статический сайт без серверной логики, то да, можно. Просто не пишите серверную логику.
Если клиентская часть — это standalone node.js приложение ничего никому не отдающее, то выключите модуль webapp, являющийся сервером статики. В этом случае у вас получится обычное приложение, запускающееся из консоли и делающее, что надо, например, переименовывающее файлики.
Я понимаю, что вы делаете: вы пытаетесь нащупать слабые места в Meteor, и в результате у нас получается полезный для читателей диалог. Молчаливым минусователям надо брать с вас пример. Теперь по теме.
Резолв зависимостей в Meteor получается двухуровневый. Первый уровень — доставка исходников для приложения — то же, что и npm. Второй уровень, которого стандартный node.js не предствляет, — загрузка модулей в runtime во время старта приложения. То есть, вы можете выделить свой код в модули и явно указать порядок загрузки. Или сделать свой код зависимым от существующих пакетов, и он будет загружен после них.
Bower знаю, пользовал. Но Meteor идёт немного дальше. Как я уже отмечал, пакет Meteor может содержать код сразу всех типов: frontend, backend, cordova. Это открывает совершенно новые возможности упорядочивания логики. Например модуль аутентификации «accounts-google» вставляет гугловскую кнопку в интерфейс приложения, включает css-файл и добавляет клиентскую и серверную логику. Поскольку всё вместе это составляет функционал «логин с гуглом», то всё оно очень хорошо инкапсулируется именно в один пакет, а не разностися по разным модулям.
Meteor в себя включает ровно столько, сколько нужно. Meteor — прослойка, клей, собирающий воедино всё, что есть в мире node.js. Пользователи вольны включать любой существующий или новый функционал. Естественно, чтобы добиться удобства, разработчикам пришлось выразить определённое мнение по поводу организации логики. Я предлагаю считайть это аналогом convention over configuration из всем знакомых (и многоми любимых) рельсов. Кстати с выключением/заменой существующего функционала проблем тоже нет: один из коментаторов отметил, что ему удалось вместо mongo использовать influxdb. В комментах ниже я расскажу о том, что ещё можно отключить.
Я пишу на coffeescript и вам рекомендую. С javascript-ом никогда проблем не было — на любом языке можно устроить такой brainfuck, что мало не покажется. Но это только для jsfiddle. Для продакшена — только в соответствии с Clean Code.
Вы просто не видели динамику развития проекта. Это нечто потрясающее — разработчики регулярно добавляли/удаляли фичи и рефакторили код, выпуская один стабильный (полностью рабочий) релиз в месяц. Критичных багов за год не было, некритичные фиксились за один-два дня. Такой профессиональной работы я ещё не видел. Сомневаюсь, что они затормозят проект. Скорее вы устанете апдейтить своё приложение.
На следующей неделе будет Meteor meetup в Москве. Желающие могут посетить собрание секты и [совершить жертвоприношение] собрать приложение самостоятельно. Вот после этого можно будет обзываться.
Про формат пакетов. Могут ли npm-пакеты включать клиентский и расшаренный код? Что насчёт модулей для Cordov'ы, их тоже можно через npm подключить? А как насчёт автоматического упорядоченного резолва зависимостей? Бросаться фразами легко, вдумчиво читать — несколько сложнее. Литература: www.meteor.com/isobuild
Шаблонизатор основан на Handlebars и модифицирован для лучшей поддержки движка реактивных обновлений Blaze. Синтаксис по большей части такой же. Форк как форк, ничего необычного — весь гитхаб на них держится.
Сборщик решает свои задачи без муторной настройки. Большего от него не требуется. По мне так, это значительно лучше чем Grunt со сложными и нечитаемыми конфигами.
Node.js патченый только для сервера разработки. На хостинге приложение будет работать на самом обычном Node.js.
Все серверные методы и методы коллекций могут принимать callback последним параметром. В этом случае они будут работать в асинхронном стиле. И тут у вас промах.
Протокол DDP у Meteor свой. Он с открытым кодом и хорошо документирован (как и весь Meteor). Не вижу здесь проблем.
Никто не заставляет вас публиковать ваше приложение на meteor.com. Хотите — деплойте сразу на Amazon, DO или ваше собственное железо. Повторюсь — Meteor-приложения — это обычные node.js приложения, к хостингу никак не привязанные.
Может, всё-таки стоит попробоать, вдруг понравится :)
Так вот, самый главный минус Meteor — достаточно высокий порог входа. Несмотря на то что процесс разработки упрощён донельзя, разработчик должен знать приличное количество технологий и библиотек. Javascript, DOM, HTML, CSS, Node.js, JQuery, Cordova, Spacebars, Blaze, Fibers — это только то, что сразу же всплыло в памяти. Плюсом идёт умение программировать, которое — отдельный большой навык.
Необходимость оборачивать библиотеки node.js в пакеты Meteor. Дел, правда, на 5 минут, и пакет можно не публиковать, но всё же. К слову, поиск нужного node.js модуля и изучение его API занимает гораздо больше времени. Да и нативные node.js модули доступны по-умолчанию. Так что минус слабоват. Я объясню, почему нужен свой формат пакетов, в комментариях ниже.
Маловато Meteor-разработчиков. Это скорее минус для бизнеса и плюс для самих разработчиков.
Нет официальной поддержки SQL, всё на mongodb. Для кого-то плюс, для кого-то минус.
Нет официальной поддержки разработки на Windows. Но это тоже слабоватый минус. Всё-таки разработчики должны быть более обучаемыми и гибкими.
Естественно, надо самому смотреть — приемлемы ли данные ограничения или нет.
Вы имеете в виду strong opinion в статье? Да, оно там есть и оно сугубо моё. Но надо ж как-то заинтересовать российское веб-сообщество! Основное отличие от рекламы — в том, что в статье всё правда и ничего не преувеличено. Без фанатизма, в общем.
По примеру 1. Вы Array.prototype.slice никогда не встречали? Очень распространённый приём в js.
По примеру 2. do в coffeescript принимает функцию аргументом и выполняет её. Поскольку функция передана аргументом, информация о родительском объекте (контексте) теряется. do надо использовать в comprehension'ах для изоляции контекста и/или создания замыканий, а не так как у вас в примере.
В копилку ваших приёмов создания констант в js и coffeescript: gist.github.com/eluck/74a5a8f8262d85497ab6
Обратное (сервер — Meteor, клиент — абстрактное приложение) тоже возможно, и до появлении поддержки cordov'ы все так и делали с мобильными приложениями. Мы, например, свои мобильные клиенты на cordov'у не перевели и пока не собираемся.
Про фейлы пока не слышал, но первая версия Meteor появилась только на прошлой неделе, так что всё впереди.
Во-вторых, далеко не всем нужны «сложные» мобильные приложения. Особенно в начале бизнеса. После получения $M инвестиций можно хоть на C++ всё переписать.
В-третьих, посмотрим на это с другой стороны. Интерфейс веба состоит из блоков, собранных из html и css. Пользователям веба этого вполне достаточно. Так почему же пользователям мобильных при адекватном подходе к построению интерфейса будет плохо?
В-четвёртых, унификация кодирования, возможно (и даже вероятно), сделает сложные мобильные приложения проще.
В-пятых, естественно, мы не лезем на поляну сложных графических 2D и 3D приложений. Область применения любой технологии ограничена, и это абсолютно нормально.
Ваши доводы?
Если клиентская часть — это статический сайт без серверной логики, то да, можно. Просто не пишите серверную логику.
Если клиентская часть — это standalone node.js приложение ничего никому не отдающее, то выключите модуль webapp, являющийся сервером статики. В этом случае у вас получится обычное приложение, запускающееся из консоли и делающее, что надо, например, переименовывающее файлики.
Резолв зависимостей в Meteor получается двухуровневый. Первый уровень — доставка исходников для приложения — то же, что и npm. Второй уровень, которого стандартный node.js не предствляет, — загрузка модулей в runtime во время старта приложения. То есть, вы можете выделить свой код в модули и явно указать порядок загрузки. Или сделать свой код зависимым от существующих пакетов, и он будет загружен после них.
Bower знаю, пользовал. Но Meteor идёт немного дальше. Как я уже отмечал, пакет Meteor может содержать код сразу всех типов: frontend, backend, cordova. Это открывает совершенно новые возможности упорядочивания логики. Например модуль аутентификации «accounts-google» вставляет гугловскую кнопку в интерфейс приложения, включает css-файл и добавляет клиентскую и серверную логику. Поскольку всё вместе это составляет функционал «логин с гуглом», то всё оно очень хорошо инкапсулируется именно в один пакет, а не разностися по разным модулям.
Meteor в себя включает ровно столько, сколько нужно. Meteor — прослойка, клей, собирающий воедино всё, что есть в мире node.js. Пользователи вольны включать любой существующий или новый функционал. Естественно, чтобы добиться удобства, разработчикам пришлось выразить определённое мнение по поводу организации логики. Я предлагаю считайть это аналогом convention over configuration из всем знакомых (и многоми любимых) рельсов. Кстати с выключением/заменой существующего функционала проблем тоже нет: один из коментаторов отметил, что ему удалось вместо mongo использовать influxdb. В комментах ниже я расскажу о том, что ещё можно отключить.
Шаблонизатор основан на Handlebars и модифицирован для лучшей поддержки движка реактивных обновлений Blaze. Синтаксис по большей части такой же. Форк как форк, ничего необычного — весь гитхаб на них держится.
Сборщик решает свои задачи без муторной настройки. Большего от него не требуется. По мне так, это значительно лучше чем Grunt со сложными и нечитаемыми конфигами.
Node.js патченый только для сервера разработки. На хостинге приложение будет работать на самом обычном Node.js.
Все серверные методы и методы коллекций могут принимать callback последним параметром. В этом случае они будут работать в асинхронном стиле. И тут у вас промах.
Протокол DDP у Meteor свой. Он с открытым кодом и хорошо документирован (как и весь Meteor). Не вижу здесь проблем.
Никто не заставляет вас публиковать ваше приложение на meteor.com. Хотите — деплойте сразу на Amazon, DO или ваше собственное железо. Повторюсь — Meteor-приложения — это обычные node.js приложения, к хостингу никак не привязанные.
Может, всё-таки стоит попробоать, вдруг понравится :)
Необходимость оборачивать библиотеки node.js в пакеты Meteor. Дел, правда, на 5 минут, и пакет можно не публиковать, но всё же. К слову, поиск нужного node.js модуля и изучение его API занимает гораздо больше времени. Да и нативные node.js модули доступны по-умолчанию. Так что минус слабоват. Я объясню, почему нужен свой формат пакетов, в комментариях ниже.
Маловато Meteor-разработчиков. Это скорее минус для бизнеса и плюс для самих разработчиков.
Нет официальной поддержки SQL, всё на mongodb. Для кого-то плюс, для кого-то минус.
Нет официальной поддержки разработки на Windows. Но это тоже слабоватый минус. Всё-таки разработчики должны быть более обучаемыми и гибкими.
Естественно, надо самому смотреть — приемлемы ли данные ограничения или нет.
Помните про DRY! :)