RailwayJS 대 TowerJS

RailwayJS 대 TowerJS

---

다시 ... 프레임 워크 선택. 이 두 TowerJS와 RailwayJS에서 멈췄지만 이음새가 매우 유사하고 어떤 방법을 선택하는 것이 매우 어렵습니다

둘 다 Express를 기반으로하며 둘 다 RoR 스타일 프레임 워크입니다.

어느 것이 가장 유망하고 어느 것이 더 인기가 있습니까?

아니면 이미 잘못된 길을 가고 있습니까? 다른 프레임 워크를 선택해야 할 수도 있습니다.

선택할 수있는 프레임 워크가 너무 많고, 신뢰할 수있는 업계 표준이없는 경우, 프레임 워크가 가까운 몇 년 안에 개발 될 것이라는 확신을 가질 수있는 것이 싫습니다.

전문가의 제안이 필요합니다. 감사

---

다음은 개요에 대한 간략한 표입니다. 아래에서 몇 가지 사항에 대해 설명하겠습니다.

+ ----------------------- + ------------------------- ----- + ------------------------------------ +
| | RailwayJS | Tower.js |
+ ----------------------- + ------------------------- ----- + ------------------------------------ +
| 첫 번째 커밋 | 2011 년 1 월 | 2011 년 10 월 |
| 레일 | 2.3.x | 3.x |
| Node.js | > = 0.4.x | > = 0.4.x |
| 서버 | ✓ | ✓ |
| 클라이언트 | | ✓ |
| 템플릿 불가지론 | ✓ | ✓ |
| 기본 엔진 | EJS | CoffeeKup |
| 데이터베이스 불가지론 | ✓ | ✓ |
| 기본 데이터 스토어 | MongoDB | MongoDB |
| 모델 검증 | validatesPresenceOf ( 'email') | validates ( 'email', 현재 상태 : true) |
| 쿼리 범위 | ✓ | ✓ |
| 체인 가능 범위 | | ✓ |
| 매개 변수 구문 분석 | | ✓ |
| 컨트롤러 | ✓ | ✓ |
| 리소스 컨트롤러 | | ✓ |
| 파일 이름 지정 | users_controller.js | usersController.coffee |
| vm.runInCustomContext | ✓ | |
| 자산 파이프 라인 | | ✓ |
| 자산 압축 | | ✓ |
| 라우팅 | map.resources ( 'posts') | @resources '게시물'|
| 중첩 된 경로 | ✓ | ✓ |
| 생성 된 URL 도우미 | ✓ | |
| 발전기 | ✓ | ✓ |
| 명령 줄 API | ✓ | ✓ |
| REPL (콘솔) | ✓ | ✓ |
| CoffeeScript 콘솔 | | ✓ |
| 자산 캐시 방법 | 타임 스탬프 | md5 해시 |
| 생산 자산 경로 | /app.css?123123123 | /app-859c828c89288hc8918741.css |
| 선호하는 언어 | 자바 스크립트 | CoffeeScript |
| CoffeeScript 지원 | ✓ | ✓ |
| 국제화 | ✓ | ✓ |
| Heroku 지원 | ✓ | ✓ |
| 문자열 케이스 | snake_case | camelCase |
| 양식 작성기 | ✓ | ✓ |
| 시맨틱 양식 작성기 | | ✓ |
| 테이블 빌더 | | ✓ |
| 파일 감시자 API | | ✓ |
| 라이브 리로드 자산 | | ✓ |
| 테스트 스위트 | | ✓ |
| 테스트 용 발생기 | | ✓ |
| 트위터 부트 스트랩 | ✓ | ✓ |
| HTML5 상용구 | | ✓ |
+ ----------------------- + ------------------------- ----- + ------------------------------------ +

저는 기존 프레임 워크 중 어느 것도 제대로하지 못했던 몇 가지 목표를 달성하기 위해 Tower.js를 만들었습니다. 다음은 이러한 목표 중 일부입니다.

1. 클라이언트와 서버에서 동일한 코드

Node.js는 서버에서 자바 스크립트를 가능하게했기 때문에 앱의 한 부분을 Rails에 작성하고 다른 부분을 Backbone에 작성할 이유가 없습니다. 그건 DRY가 아닙니다. 모델을 한 번 정의하고 클라이언트와 서버 모두에서 사용할 수 있어야합니다.

