RailwayJS vs TowerJS
Encore une fois ... sélection du cadre. Je me suis arrêté sur ces deux TowerJS et RailwayJS, mais cela semble très similaire et il est très difficile de choisir
Les deux sont basés sur Express, les deux sont des cadres de style RoR ...
Lequel est le plus prometteur, lequel sera le plus populaire?
Ou peut-être que je suis déjà sur la mauvaise voie? Je devrais peut-être choisir un autre cadre.
Je déteste quand il y a tellement de frameworks à choisir, il n'y a pas de norme de l'industrie sur laquelle s'appuyer, pour être plus ou moins sûr que le framework sera développé dans quelques années ...
S'il vous plaît aider, besoin de suggestions d'experts. Merci
Voici un petit tableau pour un aperçu, je vais parler de certaines choses ci-dessous.
+ ----------------------- + -------------------- ---------- + ------------------------------------ +
| | RailwayJS | Tower.js |
+ ----------------------- + ---------------- -------------- + ----------------------------------- - +
| Premier commit | Janvier 2011 | Oct. 2011 |
| Rails | 2.3.x | 3.x |
| Node.js |> = 0.4.x |> = 0.4.x |
| Serveur | ✓ | ✓ |
| Client | | ✓ |
| Modèle agnostique | ✓ | ✓ |
| Moteur par défaut | EJS | CoffeeKup |
| Base de données agnostique | ✓ | ✓ |
| Banque de données par défaut | MongoDB | MongoDB |
| Validations du modèle | validatesPresenceOf ('email') | validates ('email', presence: true) |
| Query portées | ✓ | ✓ |
| Lunettes de visée à chaîne | | ✓ |
| Analyse des paramètres | | ✓ |
| Contrôleurs | ✓ | ✓ |
| Contrôleurs de ressources | | ✓ |
| Désignation des fichiers | users_controller.js | usersController.coffee |
| vm.runInCustomContext | ✓ | |
| Pipeline d'actifs | | ✓ |
| Compression des actifs | | ✓ |
| Routage | map.resources ('messages') | @resources 'posts' |
| Itinéraires imbriqués | ✓ | ✓ |
| Assistants d'URL générés | ✓ | |
| Générateurs | ✓ | ✓ |
| API de ligne de commande | ✓ | ✓ |
| REPL (console) | ✓ | ✓ |
| Console CoffeeScript | | ✓ |
| Méthode de cache d'actifs | horodatage | hachage md5 |
| Chemin d'accès aux ressources de production | /app.css?123123123 | /app-859c828c89288hc8918741.css |
| Langue préférée | JavaScript | CoffeeScript |
| Prise en charge de CoffeeScript | ✓ | ✓ |
| Internationalisation | ✓ | ✓ |
| Prise en charge Heroku | ✓ | ✓ |
| Étui à chaîne | snake_case | camelCase |
| Form builder | ✓ | ✓ |
| Constructeur de formes sémantiques | | ✓ |
| Chaudière de table | | ✓ |
| API File Watcher | | ✓ |
| Actifs de rechargement en direct | | ✓ |
| Suite de tests | | ✓ |
| Générateurs de tests | | ✓ |
| Twitter Bootstrap | ✓ | ✓ |
| HTML5 Boilerplate | | ✓ |
+ ---------------- ------- + ------------------------------ + ----------- ------------------------- +
J'ai créé Tower.js pour atteindre plusieurs objectifs qu'aucun des cadres existants n'a fait de manière adéquate. Voici certains de ces objectifs.
1. Même code sur le client et le serveur
Étant donné que Node.js a rendu JavaScript possible sur le serveur, il n'y a aucune raison d'écrire une partie de l'application dans Rails et l'autre dans Backbone. C'est tout sauf SEC. Vous devriez pouvoir définir les modèles une fois et les utiliser à la fois sur le client et sur le serveur.
RailwayJS ne fonctionne que sur le serveur car il a été construit autour d'express. Tower.js est également construit autour d'express mais d'une manière qui le fait fonctionner à la fois pour le client et le serveur. Tower.js fournit la même API exacte pour le client et le serveur. Cela signifiait que je devais réécrire certaines choses comme le routeur pour qu'il fonctionne de la même manière sur le client et le serveur (en plus, cela vous permet de faire des choses comme history.pushState Avec la solution de secours #, En utilisant la même chose ensemble d'itinéraires).
2. Mêmes "vues" sur le client et le serveur
J'ai passé beaucoup de temps à Rails et à écrire des modèles Haml. Parallèlement, j'écrivais des interfaces JavaScript Web et mobiles en utilisant des langages de modèles comme Moustache. C'est plus de duplication de code ... Vous devriez pouvoir utiliser les mêmes ensemble de vues/modèles à la fois sur le client (en tant que modèles JavaScript) et sur le serveur (rendu HTML statique).
Puisque Haml était assez génial (super propre, vous permettait d'exécuter Ruby arbitraire, intégré à la jolie impression, etc.), l'alternative JavaScript la plus proche était CoffeeKup . Et cela fonctionne à la fois sur le client et sur le serveur. CoffeeKup vous permet d'écrire des modèles avec toute la puissance de JavaScript, vous n'avez donc aucune limitation. Construire un FormBuilder dans Moustache va prendre beaucoup de travail ou beaucoup de code, ou les deux.
Notez cependant que vous êtes libre de remplacer les moteurs de modèle et d'utiliser Jade, Moustache, Guidons, etc. pour le client ou le serveur. CoffeeKup est juste un défaut propre et puissant.
3. API de modèle de qualité Rails sur le client et le serveur
ActiveModel (implémenté par ActiveRecord pour SQL et Mongoid pour MongoDB pour Rails) est une API très approfondie et bien testée permettant aux développeurs de définir et d'interagir avec les données. C'est à la fois puissant et agréable. Toutes les implémentations JavaScript précédentes (et actuelles) n'ont jamais été aussi robustes et bien conçues, et je n'ai rien vu se produire dans un avenir proche.
Si vous pouvez écrire ceci dans Rails:
User.where(:email => /[a-z/).page(2).limit(20)
Vous devriez pouvoir le faire en JavaScript:
App.User.where(email: /[a-z/).page(2).limit(20)
Tower.js est livré avec des "étendues chaînables", ce qui signifie des requêtes hardcore + pagination. Il est modélisé d'après MongoDB Query API , mais cette "entrée" API est convertie en commandes de base de données appropriées pour les différents magasins de données.
4. Interface uniforme avec les banques de données SQL et NoSQL
Tower.js dispose actuellement d'un magasin MongoDB et de mémoire (dans le navigateur), et vise à fournir une interface uniforme au reste des bases de données populaires (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra, etc.).
RailwayJS semble également le faire via JugglingDB, et cela semble être un bon début. Mais j'ai choisi de ne pas l'utiliser pour plusieurs raisons. Premièrement, il semble qu'il soit construit autour de l'API Rails 2.x (User.validatesUniquenessOf "email" Vs. User.validates "email", presence: true). Deuxièmement, il n'a pas le la richesse des requêtes chaînables qui Rails 3 le fait. Troisièmement, je veux pouvoir ajouter du code à la base de code rapidement, et comme je suis très pointilleux, je finirais probablement par refactoriser le tout pour utilisez CoffeeScript, haha. Et je ne veux pas construire une couche autour de cela car il doit aussi fonctionner sur le client, donc garder l'architecture de la bibliothèque aussi minimale que possible est une priorité élevée.
5. Contrôleurs ingénieux
Le inherited_resources Ruby gem a découpé environ 90% du code de mes Rails contrôleurs. Il a trouvé un ensemble de conventions pour implémentant les 7 actions de base du contrôleur. Tower.js inclut quelque chose comme ça, donc par défaut vous n'avez pas à écrire de code dans vos contrôleurs, ils répondront toujours avec JSON et HTML. Cela permet également de définir des routes imbriquées .
6. Analyseur automatique de requêtes URL vers base de données
Dans Tower.js, vous pouvez dire à un contrôleur de surveiller des paramètres spécifiques dans l'URL et il les convertira en un hachage prêt à être appliqué à une requête de modèle.
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}
Étant donné une URL qui ressemble à /users?email=abc&something=random, Alors @criteria() vous donnera un hachage {email: /abc/}.
Ce n'est pas dans Rails, mais j'aimerais bien.
7. Formes sémantiques
Je suis super en HTML sémantique. Le générateur de formulaires de Rails génère un HTML assez laid, donc beaucoup de gens ainsi que moi-même avons utilisé Formtastic , ce qui génère plus de formes sémantiques. Tower.js utilise à peu près la même API que Formtastic. Il dispose également d'un générateur de tables sémantiques, ce qui facilite la création de tables consultables/triables pour les vues d'administration.
8. Pipeline d'actifs
Rails 3 avait un pipeline d'actifs génial, où vous pouviez écrire votre JavaScript en CoffeeScript, votre CSS en SCSS, et il se recompilait automatiquement. Ensuite, rake assets:precompile Vos ressources et vous obtiendrez des ressources gzippées hachées md5 prêtes pour S3. C'est assez difficile à construire vous-même, et je n'ai vu personne travailler sur cela pour Node.js.
RailwayJS utilise la méthode Rails 2 pour horodater le chemin des ressources, donc au lieu de cette version hachée md5:
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
Vous obtiendriez quelque chose comme ceci:
/stylesheets/application.css?1306993455524
C'est un problème pour plusieurs raisons importantes. Le Rails Asset Pipeline Guide contient les détails, mais le plus important est que S3 ne reconnaît pas l'horodatage, donc il lit /stylesheets/application.css, et si vous définissez un futur lointain Expires header et vous avez changé votre CSS, toute personne qui a déjà visité votre site devra purger son cache ou forcer l'actualisation de votre page pour voir les mises à jour.
RailwayJS n'a pas non plus de pipeline de compilation d'actifs intégré (du moins à ma connaissance).
9. Le Watchfile
Guard était un énorme booster de productivité dans Rails. Il vous a permis d'écrire des "tâches de surveillance" rapides, essentiellement comme des tâches de râteau/gâteau, qui s'exécutaient lorsqu'un fichier correspondant à un modèle était créé/mis à jour/supprimé.
Tower a cela intégré (en utilisant design.io ). C'est en fait ce qui dit aux actifs CoffeeScript et Stylus de se compiler en JavaScript et CSS. Mais vous pouvez faire des choses très puissantes avec cette fonctionnalité, voir https://github.com/guard/guard/wiki/List-of-available-Guards pour des exemples.
10. CoffeeScript
Grand fan de CoffeeScript.
CoffeeScript réduit de moitié la quantité de JavaScript dont vous avez besoin d'écrire ( 6 501 ajouts, 15 896 suppressions conversion de la bibliothèque Node.js entière en CoffeeScript). Et cela rend le codage beaucoup plus rapide et plus facile.
De plus, CoffeeScript est le seul moyen de conserver cette expérience de codage productive et agréable que Rails a montré au monde. JavaScript ne fait tout simplement pas cela.
Les petites choses
Je suis fan des standards. RailwayJS est resté fidèle à la convention Ruby d'utiliser snake_case, et je le voulais aussi, mais la communauté JavaScript utilise camelCase, donc Tower a opté pour cela. CamelCase a également quelques avantages supplémentaires, tels que vous n'avez pas besoin de convertir côté serveur Rails snake_case vers/depuis camelCase pour le client, et la suppression de ce caractère supplémentaire vous donne une toute petite taille de fichier.
Je suis également amoureux du code super propre. Avant d'envisager de contribuer à un projet, j'ai lu le code source ... et si c'est super compliqué, je vais probablement le réécrire.
J'aime aussi optimiser le code. Avec Tower.js, un grand objectif est de le structurer afin qu'il fasse tout ce que Rails fait, fournissant la même API exacte à la fois sur le client et le serveur, en utilisant la quantité minimale de code possible. un compromis cependant entre la réduction de la taille de la base de code et l'écriture d'un code clair et amusant/productif à utiliser. Toujours trouver des moyens de tirer le meilleur parti des deux mondes.
Je suis définitivement dans le coup également. C'est le fondement de notre entreprise et tout ce que je vais personnellement construire à l'avenir. Je veux arriver au point où vous pouvez sortir une application bien conçue, fonctionnelle et hautement optimisée en une journée.
J'espère que cela pourra aider.
Avez-vous prêté attention à Derbyjs ? Celui-ci, bien que pas encore en version bêta, est assez excitant. Il est écrit par un ancien employé de Google et l'auteur de everyauth . Vous devrez écrire un minimum de javascript côté client avec celui-ci. Voir les extraits extraits de la page officielle:
Pourquoi ne pas utiliser Rails et Backbone? Derby représente une nouvelle race de frameworks d'application, qui, selon nous, remplaceront les bibliothèques actuellement populaires comme Rails et Backbone.
L'ajout de fonctionnalités dynamiques aux applications écrites avec Rails, Django et d'autres frameworks côté serveur a tendance à produire un désordre embrouillé. Le code du serveur affiche divers états initiaux tandis que les sélecteurs et rappels jQuery tentent désespérément de comprendre le DOM et les événements utilisateur. L'ajout de nouvelles fonctionnalités implique généralement la modification du code du serveur et du client, souvent dans des langues différentes.
De nombreux développeurs incluent désormais un framework MVC client comme Backbone pour mieux structurer le code client. Quelques-uns ont commencé à utiliser des bibliothèques de liaisons déclaratives de vues de modèles, telles que Knockout et Angular, pour réduire la manipulation DOM passe-partout et les liaisons d'événements. Ce sont d'excellents concepts, et l'ajout d'une structure améliore certainement le code client. Cependant, ils conduisent toujours à la duplication du code de rendu et à la synchronisation manuelle des modifications dans des bases de code serveur et client de plus en plus complexes. Non seulement cela, chacune de ces pièces doit être câblée manuellement et emballée pour le client.
Derby simplifie radicalement ce processus d'ajout d'interactions dynamiques. Il exécute le même code sur les serveurs et les navigateurs et synchronise automatiquement les données. Derby prend en charge le rendu des modèles, le conditionnement et les liaisons de vue de modèle dès la sortie de l'emballage. Étant donné que toutes les fonctionnalités sont conçues pour fonctionner ensemble, aucune duplication de code et aucun code de collage ne sont nécessaires. Derby équipe les développeurs pour un avenir où toutes les données de toutes les applications sont en temps réel.
Flexibilité sans le code de colle Derby élimine l'ennui de connecter ensemble un serveur, un moteur de modèle de serveur, un compilateur CSS, un packager de script, un minifieur, un framework MVC client, une bibliothèque JavaScript client, un moteur de template et/ou de liaisons client, une bibliothèque d'historique client, un transport en temps réel, ORM et base de données. Il élimine la complexité de la synchronisation de l'état entre les modèles et les vues, les clients et les serveurs, les fenêtres multiples, les utilisateurs multiples et les modèles et bases de données.
En même temps, il joue bien avec les autres. Derby est construit au-dessus des bibliothèques populaires, notamment Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB et bientôt d'autres bases de données et banques de données populaires. Ces bibliothèques peuvent également être utilisées directement. La couche de synchronisation des données, Racer, peut être utilisée séparément. D'autres bibliothèques clientes, telles que jQuery, et d'autres modules Node.js de npm fonctionnent aussi bien avec Derby.
Lorsque vous suivez la structure de fichiers par défaut, les modèles, styles et scripts sont automatiquement empaquetés et inclus dans les pages appropriées. De plus, Derby peut être utilisé via une API dynamique, comme le montre l'exemple simple ci-dessus.
Mais il est également livré avec l'avertissement suivant
Derby et Racer sont des logiciels alpha. Alors que Derby devrait fonctionner suffisamment bien pour le prototypage et les projets de week-end, il est toujours en cours de développement majeur. Les API sont susceptibles de changer.
Il n'a pas encore d'implémentation d'autorisation et est chargé de problèmes de sécurité , bien qu'ils seront pris en charge dans les mois à venir. Si vous pouvez attendre quelques mois, cela semble être un cadre prometteur.
Il semble que TowerJS soit plus étroitement couplé à MongoDB comme magasin de données, tandis que RailwayJS semble avoir une flexibilité d'adaptateur de modèle. Cela pourrait affecter votre choix entre les deux. Personnellement, je choisirais d'écrire Rails sites utilisant RoR. Node semble se prêter davantage à différents types de services, ne pensez-vous pas? (I ' Je pense Backbone dans le client avec AJAX REST services).
La sélection d'un cadre se résume à votre niveau de confort avec lui .. généralement basé sur ..
Dans quelle mesure le projet est-il actif? À quand remonte le dernier commit? Si ce n'est pas sur github, c'est une préoccupation immédiate pour moi car cela rend les contributions des utilisateurs plus difficiles.
Combien d'articles de blog puis-je trouver sur le framework? Si personne n'en parle, c'est généralement mauvais signe car les gens parlent naturellement de choses qui les excitent.
Que pense I du cadre? Cela peut être plus difficile à juger, mais il devrait y avoir suffisamment d'exemples pour que vous puissiez au moins avoir une idée de base. S'il n'y en a pas, alors en soi c'est un gros problème.
Euh .. bien sûr, la question évidente est de savoir si vous voulez un framework RoR .. pourquoi ne pas simplement utiliser RoR? ;)