Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Есть еще такой интересный проект Full Stack Framework for NodeJS sailsjs.org/
А SailsJS может генерировать страницы на сервере? Для SEO важно.
По моему нет.
Кто мешает сделать подобно этому? www.yearofmoo.com/2012/11/angularjs-and-seo.html
А кто работал с Opa framework? Там вроде как вообще магия происходит. Он сам выбирает какой код выполнять на стороне клиента, а какой на стороне сервера.
Кстати хотел спросить, кто ставил себе derbyjs на виндовз? У меня не хочет hiredis компилироваться… Кто-нибудь решал такую задачу?
Не встречал на хабре материалов, посвященных фреймворку Derbyjs
Была, но сплыла почему-то: Derby.js — новый взгляд на веб-разработку Еще в том году вроде.
Еще был когда-то NowJS, но сплыл. На гитхабе уже 2 года никаких коммитов.
Derby.js — новый взгляд на веб-разработкухорошо спрятали, из кеша гугла не достается, на web.archive.org тоже нету. :(
Кто-то мне только что инвайт подарил за этот пост. Спасибо!
Вообще пишу на derby.js больше года, полет нормальный.
До этого писал на asp.net -> asp.net mvc -> asp.net web api + backbone.js -> meteor (недолго) -> derby.js
Если есть вопросы, спрашивайте.
Вообще пишу на 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?
Постепенно всё больше писал на клиенте (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 совсем не хочется, рекомендую.
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) дублирование кода на клиенте и сервере
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 и много других, но это детали внтуренней обработки любых параметров, которые РЕСТа напрямую не касаются.
— насчет синхронизации, там где прям нужно рилтайм обновление и пуш данных к юзерам — да, рест напрямую тут не подойдет, это все же одна из архитектур взаимодействия.
— насчет синхронизации, там где прям нужно рилтайм обновление и пуш данных к юзерам — да, рест напрямую тут не подойдет, это все же одна из архитектур взаимодействия.
Чем не понравился Метеор?
Чем он уступает Derby?
Что самое сильное на ваш взгляд в Derby?
Чем он уступает Derby?
Что самое сильное на ваш взгляд в Derby?
Чем понравился Метеор:
Очень низкий порог входа. Отличный маркетинг (многие и не знают что есть альтернативы). Очень красивый апи.
На Метеоре вы очень быстро сможете написать несложный проект (коих большинство).
Чем не понравился Метеор:
Некоторый уровень абстракции от node.js, свой пакетный менеджер, авторизация и т.п. загоняют вас в определенные рамки. Красота апи требует жертв. Неудобства пропорциональны сложности проекта.
Чем он уступает Derby?
В derby отличная модель работы с данным на основе share.js, нативый serverside, к тому же приложение derby — это обычное приложение express.js, что позволяет быть гибкими и пользоваться всеми плюшками node.js.
Что самое сильное на ваш взгляд в 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
Я тоже помогу, чем могу, пишите.
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
Я тоже помогу, чем могу, пишите.
Вроде бы альтернатива для NowJS есть github.com/substack/shoe
Презентация на ту же тему: www.slideshare.net/studgeek/an-overview-of-derbyjs-and-meteorjs-for-the-nova-nodejs-meetup
Я правильно понимаю, что использовать Jade c Derby не получится?
нет не правильно. используем jade и для derby 0.5 и для 0.6
Порекомендуйте, что на эту тему хорошего можно почитать. 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-файла:
Ну и смотрите документацию к github.com/cray0000/derby-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, но волею судеб, теперь хорошо знаю дерби и переходить, скорее всего не буду.
А так само думал о meteor, но волею судеб, теперь хорошо знаю дерби и переходить, скорее всего не буду.
Это уже очень интересно, с появлением юнит-тестов должно появится некостыльное решение. Как минимум стоит поставить дерби на мониторинг. Пока метеор вроде меня устраивает, в дерби главным вопросом для меня был jade. Другой важный вопрос — юнит и функциональное тестирование, на подобии cucumber, но с этим как я понял и у метеора не очень.
Сам фреймворк очень хорошо поделен на модули, почти все покрыты тестами. Используется mocha. Мы в своих проектах тоже используем mocha, а так же casper-mocha для тестирования производительности в браузере.
Для dependency-injection модели используется модуль racer-fixtures.
Для dependency-injection модели используется модуль racer-fixtures.
Я, кстати, habrahabr.ru/post/221027/ написал — там есть немного о текущем состоянии derby.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш взгляд: Meteor против Derby