¿Cuáles son las desventajas de RoR? [cerrado]

Actualmente estoy tratando de decidir qué lenguaje del lado del servidor aprender y usar para el desarrollo web, y aunque es relativamente fácil obtener información sobre por qué x, y, o z es algo bueno, es más difícil descubrir las desventajas de cada uno de ellos.

En particular, tengo curiosidad acerca de los inconvenientes que existen para aprender y / o usar Ruby on Rails en lugar de cualquier otro lenguaje / marco dado.

Hablando por experiencia: la desventaja es que confías demasiado en el marco de Rails . Esto es algo maravilloso y maravilloso si solo está escribiendo aplicaciones CRUD simples y nuevas que caen directamente en el "punto óptimo" de Rails; Su productividad se disparará. Sin embargo, en el momento en que tenga que hacer algo fuera de ese punto óptimo: interactúe con una base de datos existente, hable con otra aplicación que no tenga una API JSON o XML definida, implemente un flujo de trabajo complicado, Rails se convertirá en su enemigo. que eses posible hacer estas cosas con Rails, pero va "contra la corriente", así que básicamente estás solo para descubrir cómo hacerlo, ya que la comunidad generalmente responderá con "No hagas eso, no son los Rails manera ": esto resulta en pérdida de productividad o código muy desordenado, ya que básicamente tienes que hackear el marco de Rails.

Además, está el inconveniente tácito: todo lo demás parecerá feo y torpe. Una vez que hayas probado el dulce, dulce néctar de Rails (está bien, evangelizando solo un poco aquí ...) todo lo demás es genial. Volver de Rails a PHP, o ASP.NET WebForms, o Java es como caminar sobre una cama de clavos después de retozar en un exuberante jardín; no verá los otros lenguajes / marcos en la misma luz, y si bien aún puede apreciarlos, secretamente anhelará el amoroso abrazo de Rails.

Para su primer idioma del lado del servidor, siento que puede haber un par de problemas con RoR:

1. No solo estás aprendiendo un idioma, estás aprendiendo un marco. Definitivamente me tomaría un tiempo jugar con el viejo rubí antes de saltar a los rieles.

2. Dado que es un marco, y uno 'obstinado', creo que le daría un alcance muy limitado de lo que está sucediendo en el marco.

En general, Ruby on Rails puede ser un buen punto de partida para poner en marcha la pelota, pero hay mucho que aprender sobre el desarrollo web que puede perderse al depender demasiado de un solo marco.

He intentado aprender RoR varias veces y mi mayor problema siempre es intentar que los paquetes funcionen correctamente y la documentación. El problema con la documentación es que siempre parece estar desactualizado (o muy básico). Obtuve lo básico del sitio, pero más allá de eso, todo parecía tan anticuado (incluso el libro que compré y terminé regresando). Otra cosa que podría ser un inconveniente son las dependencias que tienen algunas de las bibliotecas y cómo pueden entrar en conflicto con otras, según lo declarado por Ben Coe .

Algo en lo que pensé más tarde y en lugar de hacer un comentario, solo editaré mi respuesta es esta: RoR tiene la posibilidad de arruinar a Ruby por ti. Sé que cuando lo probé, me hizo pensar que "Ruby era estúpido". Luego, unos meses más tarde, decidí darle una oportunidad a Ruby y me encantó el idioma, fue el marco lo que me hizo odiar el idioma. No me he metido mucho en eso, pero cuando lo hice, realmente disfruté de Sinatra . Creo que obtuve la alegría que la mayoría de la gente saca de RoR de Sinatra.

Si este es su primer idioma del lado del servidor, es tan bueno como cualquiera. Lo que hay que hacer es concentrarse en uno, y después de sentir que lo ha dominado, explore a otros y deduzca sus propias conclusiones.

Trabajo a diario con RoR y ASP.NET, pero, curiosamente, prefiero el mundo ASP.NET, pero eso tiene más que ver con la filosofía personal que con el lenguaje o la arquitectura en sí. (Soy un poco un fanático del control y personalmente gravito en lenguajes fuertemente tipados).

En cualquier caso, digo que lo pruebes. RoR es un excelente entorno para trabajar, pero antes de saltar directamente a Rails, siéntete cómodo con Ruby como idioma. Más allá de las cosas web, Ruby es un lenguaje de scripting bastante bueno si tienes que administrar una caja * nix y puedes ahorrarte un montón de tiempo.

Como alguien que aprendió Rails recientemente (como un pasatiempo, nunca lo usó para el desarrollo de grado comercial) y ya había trabajado en JEE y ASP.NET, la respuesta de Wayne M sonó muy cierta.

De todos modos, hay un lado sutil de esto que nadie ha mencionado todavía, pero que me molestó un poco con Rails: la fuerte dependencia de la convención sobre la configuración .

Esencialmente, si está acostumbrado a la orientación basada en "Buscar en archivos" con una nueva base de código, es probable que CoC lo moleste cuando intente recoger Rails. Es ideal para campos verdes CRUD simples que se realizan precisamente a la manera de Rails (como dice Wayne M), pero para cualquier cosa más única y complicada, será difícil resolver lo que está sucediendo si intentas resolver el flujo buscando cosas en archivos para ver cómo se conectan las tuberías.

