Комментарии 73
А все-таки выглядит как маркетинговый булшит. Я бы в первую очередь хотел почитать—желательно в самом начале статьи—в чем ключевое отличие meteor от angular или backbone. И вообще, чтоб вся статья была про важные отличия. Потому что список плюшек вообще не привязан к технологии, с тем же успехом почти то же самое можно было написать про angular vs. backbone. Ну и потом более предметное обсуждение хотелось бы видеть, системный какой-то анализ.
Meteor по своей сути — это попытка полностью упорядочить разработку в мире frontend, node.js (а позже и cordov'ы). Те тулзы, которых не хватало, ребята написали сами: www.meteor.com/projects. В результате получили упорядоченную структуру, где большей части проектов (модулей) из миров node.js, frontend, cordova нашлось правильное место. Если сравнивать с backbone, то Meteor так или иначе включает в себя весь функционал backbone. Примерно то же angular. Однако, если очень хочется, то можно подключить их к Meteor-приложению через пакеты и использовать как обычно (правда в Meteor всё сделано несколько удобнее).
А разве того, что Meteor является full-stack фреймворком, а Angular или Backbone — клиентскими фрейморками не достаточно? Как их можно сравнивать?
Сравнивать нужно например с Derby (вот устаревшая немного статья на Хабре) или с традиционной связкой JS+PHP|Python|Ruby etc — c этим автор статьи неплохо справился, имхо
Сравнивать нужно например с Derby (вот устаревшая немного статья на Хабре) или с традиционной связкой JS+PHP|Python|Ruby etc — c этим автор статьи неплохо справился, имхо
Вы можете использовать backbone или angular с метеором (-:
А Meteor умеет работать с несколькими веб-мордами?
А что конкретно вы называете веб-мордой? Шаблонизатор? CSS-фреймворк? В обоих случаях — да. На текущий момент поддерживаются spacebars и jade (но количество доступных пакетов увеличивается с огромной скоростью, так что скоро подтянутся все востребованные шаблонизаторы). CSS фреймворки — на любой цвет и вкус (можно подключать через пакеты или простым копированим файлов).
Веб-морда — это сервер, который обслуживает запросы от пользователя. Их может быть несколько и нагрузка между ними балансируется.
Понятно, что один сервер рано или поздно перестанет справляться с нагрузкой(именно запросов) и станет вопрос масштабируемости проекта.
Вот вопрос в том умеет это метеор или нет?
Понятно, что один сервер рано или поздно перестанет справляться с нагрузкой(именно запросов) и станет вопрос масштабируемости проекта.
Вот вопрос в том умеет это метеор или нет?
Будущее — за архитектурой, собираемой из отдельных компонуемых npm-пакетов. Управляющий код оформлен в виде потоков данных (Bacon, Highland). HTTP-данные, данные из сокетов и моделей абстрагированы в источники таких потоков, а представления на них единообразно подписываются. Пользователь также является источником потоков команд, подписчиком на которые выступает сервер.
Полностью согласен. Но, возможно, за деревьями вы не видите леса. Посмотрите поподробнее на Meteor — всё, о чём вы написали, как-раз таки им и реализуется. Смотрите:
Это как раз Meteor-пакеты. Компонуем node.js (npm), frontend (произвольный код) и cordova (packages). Всё чётко версионировано, все зависимости явны.
Реактивное програмирование — одна из core-фич Meteor. Я о ней не написал в статье, но тем не менее она есть и она прекрасна в своей простоте и эффективности. Литература: https://www.meteor.com/tracker
Это как раз про протокол DDP. Всё в точности соответствует вашему описанию. HTTP стоит отдельно, потому как (если не websocket) подразумевает перезагрузку страниц, а этого Meteor-приложению не требуется.
Этот пост появился не просто так. Meteor реально прекрасен. И к тому же хорошо работает.
Будущее — за архитектурой, собираемой из отдельных компонуемых npm-пакетов.
Это как раз Meteor-пакеты. Компонуем node.js (npm), frontend (произвольный код) и cordova (packages). Всё чётко версионировано, все зависимости явны.
Управляющий код оформлен в виде потоков данных (Bacon, Highland).
Реактивное програмирование — одна из core-фич Meteor. Я о ней не написал в статье, но тем не менее она есть и она прекрасна в своей простоте и эффективности. Литература: https://www.meteor.com/tracker
… данные из сокетов и моделей абстрагированы в источники таких потоков, а представления на них единообразно подписываются… (и далее)
Это как раз про протокол DDP. Всё в точности соответствует вашему описанию. HTTP стоит отдельно, потому как (если не websocket) подразумевает перезагрузку страниц, а этого Meteor-приложению не требуется.
Этот пост появился не просто так. Meteor реально прекрасен. И к тому же хорошо работает.
Похоже на рекламу, хотя AdBlock не сработал.
Вы имеете в виду strong opinion в статье? Да, оно там есть и оно сугубо моё. Но надо ж как-то заинтересовать российское веб-сообщество! Основное отличие от рекламы — в том, что в статье всё правда и ничего не преувеличено. Без фанатизма, в общем.
когда без фанатизма — перечисляют еще и минусы. а когда «почему не называем минусы? а их нет!» это буже булшит
Ха-ха, хороший приём! Я обязательно их опишу в ответе к этому комментарию. Но чуть позже, в ближайший час-два буду занят.
Прошло 9 часов…
А если серьёзно — есть один огроменнейший минус (я за вас озвучу) — наличие JS кода.
А если серьёзно — есть один огроменнейший минус (я за вас озвучу) — наличие JS кода.
Я ожидал минус(ы), но ожидал комментарий с доказательством превосходства JS, который бы я с радостью парировал примером на том же JS, от которого кровь в жилах стынет ;)
Я пишу на coffeescript и вам рекомендую. С javascript-ом никогда проблем не было — на любом языке можно устроить такой brainfuck, что мало не покажется. Но это только для jsfiddle. Для продакшена — только в соответствии с Clean Code.
Я в курсе, уже устраивал бреинфак на кофе =)
habrahabr.ru/post/235205/
habrahabr.ru/post/235205/
А вообще проблемы JS лишь в его гибкости, излишней (если уж захотели кофе — пример на кофе). Например можно сделать так:
или так:
class Some
some: -> alert 23
new Some::some # вылетит 23 в обход конструктора с инстанциированием метода класса.
или так:
class Some
privateStaticMethod = -> console.log @
callPrivateMethod: ->
do privateStaticMethod
privateStaticMethod.apply(@, [])
some = new Some
some.callPrivateMethod() # Window, затем some (object), т.е. уже не статик метод
Ничего удивительного. Просто надо знать как работает используемая технология. И приоритетом установить избегание конструкций, которые не читаются с первого раза.
По примеру 1. Вы Array.prototype.slice никогда не встречали? Очень распространённый приём в js.
По примеру 2. do в coffeescript принимает функцию аргументом и выполняет её. Поскольку функция передана аргументом, информация о родительском объекте (контексте) теряется. do надо использовать в comprehension'ах для изоляции контекста и/или создания замыканий, а не так как у вас в примере.
В копилку ваших приёмов создания констант в js и coffeescript: gist.github.com/eluck/74a5a8f8262d85497ab6
По примеру 1. Вы Array.prototype.slice никогда не встречали? Очень распространённый приём в js.
По примеру 2. do в coffeescript принимает функцию аргументом и выполняет её. Поскольку функция передана аргументом, информация о родительском объекте (контексте) теряется. do надо использовать в comprehension'ах для изоляции контекста и/или создания замыканий, а не так как у вас в примере.
В копилку ваших приёмов создания констант в js и coffeescript: gist.github.com/eluck/74a5a8f8262d85497ab6
Так вот, самый главный минус 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. Но это тоже слабоватый минус. Всё-таки разработчики должны быть более обучаемыми и гибкими.
Естественно, надо самому смотреть — приемлемы ли данные ограничения или нет.
Необходимость оборачивать библиотеки node.js в пакеты Meteor. Дел, правда, на 5 минут, и пакет можно не публиковать, но всё же. К слову, поиск нужного node.js модуля и изучение его API занимает гораздо больше времени. Да и нативные node.js модули доступны по-умолчанию. Так что минус слабоват. Я объясню, почему нужен свой формат пакетов, в комментариях ниже.
Маловато Meteor-разработчиков. Это скорее минус для бизнеса и плюс для самих разработчиков.
Нет официальной поддержки SQL, всё на mongodb. Для кого-то плюс, для кого-то минус.
Нет официальной поддержки разработки на Windows. Но это тоже слабоватый минус. Всё-таки разработчики должны быть более обучаемыми и гибкими.
Естественно, надо самому смотреть — приемлемы ли данные ограничения или нет.
Было бы здорово представить это в виде туториала и параллельно продемонстрировать все вышеперечисленные преимущества.
Есть официальный туториал с демонстрацией всех перечисленных фич: www.meteor.com/install. Ссылка также приведена в статье.
Помните про DRY! :)
Помните про DRY! :)
В первом же предложении вы упоминаете Derby. Он кстати умеет практически все что умеет метеор.
Метеор активнее развивается, а дерби потихоньку загибается.
Derby VS Meteor
Ну так, метеор же все пихает в одну репу, а у дерби все разнесено (derby, derby-templates, derby-parsing, exprima-derby, saddle, tracks, racer, racer-bundle, share (все типы вынесены в свои репы и модули), livedb, livedb-mongo, drerby-standalone и т.д.).
В таком случае можно сравнить по величине сообщества, количеству релизов и любым другим показателям. Даже если брать суммарно все проекты дерби, у метеора показатели в разы выше. И метеор тоже не монолитен, у него есть более двух тысяч специализированных пакетов, причем их количество выросло на треть примерно за месяц.
И? Выкинув racer или share можно их чем-то заменить? или без них будет полноценное приложение? (-:
Или, при обновлении racer, можно получить полностью нерабочее приложение (-:
Очень сомнительный плюс (-:
Или, при обновлении racer, можно получить полностью нерабочее приложение (-:
Очень сомнительный плюс (-:
А на moscovjs метеор сектой назвали… :)
Осторожно, статья страдает метеоризмом.
По описанию выглядит как монолитная штуковина с кучей собственных велосипедов решений: пакеты не npm, а свои, шаблонизатор свой, сборщик свой, — даже nodejs не апстримный, а с патчами. На сервере асинхронность спрятана за fibers, а на клиенте, по понятным причинам, нет. Свой протокол на своем формате. Из коробки привязка к домену meteor.com, на кой оно мне?
Даже если оно все и правда такое замечательное, пробовать как-то стремно. То ли наркотик, то ли, как выше сказали, секта, то ли покупаешь «решение» у Microsoft или Oracle.
Даже если оно все и правда такое замечательное, пробовать как-то стремно. То ли наркотик, то ли, как выше сказали, секта, то ли покупаешь «решение» у Microsoft или Oracle.
Про формат пакетов. Могут ли 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 приложения, к хостингу никак не привязанные.
Может, всё-таки стоит попробоать, вдруг понравится :)
Шаблонизатор основан на Handlebars и модифицирован для лучшей поддержки движка реактивных обновлений Blaze. Синтаксис по большей части такой же. Форк как форк, ничего необычного — весь гитхаб на них держится.
Сборщик решает свои задачи без муторной настройки. Большего от него не требуется. По мне так, это значительно лучше чем Grunt со сложными и нечитаемыми конфигами.
Node.js патченый только для сервера разработки. На хостинге приложение будет работать на самом обычном Node.js.
Все серверные методы и методы коллекций могут принимать callback последним параметром. В этом случае они будут работать в асинхронном стиле. И тут у вас промах.
Протокол DDP у Meteor свой. Он с открытым кодом и хорошо документирован (как и весь Meteor). Не вижу здесь проблем.
Никто не заставляет вас публиковать ваше приложение на meteor.com. Хотите — деплойте сразу на Amazon, DO или ваше собственное железо. Повторюсь — Meteor-приложения — это обычные node.js приложения, к хостингу никак не привязанные.
Может, всё-таки стоит попробоать, вдруг понравится :)
А как насчёт автоматического упорядоченного резолва зависимостей?А что, есть пакетные менеджеры, которые не умеют разрешать зависимости?
Могут ли npm-пакеты включать клиентский и расшаренный код?Откройте для себя bower/component/umd и browserify (если уж так хочется npm на клиенте). Я помогу освоить, если хотите.
Бросаться фразами действительно легко, а что если нужный мне модуль лежит в npm или bower?
И тут у вас промах.Это не у меня промах, а у вас, раз вы не смогли донести:)
Он с открытым кодом и хорошо документирован (как и весь Meteor).Хорошая документация и даже открытый код не значат ни-че-го, если что-то прибито гвоздями и выдрать это и заменить на свое невозможно. systemd вон тоже с открытым кодом, а вы слышали как его ругают? И ровно за то же самое.
Я просто пытаюсь вам показать, как для человека со стороны выглядят ваши дифирамбы, а вы меня в маны посылаете. Благодаря вашим некритически настроенным одам читать метеоровские маны теперь страшно.
Я понимаю, что вы делаете: вы пытаетесь нащупать слабые места в Meteor, и в результате у нас получается полезный для читателей диалог. Молчаливым минусователям надо брать с вас пример. Теперь по теме.
Резолв зависимостей в Meteor получается двухуровневый. Первый уровень — доставка исходников для приложения — то же, что и npm. Второй уровень, которого стандартный node.js не предствляет, — загрузка модулей в runtime во время старта приложения. То есть, вы можете выделить свой код в модули и явно указать порядок загрузки. Или сделать свой код зависимым от существующих пакетов, и он будет загружен после них.
Bower знаю, пользовал. Но Meteor идёт немного дальше. Как я уже отмечал, пакет Meteor может содержать код сразу всех типов: frontend, backend, cordova. Это открывает совершенно новые возможности упорядочивания логики. Например модуль аутентификации «accounts-google» вставляет гугловскую кнопку в интерфейс приложения, включает css-файл и добавляет клиентскую и серверную логику. Поскольку всё вместе это составляет функционал «логин с гуглом», то всё оно очень хорошо инкапсулируется именно в один пакет, а не разностися по разным модулям.
Meteor в себя включает ровно столько, сколько нужно. Meteor — прослойка, клей, собирающий воедино всё, что есть в мире node.js. Пользователи вольны включать любой существующий или новый функционал. Естественно, чтобы добиться удобства, разработчикам пришлось выразить определённое мнение по поводу организации логики. Я предлагаю считайть это аналогом convention over configuration из всем знакомых (и многоми любимых) рельсов. Кстати с выключением/заменой существующего функционала проблем тоже нет: один из коментаторов отметил, что ему удалось вместо mongo использовать influxdb. В комментах ниже я расскажу о том, что ещё можно отключить.
Резолв зависимостей в Meteor получается двухуровневый. Первый уровень — доставка исходников для приложения — то же, что и npm. Второй уровень, которого стандартный node.js не предствляет, — загрузка модулей в runtime во время старта приложения. То есть, вы можете выделить свой код в модули и явно указать порядок загрузки. Или сделать свой код зависимым от существующих пакетов, и он будет загружен после них.
Bower знаю, пользовал. Но Meteor идёт немного дальше. Как я уже отмечал, пакет Meteor может содержать код сразу всех типов: frontend, backend, cordova. Это открывает совершенно новые возможности упорядочивания логики. Например модуль аутентификации «accounts-google» вставляет гугловскую кнопку в интерфейс приложения, включает css-файл и добавляет клиентскую и серверную логику. Поскольку всё вместе это составляет функционал «логин с гуглом», то всё оно очень хорошо инкапсулируется именно в один пакет, а не разностися по разным модулям.
Meteor в себя включает ровно столько, сколько нужно. Meteor — прослойка, клей, собирающий воедино всё, что есть в мире node.js. Пользователи вольны включать любой существующий или новый функционал. Естественно, чтобы добиться удобства, разработчикам пришлось выразить определённое мнение по поводу организации логики. Я предлагаю считайть это аналогом convention over configuration из всем знакомых (и многоми любимых) рельсов. Кстати с выключением/заменой существующего функционала проблем тоже нет: один из коментаторов отметил, что ему удалось вместо mongo использовать influxdb. В комментах ниже я расскажу о том, что ещё можно отключить.
Вот так уже лучше, спасибо.
Ну, во-первых, второй уровень — это старые добрые CommonJS-like модули, которые все так любят. Ну а первый — это npm, или, на фронтенде, bower. И зачем две ортогональные задачи смешивать в одну?
Первый уровень — доставка исходников <...> Второй уровень, которого стандартный node.js не предствляет, — загрузка модулей в runtime
Ну, во-первых, второй уровень — это старые добрые CommonJS-like модули, которые все так любят. Ну а первый — это npm, или, на фронтенде, bower. И зачем две ортогональные задачи смешивать в одну?
Это избавляет от шума (явные импорты и экспорты в каждом файле CommonJS) и упрощает конфигурацию (все зависимости явны и инкапсулированы в одном файле конфигурации). В итоге это просто удобно. Я бы объяснил это естественной эволюцией, ведь npm, bower, yeoman и проч. тоже не сразу появились.
CommonJS не разрулит зависимости вида «css используется селектор, который зависит от класса проставляемого скриптом типа modernizr на body, следовательно нужно подгрузить этот самый скрипт»
Что-то мне этот метеор напоминает ASP (классический). Такая же монолитная вермишель, проекты на которой лет через 5 смогут ворочаться только в ИЕ6ИЕ10. Правда в поддержку могу сказать, что это опенсорс, так что можно надеяться на некоторую более продолжительную жизнь.
Вы просто не видели динамику развития проекта. Это нечто потрясающее — разработчики регулярно добавляли/удаляли фичи и рефакторили код, выпуская один стабильный (полностью рабочий) релиз в месяц. Критичных багов за год не было, некритичные фиксились за один-два дня. Такой профессиональной работы я ещё не видел. Сомневаюсь, что они затормозят проект. Скорее вы устанете апдейтить своё приложение.
автору очень хочется поделиться своим «счастьем» и побыстрее сделать всех вокруг «счастливыми», но именно вот такой захлёбывающийся от восторга гиперактивный фанатизм наоборот отпугивает.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А парни из Sencha разработчикам из Facebook тогда же в 2012 году в догонку показали, что можно было сделать на HTML 5: www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
Только FB их все равно не купил, а приложение от Sencha довольно быстро перестало нормально работать
Только FB их все равно не купил, а приложение от Sencha довольно быстро перестало нормально работать
Во-первых. На сайте cordov'ы есть страничка /apps, где [смеющиеся] сомневающиеся могут посмотреть на разработанные на текущий момент приложения.
Во-вторых, далеко не всем нужны «сложные» мобильные приложения. Особенно в начале бизнеса. После получения $M инвестиций можно хоть на C++ всё переписать.
В-третьих, посмотрим на это с другой стороны. Интерфейс веба состоит из блоков, собранных из html и css. Пользователям веба этого вполне достаточно. Так почему же пользователям мобильных при адекватном подходе к построению интерфейса будет плохо?
В-четвёртых, унификация кодирования, возможно (и даже вероятно), сделает сложные мобильные приложения проще.
В-пятых, естественно, мы не лезем на поляну сложных графических 2D и 3D приложений. Область применения любой технологии ограничена, и это абсолютно нормально.
Ваши доводы?
Во-вторых, далеко не всем нужны «сложные» мобильные приложения. Особенно в начале бизнеса. После получения $M инвестиций можно хоть на C++ всё переписать.
В-третьих, посмотрим на это с другой стороны. Интерфейс веба состоит из блоков, собранных из html и css. Пользователям веба этого вполне достаточно. Так почему же пользователям мобильных при адекватном подходе к построению интерфейса будет плохо?
В-четвёртых, унификация кодирования, возможно (и даже вероятно), сделает сложные мобильные приложения проще.
В-пятых, естественно, мы не лезем на поляну сложных графических 2D и 3D приложений. Область применения любой технологии ограничена, и это абсолютно нормально.
Ваши доводы?
Лично мне не очень понравилось включение мобильной разработки… Хотя моё приложение запустилось в эмуляторе андроидовском, но оно всё какое-то убогое, и всё равно придётся дизайн переделывать, поведение переделывать…
Мне легче переписать на jave, чем их вариантом пользоваться…
Мне легче переписать на jave, чем их вариантом пользоваться…
А можно как-то использовать только клиентскую часть Meteor?
В том-то и дело, что нет. Все перепилено и заточено сугубо под себя.
А вот клиентскую часть derby, кстати, отдельно попробовать можно — github.com/derbyjs/derby-standalone
Можно, но детали зависят от того, что вы имеете в виду под клиентской частью.
Если клиентская часть — это статический сайт без серверной логики, то да, можно. Просто не пишите серверную логику.
Если клиентская часть — это standalone node.js приложение ничего никому не отдающее, то выключите модуль webapp, являющийся сервером статики. В этом случае у вас получится обычное приложение, запускающееся из консоли и делающее, что надо, например, переименовывающее файлики.
Если клиентская часть — это статический сайт без серверной логики, то да, можно. Просто не пишите серверную логику.
Если клиентская часть — это standalone node.js приложение ничего никому не отдающее, то выключите модуль webapp, являющийся сервером статики. В этом случае у вас получится обычное приложение, запускающееся из консоли и делающее, что надо, например, переименовывающее файлики.
Наверное, имеется ввиду — использование метеор только в браузере с какой-нибудь свой серверной частью (например, ROR + postgresql)
И такую штуку провернуть можно. Для этого нужно сгенерировать клиентский bundle метеором и чем-либо отдавать его клиенту (по идее можно даже через Cloudflare/Cloudfront). Для взаимодействия с клиентской частью сервер должен поддерживать протокол DDP (есть на почти всех языках). Такой абстрактный сервер сможет работать с любой БД. Но насколько это удобно?
Обратное (сервер — Meteor, клиент — абстрактное приложение) тоже возможно, и до появлении поддержки cordov'ы все так и делали с мобильными приложениями. Мы, например, свои мобильные клиенты на cordov'у не перевели и пока не собираемся.
Обратное (сервер — Meteor, клиент — абстрактное приложение) тоже возможно, и до появлении поддержки cordov'ы все так и делали с мобильными приложениями. Мы, например, свои мобильные клиенты на cordov'у не перевели и пока не собираемся.
Причём вся эта штука без хайпа и маркетоложеского словоблудия, тихо и незаметно реализуется на Clojure/ClojureScript с помощью om+sente+core.async.
Хотелось бы глянуть на ограничения архитектуры и фейл-сториз. Спасибо…
У нас сейчас в разработке самое крупное (или одно из самых) Meteor-приложение. Именно с архитектурными ограничениями пока не столкнулись. Самое главное «ограничение», как я писал выше, — высокий порог входа. Постоянно приходится выгребать за ньюкамерами тонны г.на.
Про фейлы пока не слышал, но первая версия Meteor появилась только на прошлой неделе, так что всё впереди.
Про фейлы пока не слышал, но первая версия Meteor появилась только на прошлой неделе, так что всё впереди.
Когда я пишу код, знаю ли я будет он исполняться на клиенте или на сервере? Есть ли миграция кода между клиентом и сервером, не обмен JSON, не RemouteProcedureCall а дословно миграция исполняемого кода?
Когда я пишу код, знаю ли я будет он исполняться на клиенте или на сервере?
Да вы можете четко контролировать какой код и где будет выполняться. Есть специальные директории client и server, файлы в которых будет доступны только в определенных средах, и еще можно использовать условия типа
if (Meteor.isClient)
// ваш клиентский код
if (Meteor.isServer)
// серверный код
Есть ли миграция кода между клиентом и сервером, не обмен JSON, не RemouteProcedureCall а дословно миграция исполняемого кода?
Не совсем понял вопрос, но у вас есть возможность писать код в одном файле и он будет доступен в обоих средах, если вы про инъекции кода в реалтайме, то нет такого нет, однако с помощью тех же механизмов RPC и eval это легко осуществимо, правда не совсем понимаю где это может пригодится.
Возможно, под миграцией исполняемого кода вы понимаете hot code push. Это технология, позволяющая обновлять версию клиентского и серверного приложения прямо во время работы с сохранением состояния клиента. Она в Meteor есть и позиционируется как одна из основных фич, но, я бы сказал, что использовать её надо с большой осторожностью.
А вот я благодарен автору этой публикации, столько интересного в комментах почитал, спасибо. Без сарказма.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О Meteor подробно: почему это будущее веб-разработки