Комментарии 36
А SailsJS может генерировать страницы на сервере? Для SEO важно.
Да ни кто не мешает. Но хочется что бы был нормальный механизм, человек зашел на страницу ему отдается генерированная сервером, а при дальнейших перемещениях уже генерируется на стороне клиента
А кто работал с Opa framework? Там вроде как вообще магия происходит. Он сам выбирает какой код выполнять на стороне клиента, а какой на стороне сервера.
Кстати хотел спросить, кто ставил себе derbyjs на виндовз? У меня не хочет hiredis компилироваться… Кто-нибудь решал такую задачу?
Я компилил redis с мелкосовтовского форка, но он по моему без hiredis…
Derby.js — новый взгляд на веб-разработку
хорошо спрятали, из кеша гугла не достается, на web.archive.org тоже нету. :(
Кто-то мне только что инвайт подарил за этот пост. Спасибо!

Вообще пишу на derby.js больше года, полет нормальный.
До этого писал на asp.net -> asp.net mvc -> asp.net web api + backbone.js -> meteor (недолго) -> derby.js
Если есть вопросы, спрашивайте.
Почему ушли с .net? и как себя показал meteor? Пробовали ли вы AngularJS? Насколько я помню была зарекомендована поддержка serverside для AngularJS в будущем, если я не ошибаюсь.
Давайте на ты. Ок?

Почему ушел с .net?
Постепенно всё больше писал на клиенте (js + jquery). Постепенно пришел к понимаю что код на клиенте хорошо бы структурировать, нашел backbone.js. Получилось что MVC на сервере практически не нужен, а нужен REST-апи. Сервер значительно похудел и в какой-то момент стало не так важно на чем его писать, так как вся функциональность была на клиенте (этакий сдвиг парадигмы). Я бы наверное так и остался на .net, но у REST-апи тоже оказались недостатки: 1) классический REST бывает только на мифических проектах в вакууме. В реальности появляется много дополнительных методов. 2) не решена проблема синхронизации данных между клиентами. Тогда произошел новый сдвиг парадигмы и я начал искать другие решения. Все они оказались на node.js.

Пробовал ли AngularJS?
Не пробовал. Знаю что это сейчас очень модный фреймворк. В моем представлении AngularJS — это такой навороченный backbone. То есть тот же MVC на клиенте. Мы динамически связали наш html с нашими данными клиенте, хорошо. Как будем данные на клиент доставлять? Как будем синхронизировать клиенты? Если два клиента работают с одними данными, будем как-то разрешать конфликты? Это всё нужно дописывать вручную или интегрировать какие-то решения.
По поводу serverside: не думаю что это будет реализованно лучше чем например serverside в meteor. Одно дело изначально заклыдывать в архитектуру, другое дело добавлять.

Хочу добавить по поводу сравнения .net и node.js
node.js в целом значительно приятнее для веба, чем .net и тому есть несколько причин:

1) платформа изначально создавалась для веба (написать веб-сервер можно в 3 строчки)
2) ассинхронность (на хабре была уже статья про миллион одновременных соединений на одном сервере)
3) один язык на сервере и клиенте (на самом деле и библиотеки в основном тоже через browserify)

После того как распробовал node.js, возвращаться на .net совсем не хочется, рекомендую.
можно узнать, что подразумевается под «классический REST бывает только на мифических проектах в вакууме. В реальности появляется много дополнительных методов»? то ли у нас заведомо неклассический REST, то ли мифический проект. как по мне REST как REST — система эндпойнтов и HTTP-verbs. ну это конечно то, что торчит наружу только.
а вы с чем столкнулись?
Под «классическим» я имел ввиду REST примерно такого вида:
GET: /users
GET: /users/34
POST: /users/34
PUT: /users/34
DELETE: /users/34

В реальности вам например нужно поменять свойство field у юзеров, которые являются создателями продуктов, которые принадлежат категории с id = 2. Сколько будете делать запросов на сервер, если например окажется что таких пользователей 50? Скорее всего у вас появится метод changeFieldForUsersWithProductsInCategory(categoryId, fieldValue). Со временем подобных методов будет много.

