Quels sont les inconvénients de RoR? [fermé]

J'essaie actuellement de choisir le langage serveur à apprendre et à utiliser pour le développement Web. Bien qu'il soit relativement facile de savoir pourquoi x, y ou z est une bonne chose, il est plus difficile de comprendre les inconvénients de chacun. d'eux.

En particulier, je suis curieux de savoir quels sont les inconvénients de l’apprentissage et / ou de l’utilisation de Ruby on Rails par opposition à tout autre langage / cadre donné.

Parlant d'expérience: l'inconvénient est que vous utilisez un peu trop le framework Rails . C’est une excellente chose si vous n’écrivez que des applications CRUD simples et novatrices qui tombent carrément dans le "sweet spot" de Rails; votre productivité va monter en flèche. Cependant, au moment où vous devez faire quelque chose en dehors de cette zone privilégiée - interagir avec une base de données existante, communiquer avec une autre application pour laquelle aucune API JSON ou XML n'est définie, implémenter un flux de travail compliqué, Rails deviendra votre ennemi. il estIl est possible de faire ces choses avec Rails, mais cela va "à contre-courant", vous devez donc vous débrouiller seul pour savoir comment le faire, car la communauté répondra généralement par "Ne faites pas cela, ce ne sont pas les Rails manière "- il en résulte une perte de productivité ou un code très compliqué, car vous devez fondamentalement pirater le framework Rails.

En outre, il y a l'inconvénient tacite: tout le reste semblera laid et kludgy. Une fois que vous avez goûté au nectar sucré et sucré de Rails (d'accord, évangélisez un peu ici ...), tout le reste est en sauce. Passer de Rails à PHP, à ASP.NET WebForms ou à Java, c'est comme marcher sur un lit de clous après avoir gambadé dans un jardin luxuriant; vous ne verrez pas les autres langages / structures de la même manière et, même si vous les appréciez toujours, vous aspirerez secrètement à l'étreinte aimante de Rails.

Pour votre premier langage côté serveur, je pense qu’il peut y avoir quelques problèmes avec RoR:

1. Vous n’apprenez pas seulement une langue, vous apprenez un cadre. Je prendrais certainement un peu de temps pour jouer avec le vieux rubis ordinaire avant de sauter dans les rails.

2. Comme il s’agit d’un cadre, et d’un «avisé», je pense que cela vous donnerait une portée très limitée de tout ce qui se passe dans le cadre.

Globalement, Ruby on Rails peut être un bon point de départ pour lancer le processus, mais il y a beaucoup à apprendre sur le développement Web que vous pouvez manquer à cause d'un trop grand nombre de frameworks.

