RailwayJS vs TowerJS [zamknięta]

Oto krótka tabela do omówienia, omówię niektóre z poniższych rzeczy.

+-----------------------+------------------------------+------------------------------------+
|                       | 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     |                              | ✓                                  |
+-----------------------+------------------------------+------------------------------------+

Stworzyłem wieżę.js, aby osiągnąć kilka celów, których żaden z istniejących ram nie zrobił w odpowiedni sposób. Oto niektóre z tych celów.

1. Ten sam kod na kliencie i serwerze

Od Węzła.js umożliwił JavaScript na serwerze, nie ma powodu, aby pisać jedną część aplikacji w Rails, a drugą w Backbone. To nie jest suche. Powinieneś być w stanie zdefiniować modele raz i używać ich zarówno na kliencie, jak i na serwerze.

RailwayJS działa tylko na serwerze, ponieważ został zbudowany wokół express. Wieża.js jest również zbudowany wokół express, ale w sposób, który sprawia, że działa zarówno dla klienta, jak i serwera. Wieża.js zapewnia ten sam dokładny API dla klienta i serwera. Oznaczało to, że musiałem przepisać kilka rzeczy, takich jak router, aby działał tak samo na kliencie i serwerze (plus pozwala robić rzeczy takie jak history.pushState z # fallback, używając ten sam zestaw tras).

2. To samo "widoki" na kliencie i serwerze

Spędziłem dużo czasu w Rails i pisaniu szablonów Haml. Oprócz tego pisałem webowe i mobilne interfejsy JavaScript przy użyciu języków szablonów, takich jak wąsy. To więcej duplikacji kodu ... powinieneś być w stanie używać tego samego zestawu widoków / szablonów zarówno na kliencie (jak szablony JavaScript), jak i na serwerze (renderowanie statycznego HTML).

Ponieważ Haml był całkiem zajebisty (super czysty, pozwalał na wykonanie dowolne ruby, wbudowane w ładny druk, itp.), najbliższą alternatywą dla JavaScript był CoffeeKup. I działa zarówno na kliencie, jak i na serwerze. CoffeeKup pozwala pisać szablony z całą mocą JavaScript, więc nie masz żadnych ograniczeń. Zbudowanie Formbuildera w wąsach wymaga albo dużo pracy, albo dużo kodu, albo obu tych rzeczy.

Pamiętaj jednak, że możesz wymieniać silniki szablonów i używać Jade, wąsów, kierownicy itp. dla klienta lub serwera. CoffeeKup jest po prostu czystym i potężnym domyślnym.

3. Rails-quality model API na kliencie i serwerze

Activemodel (zaimplementowany przez ActiveRecord dla SQL i Mongoid dla MongoDB dla Rails) jest bardzo dokładnym i dobrze przetestowanym API pozwalającym programistom na definiowanie i interakcję z danymi. Jest zarówno potężny, jak i przyjemny. Wszystkie poprzednie (i obecne) implementacje JavaScript nigdy nie były tak solidne i dobrze zaprojektowane, a ja nie widziałem, aby coś się działo w pobliżu przyszłość.

Jeśli możesz to napisać w Rails:

User.where(:email => /[a-z/).page(2).limit(20)

Powinieneś być w stanie to zrobić w JavaScript:

App.User.where(email: /[a-z/).page(2).limit(20)

Wieża.js jest wyposażony w "chainable scopes", co oznacza hardcore queries + pagination. Jest wzorowany na MongoDB Query API , Ale To API "input" jest konwertowane do odpowiednich poleceń bazy danych dla różnych magazynów danych.

4. W 2009 roku firma została założona w 2009 roku.]}

Wieża.js ma obecnie MongoDB i pamięć (in-browser) sklep, i ma na celu zapewnienie jednolitego interfejsu do reszty popularnych baz danych (CouchDB, Neo4j, PostGreSQL, MySQL,SQLite, Cassandra, itp.).

RailwayJS wydaje się robić to również poprzez JugglingDB, i wygląda to na dobry początek. Ale zdecydowałem się nie używać go z kilku powodów. Po pierwsze, wygląda na to, że jest budowany wokół Rails 2.X API (User.validatesUniquenessOf "email" vs. User.validates "email", presence: true). Po drugie, nie ma bogactwa zapytań łańcuchowych, które robi Rails 3. Po trzecie, chcę móc Dodaj kod do bazy kodowej szybko, a ponieważ jestem bardzo wybredny, prawdopodobnie skończyłbym na refaktoryzacji całości, aby użyć CoffeeScript, haha. I nie chcę budować wokół tego warstwy, ponieważ musi ona działać również na kliencie, więc utrzymanie architektury bibliotecznej jak najmniejszej jest priorytetem.

5. Zaradni kontrolerzy

The inherited_resources Ruby gem wyciął około 90% kodu z moich kontrolerów Rails. Opracowano na podstawie materiału źródłowego. konwencje implementacji 7 podstawowych akcji kontrolera. Wieża.js zawiera coś takiego, więc domyślnie nie musisz pisać żadnego kodu w kontrolerach, które nadal będą odpowiadać JSON i HTML. To również sprawia, że można zdefiniować zagnieżdżone trasy.

6. Automatyczny parser zapytań URL-to-database

W Wieży.js, możesz powiedzieć kontrolerowi, aby obserwował określone parametry w adresie url i przekonwertuje je na hash gotowy do zastosowania do modelu zapytanie.

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}

