2009-07-08 10 views
14

He estado usando Grails durante los últimos meses y realmente me gusta, especialmente GORM. Sin embargo, me estoy interesando en Scala's Lift. Por lo tanto, me gustaría saber su opinión sobre qué tipo de aplicaciones web son más adecuadas para cuál de esos dos marcos o si solo es cuestión de gustos, ¿qué marco utilizar?Grails - Lift: ¿Qué estructura es más adecuada para qué tipo de aplicaciones?

Finalmente, ¿cuál de esos marcos cree que serán más utilizados en el futuro? Tengo la sensación de que Grails está lejos de alcanzar una masa crítica y sigue siendo muy oscuro (en los últimos meses tuve la oportunidad de trabajar con empresas medianas y startups de TI trabajando principalmente con la pila JVM y solo una persona sabía y usó Grails) y ni siquiera estoy seguro de si puede convertirse en el "RoR" del mundo de Java (de hecho informa una caída de crecimiento en los últimos meses, incluso si otros marcos tienen una tasa de crecimiento positiva). Y me encanta Groovy, es realmente fácil de aprender, pero he notado lo lento que puede ser para algunas tareas.

Por otro lado, Scala parece ser más popular (Tiobe Index) y el hecho de que Twitter lo esté usando ahora le dio una presencia aún mayor en la blogósfera con muchos amantes y enemigos haciendo ruido. Es famoso por ser rápido y escalable. Sin embargo, el lenguaje parece algo difícil de entender y aprender para muchos desarrolladores (por lo que tal vez nunca gane el estatus de mainstream). El ascensor es poco conocido y he leído algunos informes de que es más adecuado para aplicaciones pequeñas (menos de 20 clases de dominio).

Al ver la cantidad de libros publicados, Groovy-Grails domina en este momento, pero muchos editores tienen libros de Scala en las obras, por lo que creo que esta ventaja no durará mucho.

Finalmente, tenemos el problema de que tanto los lenguajes como los marcos aún tienen un soporte IDE deficiente (está mejorando cada día pero lejos de lo que las tiendas Java esperan que sea productivo).

No quiero comenzar una guerra de llama, pero estaría muy interesado en escuchar las opiniones de otros usuarios.

+2

Grails no tiene un soporte IDE deficiente, de hecho, tiene un excelente soporte IDE en comparación con la mayoría de los marcos web RAD - Intellij IDEA tiene soporte para grillas sin rival.El único inconveniente es su comercial (y no es realmente una desventaja, quiero decir, es hora de pagar por su software, no siempre se puede esperar software gratuito, pero de alta calidad ... pero eso es otro debate todos juntos ...) – Chii

+0

SpringSource Tool Suite (basado en Eclipse) ahora es gratuito e incluye soporte decente de Grails. –

+0

El soporte para griales es bueno con GGTS: http://grails.org/products/ggts – Jayan

Respuesta

1

Grails es una buena idea (pero solo "robada" de los rieles) pero el hecho de que los tipos geniales no estén interesados ​​en obtener la compatibilidad adecuada con Eclipse está obstaculizando mucho su éxito. Incluso he visto las preguntas de Eclipse sin respuesta en las listas de Grails.

Estoy de acuerdo con Tim en que Netbeans 6.7 finalmente ofrece la primera mitad de camino útil Soporte de código abierto IDE para Groovy/Grails - y eventualmente, SpringIDE también contará con mejor soporte Groovy/Grails.

La razón por la que a muchas personas de Java les encanta Java es la tipificación estática, que permite que las herramientas te ayuden en muchas cosas. Esto se pierde con un lenguaje tan maravilloso. Sí, podría escribir cada pieza de código realmente importante en Java y seguir usando Grails, pero entonces, ¿por qué debería, solo para guardar un montón de líneas de código de pegamento, hacerlo en lugar de aprender a usar un framework Java de manera altamente efectiva?

Para terminar: todavía no había mirado a scala, pero construí algunas aplicaciones simples con griales, y tiendo a volver a Java, incluso a reimplementar todas las aplicaciones que necesitan un mayor desarrollo en un marco Java simple - I piensa wicket y Seam.

