[Ubuntu-ni] ¿Ruby on Rails está muerto? jajajaja

Hiko_Hitokiri lastvnm en gmail.com
Dom Oct 28 20:12:45 GMT 2007 

esa vos me agrada... lo unico que los frameworks son para araganes wuevones
y demas jajajajaja.. solo usen editores con ayuda nosea como los de
dreanweaver jajaja windowzeros

El día 28/10/07, Igor Guerrero <igfgt1 en gmail.com> escribió:
>
> Creo que el hecho de que todos quieran copiar a RoR es ya un exito para el
> framework.
>
> La *unica* ventaja que se le da a Ruby on Rails en este articulo es en
> realidad la razon por la cual Rails es Rails... y eso es por Ruby, y
> desgraciadamente tanto Java como PHP se quedan cortisimos al querer igualar
> la calidad de lenguaje que es Ruby, talves Python puede hacer eso usando
> Django que es un framework no tan popular como Rails pero igual de poderoso
> y pragmatico(Y no es una copia de Rails).
>
> On 10/28/07, Celvin Rivas <josecelvin en gmail.com> wrote:
>
> > ¿Ruby on Rails está muerto?
> >
> > La sensación general de los que escriben éste artículo es que Ruby on
> > Rails está muerto. O mejor dicho: *el efecto Ruby on Rails ha muerto.*El objetivo de éste artículo es plasmar un breve análisis que hemos
> > realizado entorno a Ruby on Rails (en adelante, RoR) , tratando de comprobar
> > si realmente el efecto RoRls está muerto. Y, sobre todo, queremos abordar la
> > cuestión abandonando todo fanatismo y defensa sectarea de cualquier
> > lenguaje.
> >
> > No es difícil observar cómo se ha incrementado la popularidad de *Ruby*en los últimos años. Desde el nacimiento y popularización de su framework
> > *RoR* se han escrito ríos de tinta a favor y en contra de ésta solución
> > para el desarrollo web.
> >
> > Nuestra tesis dice que:
> >
> >
> >    1. pese a *RoR* nada más salir parecía netamente mejor que otras
> >    opciones como *PHP* o *Java*, se demuestra que realmente es débil
> >    donde *PHP* o *Java * son fuertes con lo que, si es mejor que *PHP
> >    * o *Java*, lo es sólo en parte.
> >    2. *PHP* y *Java* han ido absorbiendo o absorberán la mayoría de
> >    las ventajas de *RoR* con lo que las razones para pasarse a *RoR*desaparecerán casi completamente.
> >
> >
> > Es por ello que el descubrimiento de que *RoR* tiene desventajas y la
> > reacción de *PHP* y *Java* para igualarse en sus ventajas hace que
> > desaparezca la necesidad de aprender o adoptar *RoR*.
> >
> > *Reacción de PHP a la llegada de RoR*
> >
> > Existen frameworks profesionales en PHP de una calidad comparable a la
> > de RoR como por ejemplo Symphony <http://www.symfony-project.com/blog/>o
> > Cake <http://www.symfony-project.com/blog/>. Sin embargo, el ejemplo
> > claro sería el Zend Framework<http://www.programania.net/category/php/zend-framework/>
> > que nació directamente como reacción a RoR. Los otros dos existían
> > antes. El Zend Framework es un conjunto de clases muy desacopladas que
> > siguen conceptos como MVC, Active Record, Inyección de dependencias,
> > DSL, pruebas unitarias, etc. Hace poco se ha publicado la versión 1.0
> > que ofrece suficientes garantías como para ser utilizada en producción.
> >
> > *Reacción de Java frente a la llegada de RoR*
> >
> > No se puede hablar de una absorción de Ruby puramente dicha, pero si
> > que es verdad que sus ideas se han tomado en serio en varios sectores
> > de la comunidad.
> >
> >
> >    - *JBullet*: Framework Web basado absolutamente en Conventions. Más
> >    información sobre jBullet<http://www.programania.net/category/java/jbullet/>
> >    .
> >    - *ActiveHibernate *: Proyecto cuyo objetivo es unir la
> >    facilidad del patrón Active Record de Ruby y la potencia de
> >    Hibernate,
> >    de tal manera que sea más fácil de configurar y manejar que la
> >    actual
> >    versión de Hibernate. Más información sobre ActiveHibernate
> >    <http://www.programania.net/programacion/activehibernate/>.
> >    - *Spring MVC:* Incorpora la posibilidad de programar con
> >    conventions, eliminando la navegación del fichero de configuración. Más
> >    información sobre Spring MVC.<http://www.programania.net/programacion/orientada-a-objetos/spring-mvc-vs-struts/>
> >
> >
> > Actual estandar en *Java Spring* considerado por muchos la nueva *J2EE*,
> > habrá que esperar a ver que hacen estos chicos en la versión 3, si
> > apuestan por adoptar estas ideas ya se pueden ir despidiendo los de *
> > Ruby*,
> > lo que no se como de costoso es adaptar el actual framework para que
> > funcione con las ideas de Ruby, a lo mejor es peor el remedio que la
> > enfermedad. Tendrían eso pendiente e incorporar la posibilidad de
> > utilizar componentes *Ajax* desde *Spring MVC*.
> >
> > *Fortalezas y debilidades de RoR*
> >
> > *Desventaja:La paradoja de Ruby on Rails.*
> >
> > La genialidad del lenguaje Ruby mezclada con el acierto del espíritu Conventions
> > over Configurations
> > <http://www.programania.net/java/struts-framework/conventions-over-configurations/>
> > convierte Ruby on Rails en una estupenda opción para desarrollar sitios
> > realmente grandes (menos código, más fácil de mantener, más reusable)….
> > pero Ruby no escala para sitios grandes, con lo que se convierte en una
> > opción útil sólo cuando quieres programar sitios grandes y complejos
> > con pocos usuarios…
> >
> > *Desventaja:Problemática de la escalabilidad*
> >
> > Existen dos problemas relacionados con el rendimiento de las
> > aplicaciones web: cómo se incrementa el coste (de desarrollo o de
> > hardware) cuando se incrementa el número de usuarios, y cómo afecta al
> > coste el necesitar enormes transacciones con bases de datos. Java
> > tradicionalmente es la opción elegida cuando se trata de transacciones:
> > tiene una probada eficacia en bancos, etc. PHP, en cambio, es la opción
> > dominante en la mayoría de portales con miles de usuarios.
> >
> > *Ventajas: qué hace a Ruby un lenguaje orientado a objetos más poderoso
> > que el resto*
> >
> >
> >    - Closures <http://martinfowler.com/bliki/Closure.html> (Blocks):
> >    Es la posibilidad de pasar como argumento trozos de código.Unaorientación a objetos total. Realmente poderoso.
> >    - mixing<http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/>
> >    :
> >    es otra forma de reutilizar código. No es exactamente herencia
> >    múltiple, si no más bien la posibilidad de hacer el include de una
> >    clase en otra.
> >
> >
> > *Cosas de RoR que también hay en los otros lenguajes: *
> >
> >
> >    - MVC <http://wiki.rubyonrails.org/rails/pages/MVC>: Java<http://struts.apache.org/>,
> >    PHP <http://framework.zend.com/manual/en/zend.controller.html>.
> >    - Active Record<http://wiki.rubyonrails.org/rails/pages/ActiveRecord>:
> >    Java <http://www.programania.net/programacion/activehibernate/>,
> >    PHP<http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Table+-+OO+Interface+Enhancements>
> >    .
> >    - AJAX Helpers<http://wiki.rubyonrails.org/rails/pages/How+to+use+the+Ajax+helpers>:
> >    Java <http://json.org/java/>, PHP<http://ajaxian.com/archives/creating-an-ajax-login-page-with-dojozend-framework>
> >    .
> >    - Pruebas unitarias <http://manuals.rubyonrails.com/read/book/5>:
> >    PHP <http://www.phpunit.de/>, Java <http://www.junit.org/>
> >
> >
> > *Conclusión*
> >
> > Con la información que tenemos disponible resulta difícil concluir
> > categóricamente que el efecto RoR esté muerto. Resulta sorprendente la
> > baja calidad de muchas de las críticas que se realizan entre los
> > diferentes partidarios de los distintos lenguajes. Cuando pensamos en
> > éste artículo nos sentimos con la suficiente fuerza como para demostrar
> > que RoR no tenía futuro. Admitimos que nos hemos quedado un poco a
> > medias. De todas formas esperamos que ayude a reflexionar sobre el tema
> > y a abrir debate.
> >
> > ------------------------------------------------------------------------------------------------------------------
> > CELVIN: La fuente original del documento es
> > http://www.programacion.com/noticia/1516/
> >
> > ------------------------------------------------------------------------------------------------------------------
> >
> > --
> > Ubuntu-ni mailing list
> > Ubuntu-ni en lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-ni
> >
> >
>
>
> --
> :::lxuser 391715:::
> http://igordevlog.blogspot.com/
> --
> Ubuntu-ni mailing list
> Ubuntu-ni en lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ni
>
>


-- 
hiko_hitokiri
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://lists.ubuntu.com/archives/ubuntu-ni/attachments/20071028/d8928c79/attachment.htm

Más información sobre la lista de distribución Ubuntu-ni