Aunque creo que este problema probablemente no será tan malo una vez que tenga mucha más experiencia con Rails. Definitivamente puedo ver que es un problema para alguien que viene del desarrollo web Java / .NET de oldskool que está acostumbrado a un flujo de configuración muy detallado, y está acostumbrado a confiar en ver todo explicado en alguna parte.

Conmigo, el mayor problema con el que aprendo mi primera X (en su caso, X es un lenguaje / marco web del lado del servidor), es que tan pronto como veo otros problemas, inmediatamente quiero comenzar a aplicar X, incluso cuando Puede que no sea la mejor opción. He mejorado en esto, pero sigue siendo una tendencia fuerte.

Para empezar, Ruby on Rails es una buena opción: hay una buena comunidad, mucha documentación y buenos tutoriales. Pero asegúrese de tener en cuenta las alternativas, especialmente si comienza a hacer más desarrollo web. RoR puede ser excesivo para algunos problemas, una solución inadecuada para otros y la mejor opción para un conjunto diferente. Sepa sus fortalezas, debilidades y cómo usar la herramienta.

Mi consejo sería tener una idea clara del proyecto que desea completar y luego comenzar a tratar de construirlo. A medida que tenga problemas, eventualmente tomará todas las herramientas adecuadas. Este enfoque es bueno porque está tomando decisiones basadas en problemas sucintos.

Otra cosa que hacer es comprar libros. Los tutoriales de Internet no son suficientes en mi experiencia; también dejan mucho espacio abierto para distraerse. Cuando tienes un libro, los editores deben asegurarse de que proporcione valor, ya que perderán dinero si recibe malas críticas. Gastar un poco de dinero te ahorrará mucho tiempo.

Honestamente, no puedo entender a aquellos que se entusiasman poéticamente sobre lo que es un paseo por el jardín de Ruby-on-Rails. Llegué a esto como un experimentado desarrollador de ASP.NET-MVC, Java, PHP, Python, ¡y descubrí que era el desperdicio de tiempo más horrible de todos! El 90 por ciento de las respuestas de Google en línea son incorrectas o están incompletas. ¿Por qué? ¿Ha cambiado tanto cada año? ¿O es que a nadie le importa hacer que el código realmente funcione? Me llevó mucho tiempo hacer cosas simples; mucho, mucho más de lo que me llevaría en C # / ASP.NET-MVC, por ejemplo. Ciertamente, nunca me llevó tanto tiempo aprender mis tecnologías originales. De acuerdo, ROR es conciso. Si eso es importante para ti. Pero descubrí que rara vez estaba claro cómo crear código que lograra una tarea. Personalmente, prefiero escribir en un teclado durante 20 segundos para escribir el código que definitivamente funciona, está claro y puede seguirlo, en lugar de escribir el código Ruby breve durante 2 segundos, pero que nunca funciona hasta que estoy despierto toda la noche buscando alguna forma de hacerlo funcionar. Es un horrible y apestoso montón de dodo. ¿Por qué? ¿Es ese código de fuente abierta (como en libre), no produce incentivos para convertirlo en una herramienta de calidad? ¿Demasiados script-kiddies bombeando revisiones y módulos y con mala documentación? No lo sé. Pero cuando finalmente pude escapar del primer proyecto de Ruby-Rails, ¡juré que nunca volvería a meterme en ese lío! no produce incentivos para que sea una herramienta de calidad? ¿Demasiados script-kiddies bombeando revisiones y módulos y con mala documentación? No lo sé. Pero cuando finalmente pude escapar del primer proyecto de Ruby-Rails, ¡juré que nunca volvería a meterme en ese desastre! no produce incentivos para que sea una herramienta de calidad? ¿Demasiados script-kiddies bombeando revisiones y módulos y con mala documentación? No lo sé. Pero cuando finalmente pude escapar del primer proyecto de Ruby-Rails, ¡juré que nunca volvería a meterme en ese desastre!

Le sugiero que mire los índices que evalúan la prevención de diferentes idiomas / scripts. Aquí hay un enlace que puede resultar útil: los profesionales populares utilizan idiomas relacionados con la web.

Esto muestra la popularidad relativa de los idiomas relacionados con la web en función de las búsquedas de ofertas de trabajo en línea.

Estoy de acuerdo con algunas de las respuestas anteriores sobre RoR, he estado desarrollando aplicaciones con RoR durante los últimos dos años. Es realmente bueno con aplicaciones simples, las operaciones CRUD (Crear, Leer, Actualizar y Eliminar) funcionan muy bien, es una bendición para desarrollar aplicaciones simples, pero también son sus limitaciones. Aunque hay muchas gemas que ofrecen varias ventajas y facilidad de uso, es básicamente eso. Al salir de la caja obtendrá todas las aplicaciones retorcidas.

Si usted es un gran equipo que trabaja en una aplicación que utiliza RoR, la delegación de trabajo puede ser difícil de evitar.