Po podaniu adresu URL, który jest podobny do /users?email=abc&something=random, @criteria() da ci hash {email: /abc/}.

Nie jest w Railach, ale chciałbym, żeby tak było.

7. Formy Semantyczne

Jestem super w semantycznym HTML. Kreator formularzy rails generuje dość brzydki HTML, tak wiele osób, jak i ja, używało Formtastic , który generuje więcej form semantycznych. Wieża.js używa prawie tego samego API co Formtastic. Posiada również semantyczny konstruktor tabel, co ułatwia twórz przeszukiwalne / sortowalne tabele dla widoków administratora.

8. Asset Pipeline

Rails 3 miał niesamowity potok zasobów, w którym można było pisać JavaScript w CoffeeScript, CSS w SCSS i automatycznie rekompilować. Następnie rake assets:precompile twoje aktywa i będziesz mieć md5-haszowane aktywa gzipped gotowe do S3. Ciężko to zbudować samemu, a nie widziałem, żeby ktoś nad tym pracował dla Node.js.

RailwayJS używa metody rails 2 do oznaczania czasu ścieżki zasobu, więc zamiast tej md5-haszowanej wersji:

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

Dostałbyś coś takiego:

/stylesheets/application.css?1306993455524

Jest to problem z kilku ważnych powodów. Przewodnik Rails Asset Pipeline Guide zawiera szczegóły, ale najważniejsze, że S3 nie rozpoznaje znacznika czasu, więc czyta / stylesheets / application.css, a jeśli ustawisz dalekosiężny nagłówek Expires i zmienisz swój CSS, każdy, kto odwiedził Twoją witrynę wcześniej, będzie musiał wyczyścić pamięć podręczną lub wymusić odświeżenie strony, aby zobaczyć aktualizacje.

RailwayJS również nie ma wbudowanego potoku kompilacji zasobów (przynajmniej z mojej wiedzy).

9. Watchfile

Guard był ogromnym wzmacniaczem wydajności w Rails. To pozwoliło Ci napisać szybkie "obserwuj zadania", zasadniczo jak rake / cake zadania, które uruchamiane, gdy plik pasujący do wzorca został utworzony/zaktualizowany / usunięty.

Wieża ma to wbudowane (za pomocą design.io ). To właśnie mówi CoffeeScript i rysik zasoby do kompilacji w JavaScript i CSS. Ale możesz robić bardzo potężne rzeczy dzięki tej funkcji, zobacz https://github.com/guard/guard/wiki/List-of-available-Guards na przykład.

10. CoffeeScript

Wielka fanka CoffeeScript.

CoffeeScript zmniejsza ilość JavaScript, o którym musisz napisać o połowę (6 501 dodatków, 15 896 delecji konwertując cały węzeł.biblioteka js do CoffeeScript). I sprawia, że kodowanie jest znacznie szybsze i łatwiej.

CoffeeScript jest również jedynym sposobem, aby zachować produktywne i przyjemne doświadczenie kodowania, które rails pokazał światu. JavaScript tego nie robi.

Małe rzeczy

Jestem fanem standardów. RailwayJS trzymała się Ruby konwencji używania snake_case, i też chciałem to zrobić, ale społeczność JavaScript używa camelCase, więc Tower poszedł z tym. CamelCase ma również kilka dodatkowych zalet, takich jak nie trzeba konwertować szyn po stronie serwera snake_case do / Z camelCase dla klienta, a usunięcie tego dodatkowego znaku daje mały mniejszy rozmiar pliku.

Jestem również zakochany w super czystym kodzie. Zanim rozważę udział w projekcie, przeczytam kod źródłowy... a jeśli jest bardzo brudny, prawdopodobnie napiszę go od nowa.

Uwielbiam też optymalizować kod. Z Wieżą.js, głównym celem jest jego struktura tak, aby robił wszystko, co robi Rails, zapewniając dokładnie to samo API zarówno w kliencie, jak i na serwerze, użycie minimalnej ilości kodu możliwe. Istnieje jednak kompromis między minimalizacją rozmiaru bazy kodowej a pisaniem kodu, który jest przejrzysty i przyjemny / produktywny w użyciu. Wciąż znajduję sposoby, aby uzyskać to, co najlepsze z obu światów.

Jestem w tym zdecydowanie na dłuższą metę. To jest fundament naszej firmy i wszystko, co ja osobiście zbuduję w przyszłości. Chcę dotrzeć do punktu, w którym można wypompować ładnie zaprojektowaną, funkcjonalną i wysoce zoptymalizowaną aplikację w dzień. Mam nadzieję, że to pomoże.