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 una buena cosa, es más difícil averiguar el Desventajas de cada uno de ellos.
En particular, tengo curiosidad acerca de los inconvenientes que tiene el aprendizaje y / o el uso de Ruby on Rails en lugar de cualquier otro lenguaje / marco dado.
Hablando desde la experiencia: el inconveniente es que confía mucho en el marco de Rails también . Esto es algo grandioso y maravilloso si solo está escribiendo aplicaciones CRUD simples y nuevas que caen directamente en el "punto ideal" de Rails; su productividad se disparará. Sin embargo, en el momento en que tenga que hacer algo fuera de ese punto clave: interactuar con una base de datos existente, hablar con otra aplicación que no tenga una API JSON o XML definida, implementar un flujo de trabajo complicado, Rails se convertirá en su enemigo. Es posible hacer estas cosas con Rails, pero va "en contra del grano", por lo que básicamente es usted mismo quien decide cómo hacerlo, ya que la comunidad generalmente responde con "Don No hagas eso, no es el método de Rails ": esto se traduce en una pérdida de productividad o en un código muy desordenado, ya que básicamente tienes que hackear el marco de Rails.
También está el inconveniente tácito: todo lo demás parecerá feo y torpe. Una vez que hayas probado el dulce y dulce néctar de los rieles (bueno, evangelizando solo un poco aquí ...) todo lo demás es genial. Volviendo de Rails a PHP, o ASP.NET WebForms, o Java es como caminar en una cama de clavos después de jugar en un exuberante jardín; no verás los otros lenguajes / marcos de trabajo de la misma manera, y aunque aún puedas apreciarlos, anhelarás secretamente el abrazo amoroso de Rails.
Para su primer lenguaje del lado del servidor, creo que puede haber un par de problemas con RoR:
No solo estás aprendiendo un idioma, estás aprendiendo un marco. Definitivamente me tomaría un tiempo para jugar con el viejo rubí antes de saltar a los rieles.
Dado que es un marco, y uno de 'opinión' en eso, creo que le daría un alcance muy limitado de todo lo que sucede en el marco.
En general, Ruby on Rails puede ser un buen punto de partida para comenzar a rodar, 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 es siempre intentar que los paquetes funcionen correctamente y la documentación. El problema con la documentación es que siempre parece estar desactualizado (o es 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 otra como lo indica Ben Coe .
Algo en lo que pensé más tarde y en lugar de hacer un comentario, solo editaré mi respuesta es la siguiente: RoR tiene la oportunidad de arruinar a Ruby para ti. Sé que cuando lo probé, me hizo pensar que "Ruby era estúpida". Luego, unos meses después, decidí darle una oportunidad a Ruby y me encantó el idioma, fue el marco lo que me hizo odiar el idioma. No lo he investigado mucho, pero cuando lo hice, realmente disfruté de Sinatra . Creo que obtuve la alegría que la mayoría de la gente obtiene de RoR de Sinatra.
Si este es su primer lenguaje del lado del servidor, es tan bueno como cualquier otro. Lo que hay que hacer es concentrarse en uno, y después de sentir que lo dominas, explora a los demás y deduce tus propias conclusiones.
Trabajo con RoR y ASP.NET a diario, 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 fanático del control y personalmente me siento atraído por lenguajes fuertemente tipados).
En cualquier caso, digo darle una oportunidad. RoR es un excelente entorno para trabajar, pero antes de saltar directamente a Rails, siéntase cómodo con Ruby como idioma. Más allá de las cosas web, Ruby es un lenguaje de scripts bastante bueno si llegas a tener que administrar una caja * nix y te puede ahorrar un montón de tiempo.
Como alguien que aprendió Rails recientemente (como pasatiempo, nunca lo usó para el desarrollo de nivel 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 confianza en convención sobre configuración .
Esencialmente, si estás acostumbrado a la orientación impulsada por "Buscar en archivos" con una nueva base de código, es probable que el CoC te moleste cuando intentes recoger los rieles. Es genial para los campos verdes de CRUD simples que se realizan precisamente a la manera de Rails (como lo dice Wayne M), pero para algo más único y complicado, será difícil averiguar qué está sucediendo si intentas resolver el flujo buscando cosas en los archivos para ver cómo la tubería está conectada.
Aunque creo que este problema probablemente no será tan grave una vez que tenga mucha más experiencia con Rails. Definitivamente puedo verlo como 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 ver todo lo que se explica 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, quiero comenzar a aplicar X inmediatamente. Incluso cuando no sea la mejor opción. He mejorado en esto, pero sigue siendo una fuerte tendencia.
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 mente las alternativas, especialmente si comienza a hacer más desarrollo web. RoR puede ser una exageración para algunos problemas, una solución inadecuada para otros y la mejor opción para un conjunto diferente. Conozca sus fortalezas, debilidades y cómo usar la herramienta.
Mi consejo sería tener una imagen clara del proyecto que desea completar y luego comenzar a tratar de construirlo. A medida que se encuentre con problemas, eventualmente obtendrá 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 lo cortan en mi experiencia; También dejan mucho espacio abierto para la distracción. Cuando tienes un libro, los editores tienen que 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 los que se quejan poéticamente de lo que es un paseo por el jardín Ruby-on-Rails. Llegué a él como un desarrollador de ASP.NET-MVC, Java, PHP, Python con experiencia, ¡y descubrí que era el desperdicio de tiempo más horrible! El 90 por ciento de las respuestas de google en línea son incorrectas o incompletas. ¿Por qué? ¿Ha cambiado mucho cada año? ¿O es que a nadie le importa que el código funcione? Me tomó mucho tiempo simplemente hacer cosas simples; mucho, mucho más de lo que me llevaría en C # / ASP.NET-MVC, por ejemplo. Ciertamente, nunca me llevó a ningún lado tanto tiempo aprender mis tecnologías originales. Concedido, ROR es conciso. Si eso es importante para ti. Pero encontré que rara vez es claro cómo crear código que pueda realizar una tarea. Personalmente, preferiría escribir en un teclado durante 20 segundos para escribir un código que definitivamente funciona, está claro y puede seguirlo, en lugar de teclear el código Ruby terso durante 2 segundos, pero que nunca funciona hasta que estoy despierto toda la noche buscando algo. Manera de hacerlo funcionar realmente. Es un horrible y apestoso montón de dodo. ¿Por qué? ¿Es que el código de código abierto (como en el código libre) no produce incentivos para convertirlo en una herramienta de calidad? ¿Demasiados scripts para niños enviando revisiones y módulos y documentación errónea? No lo sé. Pero cuando finalmente pude escapar de ese primer proyecto de Ruby-Rails, ¡juré que nunca volvería a meterme en ese lío!
Le sugiero que mire los índices que califican el prevelance de diferentes lenguajes / scripts. Aquí hay un enlace que podría ser útil: lenguajes populares utilizados profesionalmente relacionados con la web.
Esto muestra la relativa popularidad 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 el desarrollo de aplicaciones simples, pero también son sus limitaciones. Aunque hay muchas gemas que ofrecen varias ventajas y facilidad de uso, es básicamente todo. Salir de la caja hará que todas las aplicaciones estén distorsionadas.
Si eres un equipo grande que trabaja en una aplicación que usa RoR, puede ser difícil salirse con la delegación de trabajo.
Lea otras preguntas en las etiquetas server-side ruby-on-rails