RailwayJS는 Express를 중심으로 구축 되었기 때문에 서버에서만 작동합니다. Tower.js는 또한 Express를 중심으로 구축되었지만 클라이언트와 서버 모두에서 작동하도록합니다. Tower.js는 클라이언트와 서버에 동일한 API를 제공합니다. 이 의미 나는 클라이언트와 서버에서 동일하게 작동하도록 라우터와 같은 몇 가지를 다시 작성했다 (플러스 그것은 당신이 같은 일을 수행 할 수 있습니다 history.pushState와 #경로의 동일한 세트를 사용하여 대체).

2. 클라이언트와 서버에서 동일한 "보기"

저는 Rails에서 많은 시간을 보냈고 Haml 템플릿을 작성했습니다. 그와 함께 Mustache와 같은 템플릿 언어를 사용하여 웹 및 모바일 JavaScript 인터페이스를 작성했습니다. 이는 더 많은 코드 중복입니다. 클라이언트 (JavaScript 템플릿)와 서버 (정적 HTML 렌더링) 모두에서 동일한 뷰 / 템플릿 세트를 사용할 수 있어야합니다.

Haml은 꽤 멋 졌기 때문에 (매우 깨끗하고, 임의의 루비를 실행할 수 있고, pretty-printing 등으로 빌드되었습니다.) 가장 가까운 JavaScript 대안은 CoffeeKup 입니다. 그리고 그것은 클라이언트와 서버 모두에서 작동합니다. CoffeeKup을 사용하면 JavaScript의 모든 기능으로 템플릿을 작성할 수 있으므로 제한이 없습니다. Mustache에서 FormBuilder를 빌드하려면 많은 작업이나 많은 코드 또는 둘 다가 필요합니다.

하지만 클라이언트 또는 서버에 템플릿 엔진을 교체하고 Jade, Mustache, Handlebars 등을 자유롭게 사용할 수 있습니다. CoffeeKup은 깨끗하고 강력한 기본값입니다.

3. 클라이언트 및 서버의 Rails 품질 모델 API

ActiveModel (ActiveRecord for SQL 및 Mongoid for 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는 하드 코어 쿼리 + 페이지 매김을 의미하는 "체인 가능한 범위"와 함께 제공됩니다. MongoDB Query API를 모델로 했지만이 API "입력"은 다른 데이터 저장소에 대한 적절한 데이터베이스 명령으로 변환됩니다.

4. SQL 및 NoSQL 데이터 저장소에 대한 통일 된 인터페이스

Tower.js currently has a MongoDB and Memory (in-browser) store, and aims to provide a uniform interface to the rest of the popular databases (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra, etc.).

RailwayJS는 JugglingDB를 통해서도이 작업을 수행하는 것으로 보이며 좋은 시작처럼 보입니다. 그러나 나는 몇 가지 이유로 그것을 사용하지 않기로 결정했습니다. 첫째, Rails 2.x API ( User.validatesUniquenessOf "email"vs. User.validates "email", presence: true)를 기반으로 구축 된 것처럼 보입니다 . 둘째, Rails 3가 수행하는 풍부한 연결 쿼리가 없습니다. 셋째, 코드베이스에 코드를 빠르게 추가 할 수 있기를 원하고, 매우 까다롭기 때문에 아마도 CoffeeScript를 사용하기 위해 모든 것을 리팩토링하게 될 것입니다. 하하. 클라이언트에서도 작동해야하므로이를 중심으로 레이어를 구축하고 싶지 않습니다. 따라서 라이브러리 아키텍처를 가능한 한 최소화하는 것이 최우선 순위입니다.

5. 수완이 풍부한 컨트롤러

inherited_resources 루비 보석 내 레일 컨트롤러의 코드의 90 %에 대해 잘라. 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. 의미 론적 형태

I'm super into semantic HTML. Rails' form builder generates pretty ugly HTML, so many people as well as myself used Formtastic, which generates more semantic forms. Tower.js uses pretty much the same API as Formtastic. It also has a semantic table builder, which makes it pretty easy to build searchable/sortable tables for admin views.

8. Asset Pipeline

Rails 3 had an awesome asset pipeline, where you could write your JavaScript in CoffeeScript, your CSS in SCSS, and it would automatically recompile. Then rake assets:precompile your assets and you'd get md5-hashed gzipped assets ready for S3. That's pretty hard to build out yourself, and I didn't see anyone working on that for Node.js.

RailwayJS uses the Rails 2 method of timestamping the asset path, so instead of this md5-hashed version:

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

You'd get something like this:

/stylesheets/application.css?1306993455524

This is a problem for a few important reasons. The Rails Asset Pipeline Guide has the details, but the big thing is S3 doesn't recognize the timestamp, so it's reading /stylesheets/application.css, and if you set a far-future Expires header and you've changed your CSS, anyone who visited your site before will have to purge their cache or force-refresh your page to see the updates.

RailwayJS also doesn't have the built in asset compilation pipeline (at least to my knowledge).

9. The Watchfile

Guard was a huge productivity booster in Rails. It allowed you to write quick "watch tasks", essentially like rake/cake tasks, that ran when a file matching a pattern was created/updated/deleted.

Tower has this built in (using design.io). This is actually what's telling the CoffeeScript and Stylus assets to compile into JavaScript and CSS. But you can do very powerful things with this feature, see https://github.com/guard/guard/wiki/List-of-available-Guards for examples.

10. CoffeeScript

Big fan of CoffeeScript.

CoffeeScript cuts the amount of JavaScript you need to write about in half (6,501 additions, 15,896 deletions converting the entire Node.js library to CoffeeScript). And it makes coding much faster and easier.

Also, CoffeeScript is the only way to keep that productive and enjoyable coding experience that Rails showed the world. JavaScript just doesn't do that.

The little things

I'm a fan of standards. RailwayJS stuck to the Ruby convention of using snake_case, and I wanted to do that too, but the JavaScript community uses camelCase so Tower went with that. CamelCase has a few added benefits as well, such as you don't need to convert server-side Rails snake_case to/from camelCase for the client, and removing that extra character gives you a tiny smaller file size.

I'm also in love with super clean code. Before I consider contributing to a project, I read through the source code... and if it's super messy, I'm probably just going to rewrite it.

I also love optimizing code. With Tower.js, a big goal is to structure it so it does everything that Rails does, providing the exact same API in both the client and server, using the minimal amount of code possible. There's a tradeoff though between minimizing the size of the codebase and writing code that's clear and fun/productive to use. Still finding ways to get the best of both worlds.

I'm definitely in this for the long-haul as well. This is the foundation for our company, and everything I personally will build in the future. I want to get to the point where you can pump out a nicely designed, functional, and highly optimized app in a day.

Hope that helps.

---

Have you paid attention to Derbyjs? This one although not yet beta, is quite exciting. It is being authored by an ex google employee and the author of everyauth. You will have to write minimal client side javascript with this one. See the excerpts taken from the official page:

Why not use Rails and Backbone? Derby represents a new breed of application frameworks, which we believe will replace currently popular libraries like Rails and Backbone.

Adding dynamic features to apps written with Rails, Django, and other server-side frameworks tends to produce a tangled mess. Server code renders various initial states while jQuery selectors and callbacks desperately attempt to make sense of the DOM and user events. Adding new features typically involves changing both server and client code, often in different languages.

Many developers now include a client MVC framework like Backbone to better structure client code. A few have started to use declarative model-view binding libraries, such as Knockout and Angular, to reduce boilerplate DOM manipulation and event bindings. These are great concepts, and adding some structure certainly improves client code. However, they still lead to duplicating rendering code and manually synchronizing changes in increasingly complex server and client code bases. Not only that, each of these pieces must be manually wired together and packaged for the client.

Derby radically simplifies this process of adding dynamic interactions. It runs the same code in servers and browsers, and it syncs data automatically. Derby takes care of template rendering, packaging, and model-view bindings out of the box. Since all features are designed to work together, no code duplication and glue code are needed. Derby equips developers for a future when all data in all apps are realtime.

Flexibility without the glue code Derby eliminates the tedium of wiring together a server, server templating engine, CSS compiler, script packager, minifier, client MVC framework, client JavaScript library, client templating and/or bindings engine, client history library, realtime transport, ORM, and database. It elminates the complexity of keeping state synchronized among models and views, clients and servers, multiple windows, multiple users, and models and databases.

At the same time, it plays well with others. Derby is built on top of popular libraries, including Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB, and soon other popular databases and datastores. These libraries can also be used directly. The data synchronization layer, Racer, can be used separately. Other client libraries, such as jQuery, and other Node.js modules from npm work just as well along with Derby.

When following the default file structure, templates, styles, and scripts are automatically packaged and included in the appropriate pages. In addition, Derby can be used via a dynamic API, as seen in the simple example above.

But it also comes with following disclaimer

Derby and Racer are alpha software. While Derby should work well enough for prototyping and weekend projects, it is still undergoing major development. APIs are subject to change.

It doesn't yet have an authorization implementation and is fraught with security issues, although they will be taken care of in months to come. If you can wait for a few months this seems to be a promising framework.

---

Selecting a framework comes down to your comfort level with it.. usually based on..

• How active is the project? When was the last commit? If it's not on github that's an immediate concern for me since that makes user contributions harder.

• How many blog posts can I find on the framework? If nobody is talking about it that's usually a bad sign since people naturally talk about things that excite them.

• What do I think of the framework? This can be harder to judge but there should be enough examples out there that you can get a basic idea at least. If there aren't then that in of itself is a big problem.

Erm.. of course the obvious question is if you want a RoR framework.. why not just use RoR? ;)

---

It looks like TowerJS is more tightly coupled with MongoDB as its data store, whereas RailwayJS seems to have model adapter flexibility. That might affect your choice between the two. Personally I'd choose to write Rails sites using RoR. Node seems to lend itself more to different kinds of services don't you think? (I'm thinking Backbone in the client with AJAX REST services).

참고URL : https://stackoverflow.com/questions/9897017/railwayjs-vs-towerjs