Железная дорога против TowerJS

Ответ 1

Вот краткая таблица к обзору, я расскажу о некоторых вещах ниже.

+-----------------------+------------------------------+------------------------------------+
|                       | RailwayJS                    | Tower.js                           |
+-----------------------+------------------------------+------------------------------------+
| First commit          | Jan 2011                     | Oct 2011                           |
| Rails                 | 2.3.x                        | 3.x                                |
| Node.js               | >= 0.4.x                     | >= 0.4.x                           |
| Server                | ✓                            | ✓                                  |
| Client                |                              | ✓                                  |
| Template agnostic     | ✓                            | ✓                                  |
| Default engine        | EJS                          | CoffeeKup                          |
| Database agnostic     | ✓                            | ✓                                  |
| Default datastore     | MongoDB                      | MongoDB                            |
| Model validations     | validatesPresenceOf('email') | validates('email', presence: true) |
| Query scopes          | ✓                            | ✓                                  |
| Chainable scopes      |                              | ✓                                  |
| Param parsing         |                              | ✓                                  |
| Controllers           | ✓                            | ✓                                  |
| Resource controllers  |                              | ✓                                  |
| File naming           | users_controller.js          | usersController.coffee             |
| vm.runInCustomContext | ✓                            |                                    |
| Asset pipeline        |                              | ✓                                  |
| Asset compression     |                              | ✓                                  |
| Routing               | map.resources('posts')       | @resources 'posts'                 |
| Nested routes         | ✓                            | ✓                                  |
| Generated url helpers | ✓                            |                                    |
| Generators            | ✓                            | ✓                                  |
| Command-line api      | ✓                            | ✓                                  |
| REPL (console)        | ✓                            | ✓                                  |
| CoffeeScript console  |                              | ✓                                  |
| Asset cache method    | timestamp                    | md5 hash                           |
| Production asset path | /app.css?123123123           | /app-859c828c89288hc8918741.css    |
| Preferred Language    | JavaScript                   | CoffeeScript                       |
| CoffeeScript support  | ✓                            | ✓                                  |
| Internationalization  | ✓                            | ✓                                  |
| Heroku support        | ✓                            | ✓                                  |
| String case           | snake_case                   | camelCase                          |
| Form builder          | ✓                            | ✓                                  |
| Semantic form builder |                              | ✓                                  |
| Table builer          |                              | ✓                                  |
| File watcher API      |                              | ✓                                  |
| Live-reload assets    |                              | ✓                                  |
| Test suite            |                              | ✓                                  |
| Generators for tests  |                              | ✓                                  |
| Twitter Bootstrap     | ✓                            | ✓                                  |
| HTML5 Boilerplate     |                              | ✓                                  |
+-----------------------+------------------------------+------------------------------------+

Я создал Tower.js для достижения нескольких целей, которые ни одна из существующих структур не сделала адекватно. Вот некоторые из этих целей.

1. Тот же код на клиенте и сервере

Так как Node.js сделал JavaScript возможным на сервере, нет причин писать одну часть приложения в Rails, а другую в Backbone. Это ничего, кроме СУХИХ. Вы должны иметь возможность определять модели один раз и использовать их как на клиенте, так и на сервере.