J'ai essayé d'apprendre RoR plusieurs fois et mon plus gros problème est toujours d'essayer de faire fonctionner correctement les paquets et la documentation. Le problème avec la documentation est qu’elle semble toujours être obsolète (ou très basique). J'ai eu les bases du site, mais au-delà, tout semblait si démodé (même le livre que j'ai acheté et qui a fini par revenir). Une autre chose qui pourrait être un inconvénient est la dépendance de certaines bibliothèques et la manière dont elles peuvent entrer en conflit avec une autre, comme l'a dit Ben Coe .

Une chose à laquelle j'ai pensé plus tard et au lieu d'en faire un commentaire, je vais modifier ma réponse est la suivante: RoR a une chance de ruiner Ruby pour vous. Je sais que quand j'ai essayé, ça m'a fait penser que "Ruby était stupide". Puis, quelques mois plus tard, j'ai décidé d'essayer Ruby et j'ai adoré la langue. C'est le cadre qui m'a fait détester la langue. Je n'y ai pas beaucoup essayé, mais quand je l'ai fait, j'ai vraiment apprécié Sinatra . Je pense que j'ai eu la joie que la plupart des gens retirent de RoR de Sinatra.

S'il s'agit de votre premier langage côté serveur, il est aussi bon que tous les autres. La chose à faire est de vous concentrer sur l’un d’entre eux et, une fois que vous avez l’impression de le maîtriser, explorez les autres et tirez vos propres conclusions.

Je travaille quotidiennement avec RoR et ASP.NET, mais étrangement, je préfère le monde ASP.NET, mais cela a plus à voir avec la philosophie personnelle qu'avec le langage ou l'architecture elle-même. (Je suis un peu un maniaque du contrôle et je gravite personnellement vers des langages fortement typés).

Peu importe, je dis de tenter le coup. RoR est un environnement de travail idéal, mais avant de vous lancer dans Rails, familiarisez-vous avec Ruby en tant que langue. Au-delà des contenus Web, Ruby est un langage de script assez cool si vous devez gérer un boîtier * nix et vous faire gagner un temps précieux.

En tant que personne qui a appris Rails récemment (en tant que passe-temps - ne l’a jamais utilisé pour un développement de niveau commercial) et qui avait déjà travaillé pour JEE et ASP.NET, la réponse de Wayne M. sonnait très vraie.

Quoi qu'il en soit, il y a un côté subtil à cela que personne n'a encore mentionné, mais qui m'a un peu gêné avec Rails - la forte dépendance de la convention par rapport à la configuration .

Essentiellement, si vous êtes habitué à utiliser l'orientation "Rechercher dans les fichiers" avec une nouvelle base de code, le CdC risque de vous importuner lorsque vous essayez de récupérer Rails. C’est génial pour les greenfields CRUD simples qui sont effectués précisément selon Rails (comme le dit Wayne M), mais pour tout ce qui est plus unique et plus compliqué, il sera difficile de déterminer ce qui se passe si vous essayez de définir le flux en recherchant trucs dans des fichiers pour voir comment la plomberie est raccordée.

Bien que je pense, ce problème ne sera probablement pas aussi grave une fois que vous aurez beaucoup plus d'expérience avec Rails. Je peux vraiment voir que c'est un problème pour quelqu'un venant du développement Web oldskool Java / .NET qui est habitué à un flux de configuration très détaillé - et qui a l'habitude de voir tout ce qui est écrit quelque part.

Avec moi, le plus gros problème avec j'apprends mon premier X (dans votre cas, X est un langage / framework web côté serveur), c’est que dès que je vois d’autres problèmes, je veux tout de suite commencer à appliquer X, même si pourrait ne pas être la meilleure option. Je me suis amélioré à cela, mais c'est toujours une forte tendance.

Ruby on Rails est un bon choix pour commencer - il existe une bonne communauté, de nombreux documents et de bons tutoriels. Mais n'oubliez pas de garder à l'esprit les alternatives, surtout si vous commencez à faire plus de développement Web. RoR peut être exagéré pour certains problèmes, une solution inadéquate pour d'autres et le meilleur choix pour un ensemble différent. Sachez ce que sont ses forces, ses faiblesses et comment utiliser cet outil.

Mon conseil serait d’avoir une image claire du projet que vous voulez mener à bien et d’essayer de le construire. Lorsque vous rencontrez des problèmes, vous finirez par saisir tous les bons outils. Cette approche est bonne car vous prenez des décisions à partir de problèmes succincts.

Une autre chose à faire est d'acheter des livres. Les didacticiels sur Internet ne me le permettent pas. ils laissent également beaucoup de place à la distraction. Lorsque vous avez un livre, les éditeurs doivent s'assurer qu'il apporte de la valeur, car ils perdront de l'argent s'il reçoit de mauvaises critiques. Dépenser un peu d'argent vous fera économiser beaucoup de temps.

Honnêtement, je ne comprends pas ceux qui discutent avec poésie de ce qu’est une promenade dans le jardin, Ruby-on-Rails. J'y suis arrivé en tant que développeur ASP.NET-MVC, Java, PHP, Python expérimenté - et j'ai trouvé que c'était le plus horrible des gaspilleurs de temps! 90% des réponses Google en ligne sont fausses ou incomplètes. Pourquoi? Cela a-t-il changé chaque année? Ou est-ce que personne ne se soucie de faire fonctionner le code? Cela m'a pris énormément de temps pour faire des choses simples; beaucoup, beaucoup plus que cela ne me prendrait dans C # / ASP.NET-MVC, par exemple. Il ne m'a certainement jamais fallu si peu de temps pour apprendre mes technologies d'origine. Certes, ROR est concis. Si c'est important pour toi. Mais j’ai rarement trouvé comment créer du code permettant d’accomplir une tâche. Personnellement, je préfère taper sur un clavier pendant 20 secondes pour écrire un code qui fonctionne, est clair et vous pouvez le suivre plutôt que taper du code laconique Ruby pendant 2 secondes, mais qui ne fonctionne jamais tant que je ne suis pas debout toute la nuit à la recherche d’un moyen de le faire fonctionner. C'est un tas de dodos horrible et puant. Pourquoi? Est-ce que le code open-source (comme dans le code libre) ne produit aucune incitation à en faire un outil de qualité? Trop de script-kiddies pompant des révisions et des modules et une mauvaise documentation? Je ne sais pas. Mais quand j'ai finalement pu échapper à ce premier projet Ruby-Rails, j'ai juré de ne plus jamais me retrouver dans ce pétrin! ne produit aucune incitation à en faire un outil de qualité? Trop de script-kiddies pompant des révisions et des modules et une mauvaise documentation? Je ne sais pas. Mais quand j'ai finalement pu échapper à ce premier projet Ruby-Rails, j'ai juré de ne plus jamais rentrer dans ce pétrin! ne produit aucune incitation à en faire un outil de qualité? Trop de script-kiddies pompant des révisions et des modules et une mauvaise documentation? Je ne sais pas. Mais quand j'ai finalement pu échapper à ce premier projet Ruby-Rails, j'ai juré de ne plus jamais rentrer dans ce pétrin!

Je vous suggère de regarder les indices évaluant la prédominance de différentes langues / scripts. Voici un lien qui pourrait s’avérer utile: les langages Web couramment utilisés par les professionnels.

Cela montre la popularité relative des langues Web basée sur les recherches d'offres d'emploi en ligne.

J'accepte certaines des réponses ci-dessus à propos de RoR. Je développe des applications avec RoR depuis deux ans. C’est vraiment bien avec des applications simples, les opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) fonctionnent très bien, c’est une aubaine pour le développement d’applications simples, mais aussi ses limites. Bien qu'il y ait beaucoup de pierres précieuses qui offrent divers avantages et facilité d'utilisation, c'est fondamentalement ça. En sortant de la boîte, vous obtiendrez des applications complètement tordues.

Si vous êtes une grande équipe travaillant sur une application utilisant RoR, la délégation de travail peut s'avérer difficile.