У REST есть и другие минусы:
1) не решена проблема синхронизации данных
2) дублирование кода на клиенте и сервере
касательно вашего примера — это не меняет взаимодествия с эндпойнтами. надо проапдейтить одну сущность — передавайте параметры, делая PUT /user/34, если надо делать bulk operations — делайте PUT для коллекции. пусть у вас будет метод changeFieldForUsersWithProductsInCategory и много других, но это детали внтуренней обработки любых параметров, которые РЕСТа напрямую не касаются.
— насчет синхронизации, там где прям нужно рилтайм обновление и пуш данных к юзерам — да, рест напрямую тут не подойдет, это все же одна из архитектур взаимодействия.
На мой взгляд REST стал популярным в вебе из-за того, что он красиво ложится на http. Но в реальности как вы сами и говорите у REST много ограничений. В чем его недостатки мы поняли. Объясните в чем его преимущества?
Чем не понравился Метеор?
Чем он уступает Derby?
Что самое сильное на ваш взгляд в Derby?
Чем понравился Метеор:
Очень низкий порог входа. Отличный маркетинг (многие и не знают что есть альтернативы). Очень красивый апи.
На Метеоре вы очень быстро сможете написать несложный проект (коих большинство).

Чем не понравился Метеор:
Некоторый уровень абстракции от node.js, свой пакетный менеджер, авторизация и т.п. загоняют вас в определенные рамки. Красота апи требует жертв. Неудобства пропорциональны сложности проекта.

Чем он уступает Derby?
В derby отличная модель работы с данным на основе share.js, нативый serverside, к тому же приложение derby — это обычное приложение express.js, что позволяет быть гибкими и пользоваться всеми плюшками node.js.

Что самое сильное на ваш взгляд в Derby?
Самое сильное в Derby — архитектура, в которую изначально заложено то, что в других фреймворках только в планах.
Супер, спасибо за объяснение) Можешь дать какие-то напутствие для изучения DerbyJS, более детальные описания и туториалы?
Вот исходники проекта в продакшене:
derby 0.3: github.com/lefnire/habitrpg/tree/master
тут переписывали на derby 0.5: github.com/lefnire/habitrpg/tree/challenges-and-0.5

Тут кто-то составлял дерево знаний необходимых для понимания derby: workflowy.com/shared/9e4d8b18-af04-4f04-1557-88b31a78c324/

Вопросы задавайте тут: Google Groups
Я тоже помогу, чем могу, пишите.
Я правильно понимаю, что использовать Jade c Derby не получится?
Порекомендуйте, что на эту тему хорошего можно почитать. jade + derby.
К сожалению, читать нечего. Могу только вкратце рассказать. Если хотите, чтобы jade работал с derby 0.6, то вам нужно будет ставить немного пропатченную версию дерби — github.com/cray0000/derby. Просто пропишите в package.json своего приложения в разделе зависимостей «derby»: «git@github.com:cray0000/derby.git». Это пропатченная версия derby, она постоянно синхронизируется с основной Павлом Жуковым (владельцем репы). Потом делаете в проекте npm install — и все подтянется (включая модуль derby-jade). Все, теперь вместо html-файлов в папочку views вы можете можете класть файлы с расшинением jade.

Вот пример jade-файла:
import:(src='./auth', ns='')
import:(src='./games')

Title:
  | My cool app

Body:
  view(name='welcome', title='Welcome {{_session.username}}')
    p We are glad to see you!

Footer:
  view(name='copyright')

welcome:
  h1 {{@title}}
  | {{@content}}

copyright:
  p Use it however you want {{_session.username}}!

Ну и смотрите документацию к github.com/cray0000/derby-jade
Спасибо, уже посмотрел репку из предыдущего коментария. Выглядит несколько костыльно. В возможные альтернативы метеору успешно вписал дерби, если с метеором не срастется, буду дерби смотреть.
pull-request с добавлением jade в дерби еще не приняли (без юнит-тестов не берут, а Павел медлит с их разработкой)
А так само думал о meteor, но волею судеб, теперь хорошо знаю дерби и переходить, скорее всего не буду.
Это уже очень интересно, с появлением юнит-тестов должно появится некостыльное решение. Как минимум стоит поставить дерби на мониторинг. Пока метеор вроде меня устраивает, в дерби главным вопросом для меня был jade. Другой важный вопрос — юнит и функциональное тестирование, на подобии cucumber, но с этим как я понял и у метеора не очень.
Сам фреймворк очень хорошо поделен на модули, почти все покрыты тестами. Используется mocha. Мы в своих проектах тоже используем mocha, а так же casper-mocha для тестирования производительности в браузере.

Для dependency-injection модели используется модуль racer-fixtures.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.