Спасибо за добрые слова. Особенно мне понравилась фраза про «вся надежда только на меня». :-)
Вряд ли имеет смысл писать туториалы по Redis или Mongo DB. Думаю их и так достаточно.
Тем более на первом этапе не нужно про них почти ничего знать.
Node и Express можно тоже в принципе освоить походу. Хотя какую-нибудь книжку по Node прочитать не было бы лишним (ибо не похож на другие платформы).
Grunt я не использую. Derby автоматом обновляет html, css на клиенте при изменении. А для coffeescipt`а (пишу на нем) я использую:
coffee -w
Что такое Bower я узнал только сейчас. Но так и не понимаю зачем он нужен если есть browserify и npm-пакеты на клиенте. Может вы мне объясните?
Итого есть две идеи для туториалов:
1) С нуля с настраиванием окружения и прочее до hello world.
2) Написать какое-то приложение шаг по шагу. Что это может быть? интернет магазин? crm-система? социальная сеть? только давайте не супер сложное что-то.
Сам использую Derby для разных целей. Есть большой проект crm-erp системы. Есть мелкие сайты, где даже нету базы данных, а есть только статичные страницы, генерирующиеся на сервере. Везде это крайне удобно и в тему.
Derby — очень гибкая штука. Если пойдете на слона, то можете из нее собрать пушку, А если на воробья — то рогатку.
Angular тут изначально не конкурентна, потому что это не full-stack.
express.js/node.js как бэкенд для Angular имеет плюсы:
1) повторное использование кода на клиенте и сервере (валидация, например)
2) browserify (использование одних и тех же модулей на клиенте и сервере)
Любой другой бэкенд для Angular ставит ее в еще более не конкурентное положение.
Я тут уже написал по поводу «преимущества возможноти любого бэкенда»
По поводу fibers посмотрел и правда псевдосинхронность. Извиняюсь ошибся, просто очень давно их ковырял.
Но я всё же не рекомендую их использовать, ибо это противоречит идеологии node.js.
Для синхронизации данных в Meteor хорошо бы реализовать модель разрешения конфликтов какую-нибудь или взять уже готовую (OT от share.js). Для OT кстати важен порядок получения сообщений между клиентом и сервером. Этого нельзя добиться в веб-сокетах. А DDP-протокол в Meteor как раз на веб-сокетах завязан. Варианта три:
1) Они меняют DDP-протокол и что там на него завязано еще. Используют share.js
2) Используют другую модель разрешения конфликтов, отличную от OT. Тут я даже не знаю что посоветовать.
3) Просто добавляют pub/sub, но не меняют модель разрешения конфликтов. Масштабироваться будет лучше, но данные будут теряться.
Я склонен к тому, что они выберут последний вариант.
Для того чтобы в Метеоре сделать Pub/sub как в Derby им нужно переписать «пол Метеора» и написать свою share.js. Они изначально пошли не в том направлении. Derby кстати тоже не сразу к share.js пришли и переписали весь racer для этого в версии 0.5.
Я просто к тому что у многих фреймворков в планах и Pub/sub и генерация html на сервере. Но это не так просто добавить, если сразу не было заложено в архитектуру.
С моей точки зрения различия между клентскими mvc фреймворками (Angular, Ember, Backbone и т.д тыщи их) минимальны. Как я вам уже сказал я не могу вам советовать использовать mvc- на клиенте фреймворки во времена node.js и full-stack фреймворков.
Спасибо, что так расиписали. Ваш опыт будет очень полезен многим.
В свою очередь хочу сделать несколько утверждений:
Если вы хотите повторно использовать код между сервером и клиентом, то бэкенд может быть только один — node.js. По этому утверждение, что «возможность любого бэкенда для mvc-на клиенте фреймворков — это их плюс» — ложно. Это такой же их плюс, какой и минус. Ибо они изначально ограничены этим и теряют возможности.
fibers не нужно использовать. node.js — ассинхронен. В этом есть плюсы и ест минусы.
Это примерно как прототипная модель наследования в js, Нельзя сказать что она хуже, чем классы. Просто не всем это привычно.
Если ваш код в node.js превращается в спаггети, то это не проблема node.js. Вам просто нужно поменять манеру писать код. Использование же fibers делает node.js синхронным, блокирует event-loop. Это очень большой костыль. Его использование убивает все сильные стороны node.js на корню. fiber я бы отнес к минусам Meteor, а не к плюсам.
Кстати в Derby есть компоненты. И реализованы они очень классно. И олдскульные сайты можно делать (ибо есть генерация html на сервере).
Синхронизация данных между клиентам в Метеор сделано довольно топорно. Метеор долбит монго каждые 10 секунд, либо по изменению данных (событий у монго нету). Вычисляет изменения и передает их клиентам. Такой подход плох с двух сторон:
1) Нету механизма разрешения конфликтов при одновременном изменении одних и тех же данных разными клиентами. Изменения будут теряться.
2) Масштабироваться такая модель будет плохо. И будет 10 секундный лаг.
В Derby это на другом уровне.
До Derby я пробовал Meteor. Писал тут. В целом могу сказать, что то что вы любите в Meteor и в Angular, вы найдете в Derby. И даже больше.
Grunt будет перекомпилировать файлы на сервере. А как вы изменения на клиент будете доставлять? Как будете осуществлять live-update на клиенте? Это должно быть заложено в фреймворк. Meteor даже от npm пакетов отказался чтобы js на клиенте можно было менять.
А что вы про игры говорите? Какие эти фреймворки? Что значит перерисовывают состояние? Я не совсем понял.
Вряд ли имеет смысл писать туториалы по Redis или Mongo DB. Думаю их и так достаточно.
Тем более на первом этапе не нужно про них почти ничего знать.
Node и Express можно тоже в принципе освоить походу. Хотя какую-нибудь книжку по Node прочитать не было бы лишним (ибо не похож на другие платформы).
Grunt я не использую. Derby автоматом обновляет html, css на клиенте при изменении. А для coffeescipt`а (пишу на нем) я использую:
Что такое Bower я узнал только сейчас. Но так и не понимаю зачем он нужен если есть browserify и npm-пакеты на клиенте. Может вы мне объясните?
Итого есть две идеи для туториалов:
1) С нуля с настраиванием окружения и прочее до hello world.
2) Написать какое-то приложение шаг по шагу. Что это может быть? интернет магазин? crm-система? социальная сеть? только давайте не супер сложное что-то.
Что еще могу для вас сделать?
А в чем не хватило гибкости?
Спасибо за вопросы. :-) Рад если помогло.
Давайте идею для туториала тогда. Про что написать? Что не понятно? Примеры какие нужны?
Derby — очень гибкая штука. Если пойдете на слона, то можете из нее собрать пушку, А если на воробья — то рогатку.
Такое возможно. Например Метеор для синхронизации данных использует DDP-протокол и серверная часть для него может быть любой (есть пример на python).
Но причем тут повторяемость кода? Для повторяемости кода нужен:
1) один язык на сервере и клиенте
2) архитектура фреймворка, способствующая этому
Тут как бы опять же node.js и full-stack
express.js/node.js как бэкенд для Angular имеет плюсы:
1) повторное использование кода на клиенте и сервере (валидация, например)
2) browserify (использование одних и тех же модулей на клиенте и сервере)
Любой другой бэкенд для Angular ставит ее в еще более не конкурентное положение.
Я тут уже написал по поводу «преимущества возможноти любого бэкенда»
По поводу fibers посмотрел и правда псевдосинхронность. Извиняюсь ошибся, просто очень давно их ковырял.
Но я всё же не рекомендую их использовать, ибо это противоречит идеологии node.js.
Для синхронизации данных в Meteor хорошо бы реализовать модель разрешения конфликтов какую-нибудь или взять уже готовую (OT от share.js). Для OT кстати важен порядок получения сообщений между клиентом и сервером. Этого нельзя добиться в веб-сокетах. А DDP-протокол в Meteor как раз на веб-сокетах завязан. Варианта три:
1) Они меняют DDP-протокол и что там на него завязано еще. Используют share.js
2) Используют другую модель разрешения конфликтов, отличную от OT. Тут я даже не знаю что посоветовать.
3) Просто добавляют pub/sub, но не меняют модель разрешения конфликтов. Масштабироваться будет лучше, но данные будут теряться.
Я склонен к тому, что они выберут последний вариант.
А это они же в виде объектов на сервере.
Для того чтобы в Метеоре сделать Pub/sub как в Derby им нужно переписать «пол Метеора» и написать свою share.js. Они изначально пошли не в том направлении. Derby кстати тоже не сразу к share.js пришли и переписали весь racer для этого в версии 0.5.
Я просто к тому что у многих фреймворков в планах и Pub/sub и генерация html на сервере. Но это не так просто добавить, если сразу не было заложено в архитектуру.
И тут про Метеор
Имелась ввиду не возможность для большинства приложений использовать pub-sub в Mongo DB из-за ограничений.
В свою очередь хочу сделать несколько утверждений:
Если вы хотите повторно использовать код между сервером и клиентом, то бэкенд может быть только один — node.js. По этому утверждение, что «возможность любого бэкенда для mvc-на клиенте фреймворков — это их плюс» — ложно. Это такой же их плюс, какой и минус. Ибо они изначально ограничены этим и теряют возможности.
fibers не нужно использовать. node.js — ассинхронен. В этом есть плюсы и ест минусы.
Это примерно как прототипная модель наследования в js, Нельзя сказать что она хуже, чем классы. Просто не всем это привычно.
Если ваш код в node.js превращается в спаггети, то это не проблема node.js. Вам просто нужно поменять манеру писать код. Использование же fibers делает node.js синхронным, блокирует event-loop. Это очень большой костыль. Его использование убивает все сильные стороны node.js на корню. fiber я бы отнес к минусам Meteor, а не к плюсам.
Кстати в Derby есть компоненты. И реализованы они очень классно. И олдскульные сайты можно делать (ибо есть генерация html на сервере).
Синхронизация данных между клиентам в Метеор сделано довольно топорно. Метеор долбит монго каждые 10 секунд, либо по изменению данных (событий у монго нету). Вычисляет изменения и передает их клиентам. Такой подход плох с двух сторон:
1) Нету механизма разрешения конфликтов при одновременном изменении одних и тех же данных разными клиентами. Изменения будут теряться.
2) Масштабироваться такая модель будет плохо. И будет 10 секундный лаг.
В Derby это на другом уровне.
До Derby я пробовал Meteor. Писал тут. В целом могу сказать, что то что вы любите в Meteor и в Angular, вы найдете в Derby. И даже больше.