Железная дорога против TowerJS
Опять... выбираем рамки. Я остановился на этих двух TowerJS и RailwayJS, но швы они очень похожи, и очень трудно выбрать какой путь
Оба основаны на Express, оба являются фреймворками в стиле RoR...
Какой из них наиболее перспективный, какой будет более популярным?
А может я уже на неверном пути? Может быть, я должен выбрать другие рамки.
Я ненавижу, когда есть так много фреймворков на выбор, нет отраслевого стандарта, на который можно было бы положиться, чтобы быть более или менее уверенным в том, что фреймворк будет разработан в ближайшие пару лет...
Пожалуйста, помогите, нужно предложение эксперта. Спасибо
4 ответа
Вот краткая таблица к обзору, я расскажу о некоторых вещах ниже.
+ ----------------------- + ------------------------- ----- + ------------------------------------ + | | Железная дорога JS | Tower.js |
+-----------------------+------------------------------+------------------------------------+
| Первый коммит | Январь 2011 | Окт 2011 |
| Рельсы | 2.3.x | 3.x |
| Node.js | >= 0.4.x | >= 0.4.x |
| Сервер | ✓ | ✓ |
| Клиент | | ✓ |
| Шаблон агностика | ✓ | ✓ |
| Движок по умолчанию | EJS | CoffeeKup |
| База данных Агностик | ✓ | ✓ |
| Хранилище данных по умолчанию | MongoDB | MongoDB |
| Проверка моделей | validatesPresenceOf('email') | проверяет ("электронная почта", наличие: true) | | Области запросов | ✓ | ✓ |
| Цепные прицелы | | ✓ |
| Парс парсинг | | ✓ |
| Контроллеры | ✓ | ✓ |
| Контроллеры ресурсов | | ✓ |
| Наименование файла | users_controller.js | usersController.coffee | | vm.runInCustomContext | ✓ | |
| Актив трубопроводов | | ✓ |
| Сжатие активов | | ✓ |
| Маршрутизация | map.resources('posts') | @resources 'posts' |
| Вложенные маршруты | ✓ | ✓ |
| Сгенерированные помощники URL | ✓ | |
| Генераторы | ✓ | ✓ |
| API командной строки | ✓ | ✓ |
| REPL (консоль) | ✓ | ✓ |
| Консоль CoffeeScript | | ✓ |
| Метод кэширования активов | метка времени | хэш md5 | | Путь производственных активов | /app.css?123123123 | /app-859c828c89288hc8918741.css |
| Предпочитаемый язык | JavaScript | CoffeeScript |
| Поддержка CoffeeScript | ✓ | ✓ |
| Интернационализация | ✓ | ✓ |
| Поддержка Heroku | ✓ | ✓ |
| Строковый кейс | случай змеи | CamelCase | | Форма строитель | ✓ | ✓ |
| Конструктор семантических форм | | ✓ |
| Стол строительный | | ✓ |
| API для просмотра файлов | | ✓ |
| Live-перезагрузить активы | | ✓ |
| Тестовый набор | | ✓ |
| Генераторы для испытаний | | ✓ |
| Twitter Bootstrap | ✓ | ✓ |
| HTML5 Boilerplate | | ✓ |
+-----------------------+------------------------------+------------------------------------+ Я создал Tower.js для достижения нескольких целей, которые ни одна из существующих платформ не сделала адекватно. Вот некоторые из этих целей.
1. Одинаковый код на клиенте и сервере
Поскольку Node.js сделал возможным JavaScript на сервере, нет причин писать одну часть приложения в Rails, а другую - в Backbone. Это ничего, кроме СУХОГО. Вы должны быть в состоянии определить модели один раз и использовать их как на клиенте, так и на сервере.
RailwayJS работает только на сервере, потому что он построен на экспрессе. Tower.js также построен на основе Express, но таким образом, что он работает как для клиента, так и для сервера. Tower.js предоставляет одинаковый API для клиента и сервера. Это означало, что мне пришлось переписать некоторые вещи, такие как маршрутизатор, чтобы он работал одинаково на клиенте и сервере (плюс он позволяет вам делать такие вещи, как history.pushState с # отступление, используя тот же набор маршрутов).
2. Одинаковые "просмотры" на клиенте и сервере
Я провел много времени в Rails и писал шаблоны для Haml. Наряду с этим я писал веб-интерфейсы и интерфейсы JavaScript для мобильных устройств, используя языки шаблонов, такие как усы. Это больше дублирования кода... Вы должны иметь возможность использовать один и тот же набор представлений / шаблонов как на клиенте (как шаблоны JavaScript), так и на сервере (визуализация статического HTML).
Поскольку Haml был довольно крутым (супер чистым, позволяющим выполнять произвольный ruby, встроенным в pretty-printing и т. Д.), Ближайшей альтернативой JavaScript был CoffeeKup. И это работает как на клиенте, так и на сервере. CoffeeKup позволяет вам писать шаблоны со всей мощью JavaScript, поэтому у вас нет никаких ограничений. Построение FormBuilder в Mustache потребует либо много работы, либо кода, либо и того, и другого.
Обратите внимание, что вы можете свободно менять шаблоны и использовать Jade, Mustache, Handlebars и т. Д. Для клиента или сервера. CoffeeKup - это просто чистый и мощный стандарт.
3. Rails-модель качества API на клиенте и сервере
ActiveModel (реализованный ActiveRecord для SQL и Mongoid для MongoDB для Rails) - это очень тщательный и хорошо протестированный API, позволяющий разработчикам определять и взаимодействовать с данными. Это одновременно и мощно, и приятно. Все предыдущие (и текущие) реализации JavaScript никогда не были настолько прочными и хорошо продуманными, и я не видел, чтобы что-то происходило в ближайшем будущем.
Если вы можете написать это в Rails:
User.where(:email => /[a-z/).page(2).limit(20)
Вы должны быть в состоянии сделать это в JavaScript:
App.User.where(email: /[a-z/).page(2).limit(20)
Tower.js поставляется с "цепочечными областями", что означает хардкорные запросы + разбиение на страницы. Он смоделирован после API запросов MongoDB, но этот "ввод" API преобразуется в соответствующие команды базы данных для разных хранилищ данных.
4. Единый интерфейс к хранилищам данных SQL и NoSQL.
В настоящее время Tower.js имеет хранилище MongoDB и Memory (в браузере) и стремится предоставить единый интерфейс для остальных популярных баз данных (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra и т. Д.).
RailwayJS, кажется, делает это также через JugglingDB, и это выглядит как хорошее начало. Но я решил не использовать его по нескольким причинам. Во-первых, похоже, что он строится вокруг Rails 2.x API (User.validatesUniquenessOf "email" против User.validates "email", presence: true). Во-вторых, он не обладает богатством цепных запросов, как в Rails 3. В-третьих, я хочу иметь возможность быстро добавлять код в кодовую базу, и, поскольку я очень разборчив, я, вероятно, в конечном итоге реорганизовал бы весь процесс, чтобы использовать CoffeeScript, ха-ха. И я не хочу строить слой вокруг этого, потому что он должен работать и на клиенте, поэтому сохранение библиотечной архитектуры на минимальном уровне является первоочередной задачей.
5. Находчивые контроллеры
Драгоценный камень ruby_redources вырезал около 90% кода из моих контроллеров Rails. Он выяснил ряд соглашений для реализации 7 основных действий контроллера. Tower.js включает в себя что-то вроде этого, поэтому по умолчанию вам не нужно писать какой-либо код в ваших контроллерах, они все равно будут отвечать JSON и HTML. Это также позволяет определить вложенные маршруты.
6. Автоматический парсер запросов к базе данных
В Tower.js вы можете указать контроллеру следить за определенными параметрами в URL, и он преобразует их в хеш, готовый для применения к модельному запросу.
class App.UsersController extends App.ApplicationController
@param "email"
index: ->
App.User.where(@criteria()).all (error, users) =>
@respondTo (format) =>
format.json => @render json: users
format.html => @render "index", locals: {users}
Учитывая URL, который как /users?email=abc&something=random, затем @criteria() даст вам хэш {email: /abc/},
Это не в Rails, но я бы хотел, чтобы это было.
7. Семантические формы
Я супер в семантическом HTML. Конструктор форм Rails генерирует довольно уродливый HTML, поэтому многие люди, как и я, использовали Formtastic, который генерирует больше семантических форм. Tower.js использует почти тот же API, что и Formtastic. Он также имеет конструктор семантических таблиц, который позволяет довольно легко создавать таблицы с возможностью поиска / сортировки для представлений администратора.
8. Актив Трубопровод
В Rails 3 был потрясающий конвейер ресурсов, где вы можете написать свой JavaScript на CoffeeScript, свой CSS в SCSS, и он будет автоматически перекомпилирован. затем rake assets:precompile ваши активы, и вы получите готовые md5 хэшированные gzipped активы для S3. Это довольно сложно создать самостоятельно, и я не видел, чтобы кто-то работал над этим для Node.js.
RailwayJS использует метод Rails 2 для отметки времени пути ресурса, поэтому вместо этой версии с хэшированием md5:
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
Вы получите что-то вроде этого:
/stylesheets/application.css?1306993455524
Это проблема по нескольким важным причинам. В Rails Asset Pipeline Guide есть детали, но главное, что S3 не распознает временную метку, поэтому он читает /stylesheets/application.css, и если вы установите далекое будущее Expires заголовок, и вы изменили свой CSS, любой, кто посещал ваш сайт раньше, должен будет очистить свой кэш или принудительно обновить вашу страницу, чтобы увидеть обновления.
RailwayJS также не имеет встроенного конвейера компиляции активов (по крайней мере, насколько мне известно).
9. Часовой файл
Guard был огромным средством повышения производительности в Rails. Это позволило вам быстро создавать "контрольные задачи", в основном, такие как задачи с граблями / тортом, которые выполнялись, когда файл, соответствующий шаблону, был создан / обновлен / удален.
В башню это встроено (используется design.io). Это на самом деле то, что говорит активация CoffeeScript и Stylus для компиляции в JavaScript и CSS. Но вы можете делать очень мощные вещи с помощью этой функции, см. Примеры https://github.com/guard/guard/wiki/List-of-available-Guards.
10. CoffeeScript
Большой поклонник CoffeeScript.
CoffeeScript сокращает объем JavaScript, о котором вам нужно написать, вдвое ( 6 501 добавление, 15 896 удалений, преобразующих всю библиотеку Node.js в CoffeeScript). И это делает кодирование намного быстрее и проще.
Кроме того, CoffeeScript - это единственный способ сохранить продуктивный и приятный опыт написания кода, который Rails продемонстрировал миру. JavaScript просто не делает этого.
Маленькие вещи
Я фанат стандартов. RailwayJS придерживался соглашения Ruby об использовании snake_case, и я тоже хотел это сделать, но сообщество JavaScript использует camelCase, так что Tower согласился с этим. У CamelCase также есть несколько дополнительных преимуществ, таких как то, что вам не нужно конвертировать серверный Rails snake_case в / из camelCase для клиента, а удаление этого дополнительного символа дает вам крошечный файл меньшего размера.
Я также влюблен в супер чистый код. Прежде чем рассмотреть возможность участия в проекте, я прочитал исходный код... и, если он очень грязный, я, вероятно, просто переписал бы его.
Я также люблю оптимизировать код. С Tower.js большая цель состоит в том, чтобы структурировать его так, чтобы он делал все, что делает Rails, предоставляя одинаковый API как на клиенте, так и на сервере, используя минимально возможный объем кода. Хотя есть компромисс между минимизацией размера кодовой базы и написанием кода, который понятен и интересен / продуктивен в использовании. Все еще находя способы получить лучшее из обоих миров.
Я определенно в этом и надолго. Это основа нашей компании, и все, что я лично буду строить в будущем. Я хочу перейти к тому моменту, когда вы сможете за день выкачивать красиво разработанное, функциональное и высоко оптимизированное приложение.
Надеюсь, это поможет.
Вы обратили внимание на Derbyjs? Этот, хотя еще не бета, довольно захватывающий. Его автором является бывший сотрудник Google и автор Everyauth. Вам придется написать минимальный Javascript на стороне клиента с этим. Смотрите выдержки из официальной страницы:
Почему бы не использовать Rails и Backbone? Derby представляет новое поколение каркасов приложений, которые, как мы полагаем, заменят популярные в настоящее время библиотеки, такие как Rails и Backbone.
Добавление динамических функций в приложения, написанные с использованием Rails, Django и других серверных сред, приводит к путанице. Код сервера отображает различные начальные состояния, в то время как селекторы и обратные вызовы jQuery отчаянно пытаются разобраться в DOM и пользовательских событиях. Добавление новых функций обычно включает в себя изменение как серверного, так и клиентского кода, часто на разных языках.
Многие разработчики теперь включают в себя клиентскую инфраструктуру MVC, такую как Backbone, чтобы лучше структурировать клиентский код. Некоторые из них начали использовать декларативные библиотеки привязки представления модели, такие как Knockout и Angular, чтобы уменьшить стандартные манипуляции с DOM и привязки событий. Это отличные концепции, и добавление некоторой структуры, безусловно, улучшает клиентский код. Однако они по-прежнему приводят к дублированию кода рендеринга и ручной синхронизации изменений во все более сложных серверных и клиентских кодах. Мало того, каждая из этих частей должна быть вручную соединена и упакована для клиента.
Дерби радикально упрощает этот процесс добавления динамических взаимодействий. Он запускает один и тот же код на серверах и в браузерах и автоматически синхронизирует данные. Derby позаботится о визуализации шаблонов, упаковке и привязках вида модели из коробки. Поскольку все функции предназначены для совместной работы, дублирование кода и склеивание кода не требуются. Derby готовит разработчиков на будущее, когда все данные во всех приложениях отображаются в реальном времени.
Гибкость без склеивания кода Derby устраняет утомительную необходимость соединить сервер, механизм шаблонирования сервера, компилятор CSS, упаковщик сценариев, минификатор, клиентскую среду MVC, клиентскую библиотеку JavaScript, механизм шаблонирования и / или привязки клиента, библиотеку истории клиента, транспорт в реальном времени, ORM и база данных. Это устраняет сложность синхронизации состояния между моделями и представлениями, клиентами и серверами, несколькими окнами, несколькими пользователями, а также моделями и базами данных.
В то же время он хорошо сочетается с другими. Derby построен на основе популярных библиотек, включая Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB и вскоре других популярных баз данных и хранилищ данных. Эти библиотеки также могут быть использованы напрямую. Уровень синхронизации данных, Racer, может использоваться отдельно. Другие клиентские библиотеки, такие как jQuery и другие модули Node.js из npm, работают так же хорошо, как и Derby.
При следовании файловой структуре по умолчанию шаблоны, стили и сценарии автоматически упаковываются и включаются в соответствующие страницы. Кроме того, Derby может использоваться через динамический API, как видно из простого примера выше.
Но это также идет со следующим отказом от ответственности
Derby и Racer - альфа-программа. Хотя Derby должен работать достаточно хорошо для создания прототипов и проектов выходного дня, он все еще находится в стадии разработки. API могут быть изменены.
У него пока нет реализации авторизации, и это чревато проблемами безопасности, хотя о них будет позаботиться в ближайшие месяцы. Если вы можете подождать несколько месяцев, это будет многообещающей основой.
Выбор основы сводится к вашему уровню комфорта с ним.. обычно на основе..
Насколько активен проект? Когда был последний коммит? Если это не на github, то это меня беспокоит, так как это усложняет работу пользователей.
Сколько сообщений в блоге я могу найти в рамках? Если никто не говорит об этом, это, как правило, плохой знак, поскольку люди, естественно, говорят о вещах, которые их волнуют.
Что я думаю о структуре? Об этом может быть сложнее судить, но примеров должно быть достаточно, чтобы вы могли получить хотя бы базовую идею. Если нет, то это само по себе является большой проблемой.
Хм.. конечно очевидный вопрос, если вы хотите инфраструктуру RoR.. почему бы просто не использовать RoR?;)
Похоже, что TowerJS более тесно связана с MongoDB в качестве хранилища данных, тогда как RailwayJS, похоже, обладает гибкостью адаптера модели. Это может повлиять на ваш выбор между двумя. Лично я бы предпочел писать сайты на Rails, используя RoR. Кажется, Node больше подходит для разных видов услуг, не так ли? (Я думаю, Backbone в клиенте с сервисами AJAX REST).