También veré Scala/Lift, ¡escuché muchas cosas buenas al respecto!

BTW: compararía comunidades y miraría listas de correo - ¿Cuántas personas hay, obtienen buenas respuestas sobre sus preguntas importantes?

Grails parece que tiene una tasa de no respuesta de casi el 50%, lo cual creo que es malo.

+0

"Grails parece tener una tasa de no respuesta de casi el 50%" - 5783 preguntas etiquetadas, sin respuesta 1225 == 22% sin respuesta. –

+3

Lauri, buenas noticias, gracias! Si leyó mi publicación, no estaba hablando de Stack Overflow, sino de la lista de correo del framework. Y es hace 3 años;) – Henning

1

Grails soporte en netbeans 6.7 es realmente bueno, así como la idea de soporte intellij en Maia.

Eclipse sigue siendo bastante sucky.

Miré el ascensor, pero estaba preocupado por los recursos disponibles ahora; esto cambiará en el futuro, pero mis proyectos no pueden esperar.

9

La respuesta aceptada aquí toma una visión realmente ignorante sobre Groovy: es un lenguaje moderno y dinámico (dinámico vs. estático es un gran debate en sí mismo y no particularmente relevante aquí). Esto es por diseño, y por lo tanto no es una desventaja, solo una diferencia. Tiene muchas características de lenguaje moderno que Java no tiene como cierres, expresiones regulares nativas, iteración polimórfica, algunos tipos de tipado estático opcional (materia de debate, pero también mira Groovy ++), sintaxis nativa para listas y mapas, etc. puede ver una comparación aquí http://groovy.codehaus.org/Differences+from+Java

Para abordar la cuestión real de Grails vs. Lift, yo diría que Grails sin ninguna duda. Tiene el SpringSource detrás, y solo mira la página de complementos http://www.grails.org/plugin/category/all - No puedo encontrar qué plugins o equivalentes están disponibles para Lift. Grails también está a la cabeza de las últimas tecnologías compatibles con la nube, con funciones como el soporte nativo de mensajería RabbitMQ y el soporte GORM integral para MongoDB y Redis.

+0

¿No le gusta algo es arrogante? Interesante punto de vista. Y luego, no digo que no ser estático es malo en general. Pero si te gusta estático, bueno, entonces las cosas no estáticas no son tu taza de té por naturaleza. Si te gusta el rojo, el uso de pintura azul para tu casa podría no ajustarse a tu gusto ... – Henning

1

Me gustaría responder específicamente a la pregunta "para qué tipo de aplicaciones". La principal diferencia entre las filosofías de Grails y Lift parece ser que Grails impone MVC, mientras que Lift parece ser más liberal, es decir, no impone MVC, pero proporciona suficientes vías para usar MVC si así lo desea.

También Lift parece ser excelente para 'Aplicaciones de una sola página', especialmente si necesita implementar una funcionalidad de servidor push utilizando tecnología como Comet (lo que obviamente no implica que no sea buena para otros tipos de aplicaciones). Por otro lado, Grails parece ser mejor para las aplicaciones 'Enterprisy', especialmente si ya está familiarizado con Spring e Hibernate, pero quiere que su aplicación sea mucho más concisa (utilizando Convention over Configuration) que lo que haría una aplicación que no sea Grails. estar usando estas tecnologías.


Referencias:

  1. Simply Lift, chapter 13
  2. Single-Page Application

responsabilidad:
acabo de comenzar la exploración de elevación y construido algunas aplicaciones simples de Estados Unidos ing Grails.

1

Con todas las mejoras de rendimiento y avances de Grails2.0, con un gran soporte proporcionado por IntelliJ 11 para el framework, la capacidad de agregar prácticamente cualquier tecnología avanzada a su aplicación Grails. Y sí, el peso de VMware detrás - Realmente no veo cómo Lift podría ser una ventaja o una buena elección. Solo piense en usar dos idiomas diferentes en la misma aplicación, necesidad de doble experiencia en el equipo, etc.

La pregunta original se publicó hace más de 2 años y creo que el tiempo mostró de qué lado está la elección del comunidad de desarrolladores;)

Cuestiones relacionadas