L'utilisation d'un framework Ruby autre que Rails présente-t-elle des inconvénients potentiels?

Question

J'aimerais utiliser un cadre plus léger que Rails (Sinatra / Ramaze / Camping), mais je crains que cela ne me permette pas d'utiliser beaucoup de bibliothèques partagées qui ont été adaptées à Rails sous la forme de plugins. . Est-ce une préoccupation majeure ou la plupart de ces plugins sont-ils utilisables dans différents frameworks Ruby?

Existe-t-il d'autres inconvénients potentiels à l'utilisation d'un framework Ruby autre que Rails?

Answer 1

Vous pouvez toujours utiliser les gemmes dans tous les frameworks que vous avez mentionnés, de sorte qu'une tonne de fichiers est réutilisable. Voulez-vous échanger un nouvel ORM, aucun problème. Vous voulez une mise en évidence de la syntaxe sophistiquée shmacy, pas de problèmes. Rails a fait un effort énorme pour s'éloigner de l'ancien modèle de plugin et utiliser exclusivement des gemmes.

Si l'un des autres cadres répond à vos besoins, mieux l'utiliser. N'oubliez pas qu'en matière de documentation et d'échantillons, rails a plus.

Si j’apprenais Ruby et que je voulais essayer un framework Web, je choisirais probablement Rails, non pas parce que c’est meilleur, mais parce que son outillage et sa documentation sont bien meilleurs.

Answer 2

La plupart des modules Ruby utilisés par Rails (même ActiveRecord) peuvent être utilisés sans Rails. Mais alors vous perdez l'avantage supplémentaire de l'intégration fournie par Rails. Vous devrez peut-être redoubler d'efforts pour coller les modules Ruby au cadre de votre choix. Veuillez également noter que la plupart de la documentation sur les modules Ruby utilisée par Rails vous indique uniquement comment utiliser ce module avec Rails.

Answer 3

Les effets de réseau jouent un petit rôle.

Answer 4

Un problème qui se pose lorsque vous utilisez d'autres frameworks tels que Sinatra, Camping, etc. est que les rails vous offrent une structure éprouvée pour vos fichiers dans votre application. Les petits cadres sont assez ouverts et libres.

Cela peut être un inconvénient lorsque vous travaillez avec plusieurs développeurs car vous devez avoir des conversations sur la création de conventions plutôt que de simplement les suivre.

Answer 5

Si vous utilisez Ruby depuis moins d'un an, limitez-vous à Rails, sauf si vous avez un besoin très clair, mieux géré par l'un des autres frameworks.

Les frameworks les plus légers, notamment Sinatra, ont tendance à être populaires auprès des personnes qui savent exactement ce dont elles ont besoin et qui ne peuvent pas se permettre d’obtenir une surcharge supplémentaire due au code inutilisé. En gros, vous choisissez votre chaîne d’outils au lieu d’être collée à ce que Rails vous donne. (Oui, dans Rails, vous pouvez remplacer ActiveRecord, etc., par d'autres bibliothèques, mais ce n'est pas tout à fait facile.) Ainsi, les frameworks les plus légers vous donnent beaucoup plus de liberté, mais vous avez également un peu plus de travail à faire.

Answer 6

Je pense qu'aucun plug-in rail ne fonctionnera immédiatement avec l'un des frameworks alternatifs, à l'exception des plug-ins ActiveRecord (tels que acts_as_nested_set, etc.) qui nécessiteront encore des travaux de plomberie (définition de $ LOAD_PATH et nécessitant un droit des dossiers). Je recommanderais DataMapper pour ORM, non seulement c'est plus rapide qu'ActiveRecord, mais il est également très modulaire et les plugins sont de véritables joyaux que vous pouvez facilement installer. En revanche, les plugins ActiveRecord sont principalement des correctifs monkey qui tendent à se rompre avec chaque nouvelle version.

Sinatra ne vient pas avec des "goodies", pas de Rakefiles, pas de squelettes, pas de script / générer, mais en fait c'est ce pour quoi il a été écrit. Vous pouvez progressivement "ajouter" & toutes les choses supplémentaires. Il existe également des squelettes pour les applications Sinatra livrées avec une présentation et des paramètres par défaut de base, vous les trouverez peut-être utiles.