RailwayJS работает только на сервере, потому что он построен вокруг express. Tower.js также построена вокруг экспресс, но таким образом, что она работает как для клиента, так и для сервера. Tower.js предоставляет тот же самый точный API для клиента и сервера. Это означало, что мне пришлось переписывать некоторые вещи, такие как маршрутизатор, поэтому он работает одинаково на клиенте и на сервере (плюс он позволяет вам делать такие вещи, как history.pushState с резервным #, используя тот же набор маршрутов).

2. Те же "представления" на клиенте и сервере

Я провел много времени в Rails и писал шаблоны Haml. Наряду с этим я писал веб-и мобильные интерфейсы JavaScript, используя языки шаблонов, такие как Mustache. Это больше дублирования кода... Вы должны иметь возможность использовать один и тот же набор представлений/шаблонов как для клиента (как шаблоны JavaScript), так и для сервера (рендеринг статического HTML).

Так как Haml был довольно удивительным (супер чистый, позволил вам выполнить произвольный рубин, построенный в довольно-печатной форме и т.д.), ближайшая альтернатива JavaScript была CoffeeKup. И он работает как на клиенте, так и на сервере. CoffeeKup позволяет писать шаблоны со всей мощью JavaScript, поэтому у вас нет ограничений. Построение FormBuilder в Mustache либо будет занимать много работы, либо много кода, либо и то, и другое.

Обратите внимание, что вы можете поменять местами механизмы шаблонов и использовать Jade, Mustache, Handlebars и т.д. для клиента или сервера. CoffeeKup - это просто чистый и мощный по умолчанию.

3. API-интерфейс модели качества Rails на клиенте и сервере

ActiveModel (реализованный ActiveRecord для SQL и Mongoid для MongoDB for 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, но этот "enter" API преобразуется в соответствующие команды базы данных для разных хранилищ данных.

4. Равномерный интерфейс к хранилищам данных SQL и NoSQL

В настоящее время Tower.js имеет хранилище MongoDB и Memory (in-browser), и оно обеспечивает равномерный интерфейс для остальной части популярных баз данных (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra и т.д.).

RailwayJS, похоже, делает это также через JugglingDB, и это похоже на хороший старт. Но я решил не использовать его по нескольким причинам. Во-первых, похоже, что он строится вокруг Rails 2.x API (User.validatesUniquenessOf "email" vs. User.validates "email", presence: true). Во-вторых, у него нет богатых цепочек запросов, которые Rails 3 делает. В-третьих, я хочу быстро добавить код в кодовую базу, и, поскольку я очень разборчивый, я бы, вероятно, в конечном итоге реорганизовал все, чтобы использовать CoffeeScript, ха-ха. И я не хочу создавать слой вокруг этого, потому что он должен работать и с клиентом, поэтому сохранение минимальной минимальной архитектуры библиотеки является высоким приоритетом.

5. Находчивые контроллеры

inherited_resources Ruby gem вырезал около 90% кода из моих контроллеров Rails. Он разработал набор соглашений для реализации 7 основных действий контроллера. Tower.js включает что-то вроде этого, поэтому по умолчанию вам не нужно писать какой-либо код в контроллерах, он все равно будет отвечать JSON и HTML. Это также делает так, что вы можете определить вложенные маршруты.

6. Автоматический анализатор запросов URL-базы данных

В 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. Это позволило вам быстро создавать "задачи просмотра", по сути, такие как задачи rake/cake, которые выполнялись, когда был создан/обновлен/удален файл, соответствующий шаблону.

Башня построена таким образом (используя 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 как на клиенте, так и на сервере, используя минимальный возможный код. Там есть компромисс между минимизацией размера кодовой базы и написанием кода, который является понятным и забавным/продуктивным в использовании. Все еще находить способы получить лучшее из обоих миров.

Я определенно в этом и для дальних. Это основа для нашей компании и все, что я лично буду строить в будущем. Я хочу дойти до того момента, когда вы сможете выкачать красивое, функциональное и высоко оптимизированное приложение за день.

Надеюсь, что это поможет.

Ответ 2

Вы обратили внимание на Derbyjs? Этот, хотя еще не бета, довольно увлекательный. Он создается сотрудником ex google и автором everyauth. Вам придется писать минимальный клиентский javascript с этим. Смотрите выдержки из официальной страницы:

Почему бы не использовать Rails и Backbone? Derby представляет новую породу приложения, которые, как мы полагаем, популярные библиотеки, такие как Rails и Backbone.

Добавление динамических функций в приложения, написанные с помощью Rails, Django и других серверные фреймворки имеют тенденцию создавать запутанный беспорядок. Код сервера отображает различные начальные состояния, в то время как селекторы jquery и обратные вызовы отчаянно пытаются осмыслить DOM и пользовательские события. Добавление новые функции обычно включают в себя изменение кода сервера и клиента, часто на разных языках.

Многие разработчики теперь включают в себя клиентскую структуру MVC, такую ​​как Backbone to лучше структурировать клиентский код. Некоторые из них начали использовать декларативные библиотеки привязки модели-просмотра, такие как Knockout и Angular, чтобы уменьшить шаблонные манипуляции с DOM и привязки событий. Это здорово концепции и добавление некоторой структуры, безусловно, улучшает клиентский код. Однако они по-прежнему приводят к дублированию кода рендеринга и вручную синхронизация изменений во все более сложном сервере и клиентском коде основы. Не только это, каждая из этих частей должна быть вручную подключена вместе и упакованы для клиента.

Derby радикально упрощает этот процесс добавления динамических взаимодействия. Он выполняет тот же код на серверах и в браузерах, и он синхронизирует данные автоматически. Derby заботится о рендеринге шаблонов, упаковки и привязки к виду модели. Поскольку все функции предназначены для совместной работы, без дублирования кода и кода клея необходимо. Derby предоставляет разработчикам будущее, когда все данные во всех приложениях в реальном времени.

Гибкость без кода клея Derby устраняет скуку проводка вместе сервера, сервера templating engine, компилятора CSS, script packager, minifier, клиентская среда MVC, клиентский JavaScript библиотека, клиентский шаблон и/или механизм привязок, история клиентов библиотека, транспорт в реальном времени, ORM и база данных. Он устраняет сложность сохранения состояния, синхронизированного между моделями и представлениями, клиентов и серверов, нескольких окон, нескольких пользователей и моделей и базы данных.

В то же время он хорошо работает с другими. Derby построен поверх популярные библиотеки, в том числе Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB, и вскоре другие популярные базы данных и датасторы. Эти библиотеки также можно использовать напрямую. Данные уровень синхронизации, Racer, может использоваться отдельно. Другой клиент библиотеки, такие как jQuery и другие Node.js модули из работы npm так же хорошо, как и Дерби.

При использовании структуры файлов по умолчанию, шаблонов, стилей и сценарии автоматически упаковываются и включаются в соответствующие страницы. Кроме того, Derby можно использовать с помощью динамического API, как видно из простой пример выше.

Но он также поставляется с следующим отказом

Derby и Racer - это альфа-программное обеспечение. Хотя Дерби должен хорошо работать достаточно для прототипирования и проектов на выходные дни, он все еще проходит основное развитие. API могут быть изменены.

У него пока нет реализации авторизации и чревато проблемами безопасности , хотя они будут позабочены в ближайшие месяцы. Если вы можете подождать несколько месяцев, это кажется перспективной основой.

Ответ 3

Выбор рамки сводится к вашему уровню комфорта с ней.. обычно на основе..

• Насколько активен проект? Когда была последняя фиксация? Если это не на github, это вызывает у меня непосредственную заботу, поскольку это делает вклад пользователя более сложным.

• Сколько сообщений в блоге можно найти в структуре? Если никто не говорит об этом, это обычно плохой знак, поскольку люди, естественно, говорят о вещах, которые их волнуют.

• Что я думаю о структуре? Это может быть труднее судить, но там должно быть достаточно примеров, по крайней мере, вы можете получить базовую идею. Если нет, то это само по себе является большой проблемой.

Erm.. Конечно, очевидный вопрос заключается в том, хотите ли вы создать структуру RoR.. почему бы просто не использовать RoR?;)

Ответ 4

Похоже, что TowerJS более тесно связан с MongoDB в качестве хранилища данных, в то время как RailwayJS, похоже, обладает гибкостью адаптера модели. Это может повлиять на ваш выбор между ними. Лично я бы решил писать Rails-сайты с использованием RoR. Node, похоже, больше поддается различным видам услуг, как вы думаете? (Я думаю, что Backbone в клиенте с услугами AJAX REST).