Ничего не мешает. Просто Derby — это несколько больше чем просто MVC на клиенте + REST.
Лично для меня это пройденный этап, вот тут писал об это: habrahabr.ru/post/191664/#comment_6666124
Да, Tyler со своим habitrpg был первым кто выложил что-то более менее серьезное в продакшен на дерби. Если мне не изменяет память это было осенью 2012. Ну и как всякий первооткрыватель, он столкнулся с некоторыми проблемами.
Те проблемы со стабильностью, которые были в версии 0.3, решены в версии 0.5. Сейчас дерби стабилен как никогда. Сам Tyler пишет об этом вот здесь: github.com/lefnire/habitrpg/issues/1247
Главная причина почему он не стал обновлятся до версии 0.5 была в том, что до определенного момента версия 0.5 требовала чтобы ваша база данных полностью сидела в редис, что для больших данных не возможно ввиду ограничения оперативной памяти. Это проблема решена несколько дней назад с появлением livedb 2.0, вот тут Joseph писал об этом: groups.google.com/forum/#!topic/derbyjs/7KPaTMTqceU
Сейчас редис — это что-то наподобие кэша для последних операций. И полагаю, так и должно быть.
Tyler давно был большим фанатом Angular, что не мешало ему в свое время сделать выбор в пользу Derby. Если интересно мое мнение по Angular, вот тут немного писал: habrahabr.ru/post/191664/#comment_6666124
В основном активность происходит в Google Groups. После последнего поста в блоге было много мажорных обновлений. Просто у Дерби в отличие от Метеора нету людей занимающихся маркетингом фуллтайм. И коммунити Дерби значительно меньше. Это можно объяснить опять же маркетингом и высоким порогом входа.
Хорошо. Но дело в том как это реализовано.
В derby.js обмен данными идет через github.com/josephg/node-browserchannel
Это такая штука, которую например Google в Gmail использует, потому что никакие веб-сокеты не дают гарантии что сообщения прийдут в том порядке, в котором ушли.
Для синхронизации данных используется sharejs.org
Это подобно тому что например Google использовал в Google Waves.
Offline пока полностью не реализован. Но база заложена. Есть share.js, который может мержить данные с клиентов, обрабатывая конфликты с учетом времени изменения. То есть если клиент пропал на время и потом вернулся, его изменения лягут в базу как надо даже сейчас.
Есть планы сделать на каждом клиента базы данных (indexed DB), чтобы можно было не просто пропадать, но и браузер перезагрузить например ничего не потеряв. На самом деле ничего не мешает этого добавить сейчас.
По поводу PhoneGap — интересный вопрос. Если вы можете запустить node.js + mongodb + redis на телефоне, то наверное можно использовать.
Чем понравился Метеор:
Очень низкий порог входа. Отличный маркетинг (многие и не знают что есть альтернативы). Очень красивый апи.
На Метеоре вы очень быстро сможете написать несложный проект (коих большинство).
Чем не понравился Метеор:
Некоторый уровень абстракции от node.js, свой пакетный менеджер, авторизация и т.п. загоняют вас в определенные рамки. Красота апи требует жертв. Неудобства пропорциональны сложности проекта.
Чем он уступает Derby?
В derby отличная модель работы с данным на основе share.js, нативый serverside, к тому же приложение derby — это обычное приложение express.js, что позволяет быть гибкими и пользоваться всеми плюшками node.js.
Что самое сильное на ваш взгляд в Derby?
Самое сильное в Derby — архитектура, в которую изначально заложено то, что в других фреймворках только в планах.
Почему ушел с .net?
Постепенно всё больше писал на клиенте (js + jquery). Постепенно пришел к понимаю что код на клиенте хорошо бы структурировать, нашел backbone.js. Получилось что MVC на сервере практически не нужен, а нужен REST-апи. Сервер значительно похудел и в какой-то момент стало не так важно на чем его писать, так как вся функциональность была на клиенте (этакий сдвиг парадигмы). Я бы наверное так и остался на .net, но у REST-апи тоже оказались недостатки: 1) классический REST бывает только на мифических проектах в вакууме. В реальности появляется много дополнительных методов. 2) не решена проблема синхронизации данных между клиентами. Тогда произошел новый сдвиг парадигмы и я начал искать другие решения. Все они оказались на node.js.
Пробовал ли AngularJS?
Не пробовал. Знаю что это сейчас очень модный фреймворк. В моем представлении AngularJS — это такой навороченный backbone. То есть тот же MVC на клиенте. Мы динамически связали наш html с нашими данными клиенте, хорошо. Как будем данные на клиент доставлять? Как будем синхронизировать клиенты? Если два клиента работают с одними данными, будем как-то разрешать конфликты? Это всё нужно дописывать вручную или интегрировать какие-то решения.
По поводу serverside: не думаю что это будет реализованно лучше чем например serverside в meteor. Одно дело изначально заклыдывать в архитектуру, другое дело добавлять.
Кто-то мне только что инвайт подарил за этот пост. Спасибо!
Вообще пишу на derby.js больше года, полет нормальный.
До этого писал на asp.net -> asp.net mvc -> asp.net web api + backbone.js -> meteor (недолго) -> derby.js
Если есть вопросы, спрашивайте.
Лично для меня это пройденный этап, вот тут писал об это: habrahabr.ru/post/191664/#comment_6666124
Те проблемы со стабильностью, которые были в версии 0.3, решены в версии 0.5. Сейчас дерби стабилен как никогда. Сам Tyler пишет об этом вот здесь: github.com/lefnire/habitrpg/issues/1247
Главная причина почему он не стал обновлятся до версии 0.5 была в том, что до определенного момента версия 0.5 требовала чтобы ваша база данных полностью сидела в редис, что для больших данных не возможно ввиду ограничения оперативной памяти. Это проблема решена несколько дней назад с появлением livedb 2.0, вот тут Joseph писал об этом: groups.google.com/forum/#!topic/derbyjs/7KPaTMTqceU
Сейчас редис — это что-то наподобие кэша для последних операций. И полагаю, так и должно быть.
Tyler давно был большим фанатом Angular, что не мешало ему в свое время сделать выбор в пользу Derby. Если интересно мое мнение по Angular, вот тут немного писал: habrahabr.ru/post/191664/#comment_6666124
Раньше я пробовал Метеор. Вот тут немного написал про впечатления: habrahabr.ru/post/191664/#comment_6666236
В derby.js обмен данными идет через github.com/josephg/node-browserchannel
Это такая штука, которую например Google в Gmail использует, потому что никакие веб-сокеты не дают гарантии что сообщения прийдут в том порядке, в котором ушли.
Для синхронизации данных используется sharejs.org
Это подобно тому что например Google использовал в Google Waves.
А у Vaadin что? Ajax? Простите за вопрос.
Вот проект от создателей derby в продакшене: lever.co
Есть планы сделать на каждом клиента базы данных (indexed DB), чтобы можно было не просто пропадать, но и браузер перезагрузить например ничего не потеряв. На самом деле ничего не мешает этого добавить сейчас.
По поводу PhoneGap — интересный вопрос. Если вы можете запустить node.js + mongodb + redis на телефоне, то наверное можно использовать.
Очень низкий порог входа. Отличный маркетинг (многие и не знают что есть альтернативы). Очень красивый апи.
На Метеоре вы очень быстро сможете написать несложный проект (коих большинство).
Чем не понравился Метеор:
Некоторый уровень абстракции от node.js, свой пакетный менеджер, авторизация и т.п. загоняют вас в определенные рамки. Красота апи требует жертв. Неудобства пропорциональны сложности проекта.
Чем он уступает Derby?
В derby отличная модель работы с данным на основе share.js, нативый serverside, к тому же приложение derby — это обычное приложение express.js, что позволяет быть гибкими и пользоваться всеми плюшками node.js.
Что самое сильное на ваш взгляд в Derby?
Самое сильное в Derby — архитектура, в которую изначально заложено то, что в других фреймворках только в планах.
Почему ушел с .net?
Постепенно всё больше писал на клиенте (js + jquery). Постепенно пришел к понимаю что код на клиенте хорошо бы структурировать, нашел backbone.js. Получилось что MVC на сервере практически не нужен, а нужен REST-апи. Сервер значительно похудел и в какой-то момент стало не так важно на чем его писать, так как вся функциональность была на клиенте (этакий сдвиг парадигмы). Я бы наверное так и остался на .net, но у REST-апи тоже оказались недостатки: 1) классический REST бывает только на мифических проектах в вакууме. В реальности появляется много дополнительных методов. 2) не решена проблема синхронизации данных между клиентами. Тогда произошел новый сдвиг парадигмы и я начал искать другие решения. Все они оказались на node.js.
Пробовал ли AngularJS?
Не пробовал. Знаю что это сейчас очень модный фреймворк. В моем представлении AngularJS — это такой навороченный backbone. То есть тот же MVC на клиенте. Мы динамически связали наш html с нашими данными клиенте, хорошо. Как будем данные на клиент доставлять? Как будем синхронизировать клиенты? Если два клиента работают с одними данными, будем как-то разрешать конфликты? Это всё нужно дописывать вручную или интегрировать какие-то решения.
По поводу serverside: не думаю что это будет реализованно лучше чем например serverside в meteor. Одно дело изначально заклыдывать в архитектуру, другое дело добавлять.
Вообще пишу на derby.js больше года, полет нормальный.
До этого писал на asp.net -> asp.net mvc -> asp.net web api + backbone.js -> meteor (недолго) -> derby.js
Если есть вопросы, спрашивайте.