miércoles
ago202014
Los 4 Framework Web Java mas usados
javaHispano
Según la última encuesta de RebelLabs sobre frameworks Web Java, aquellos basados en SPI (single page interface) se están popularizando, muestra de ello es que frameworks puramente RIA: Vaadin y GWT ocupan los puestos 3 y 4.
Pero lo que también resulta interesante es que la mayoría de los encuestados afirman no usar sólo un framework, supongo que basados en la naturaleza de la aplicación a desarrollar deciden utilizar la tecnología mas apropiada para cada caso.
Nota: noticia enviada por manolo
Reader Comments (20)
cuantos de ustedes son spring mvc haters igual que yo
Luis, ¿por qué eres hater de Spring MVC? Simplemente por curiosidad.
Spring MVC tiene una excelente arquitectura al combinarlo con jQuery y ajax funcionan muy bien y todo queda bien organizado en capas.
Luis, ¿por qué odias Spring MVC? Razónalo tío, que generamos un debate chulo.
A mi me sorprende mucho el bajo uso de Struts 2 (según esta encuesta).
Búsquedas de Google:
Spring mvc -> 1,010,000 results
Struts 2 -> 597,000 results
Jsf 2 -> 548,000 results
Struts 1 -> 481,000 results
¿Quién de vosotros hace uso de Struts2? Podríamos hacer una "miniencuesta" para ver la validez de esta encuesta.
Por ejemplo, yo uso JSP y Servlets :) (y no es broma)
En esta búsqueda falta la comparacion con el estandar JAX-RS, implementado nativamente en los servidores de aplicationes JEE6+.
La implementación de referencia es Jersey y JBOSS tiene como implementación RESTEasy.
Utilizando estas librerias en el front-end puedes trabajar con los nuevos frameworks Javascript (AngularJs, Kendo ui, Knockout, etc)... Con Spring MVC puedes hacer lo mismo, retornando JSON, pero si hay un estándar que hace lo mismo yo prefiero utilizar el estandar.
hola, alguno de ustedes ha tenido experiencia creando un framework de desarrollo en Spring? tengo muchas dudas al respecto y ando perdida
jcarmonaloeches yo he escuchado a mucha gente decir que los Servlets están obsoletos al igual que jsp. Simplemente no saben de lo que hablan.
No siempre hay que usar un framework, hay aplicaciones que no lo requieren pero parece que hay gente que sin framework no sabe programar.....
https://github.com/viranzo/SpringMVC-Hibernate
Concidero que spring en general es la respuesta a muchas cosas que faltan en el estándar Java EE. Como comenta un usuario, Mvc + componentes javascript es una combinación muy buena y liviana. Los servlet nunca pasaran de moda mientras sean la base de las aplicaciones y web y framework (FacesServlet, DispatchetServlet,etc)
Yo no he utilizado struts 2 porque en las mayoría de los casos nuestros clientes ya han definido el uso de spring o jsf, pero sería interesante tener una opinión de los usuarios que utilizan struts 2 y nos hablaran de sus ventaja.
Saludos!
Pedro, no sabes cuánta razón tienes. Un ejemplo:
Uno de los últimos trabajos entregados por uno de los proveedores que trabajan para nosotros consistía en un par de servicios web con dos querys sql en total. Las estadísticas del entregable final (rechazado) son:
* 40K de código compilado. 17M de empaquetado.
* 30 clases. 84 métodos.
* Unas 1260 líneas de código (ncloc).
* 44 bibliotecas necesarias para la ejecución. De ellas 2 sí eran necesarias.
* Spring, hibernate y Apache-cxf forman la "solución" elegida.
Personalmente me parece un despropósito esas "decisiones técnicas".
Pero lo más grave es que la misma empresa adopta siempre la misma solución para resolver problemas heterogéneos, lo que me induce a pensar... Bueno, es obvio, ¿no?
Ramón: y exactamente cuál es el argumento para el rechazo? Que llevaba 2 librerías en el war que no usaban? Que ocupaba 17M? El tamaño del entregable es más importante que la capacidad de extensibilidad del sistema u otras características?
IMHO, que lleve 2 librerias que no usa habla muy mal del equipo de desarrollo y que use hibernate si sólo va a hacer selects en sql también, al menos de quién toma las decisiones en ese equipo.
Pero que hayan decidido usar spring y apache-cxf me parece muy correcto. Aún para un proyecto pequeño, el core de Spring te proporciona características y patrones que deberían formar parte de casi cualquier desarrollo. Y Apache-cxf me parece un buen framework para desarrollar servicios web, aunque yo uso Axis2.
No siempre hay que usar un framework, pero lo que nunca habría que hacer es reinventar uno existente.
Lo de las métricas me ha parecido interesante. Como proveedor, mis clientes nunca me han hecho algo así. Nosotros tenemos nuestro propio sistema de métricas y te recomendaría que añadiras algo de complejidad ciclomática, % de código duplicado, tamaño máximo de clase y tamaño máximo de método. Metricas que dicen mucho más de la calidad de programación que el tamaño del entregable.
Anonimo. No has leído correctamente mi post, lo que decía en mi post era que de las 44 bibliotecas sólo "2 sí eran necesarias", es decir no encontraba justificación para las otras 42.
Puede que no compartas mi opinión, pero para mí esa solución para 2 querys de sql y 2 servicios exportados es como matar moscas a cañonazos: requiere de más recursos en el servidor de los que realmente son necesarios, y evidencia que no ha existido ningún tipo de análisis y/o diseño.
Respecto de las métricas, te agradezco el consejo, y añado:
la complejidad ciclomática es sólo una de las muchas métricas que medimos en todas las entregas de todos nuestros proveedores desde hace años, y les exigimos alcanzar ciertos valores en ellas.
Tenemos montado un sistema de integración continua (Jenkins) enlazado con un gestor de repositorios Maven (Nexus) (nuestros proyectos son todos en Java) y unido a un medidor de métricas (SonarQube), así que en cuestión de métricas creemos estar bien cubiertos, para desgracia de nuestros proveedores. De otro modo no seríamos capaces de gestionar adecuadamente proyectos de cien o doscientas mil líneas de NLOC, o el más grande, de casi un millón de NLOC.
Respecto a los argumentos para el rechazo te voy a dar el principal: hemos prohibido a TODOS nuestros proveedores que empleen cualquier biblioteca en los proyectos sin consultarlo con nosotros antes. Están advertidos de que es necesario una justificación, y que el dimensionamiento del proyecto puede no justificar su uso. Eso no quiere decir que no los permitamos, en algún proyecto se permiten, pero no los permitimos en uno tan sencillo como el que mencionaba.
Que maravilla, Ramón! Ojalá todos los clientes fueran así de exigentes en su relación con los proveedores. Qué diferente sería nuestro sector si esto fuera así!
Tienes razón. Me he confundido con los 2 "necesario" distintos que habías puesto. Desconozco tus argumentos pero 2 librerias para un proyecto así me parecen pocas. Por muy simple que lo quieras hacer necesitas al menos un motor de servicios web que ya llevará sus propias dependencias transitivas (y suelen ser muchas). Ponle además un motor OXM para facilitar el desarrollo a poco que el interfaz del servicio pase de 3-4 strings. A eso sumale librerias básicas para cualquier proyecto como logging, commons o incluso joda-time si vas a hacer algo complejo con fechas. Entiendo también que estas 44 librerías que comentas van en el artefacto y no en el proyecto en sí, donde habría que sumar las librerias de testing, mocking, etc.
Por curiosidad le he echado un vistazo a un proyecto nuestro similar al que comentas. Aunque nosotros usamos Axis2 que tiene sus propios artefactos AAR en lugar de WAR y eso nos permite tener que incluir las librerias de Axis2 en el artefacto. El resultado es que nuestro servicio web ocupa 5M y tiene 17 librerias. 15 de ellas son de Spring y dependencias de Spring. Las otras 2 son el oxm empaquetado en un jar en lugar de tenerlo desperdigado por los fuentes propios del proyecto y una libreria propia con utilidades para proyectos de este tipo (servicios web axis2 con spring y jdbc).
Creo que como cliente no deberías dejar que tus proveedores implementaran sus propios patrones de inyección de dependencias, aop, control de transacciones y utilidades de JDBC. Por muy simple que te pueda parecer tu proyecto inicialmente.
Tampoco creo que te interese que el proveedor se ponga a construir a partir de un servlet su propio motor soap y se lie a concatenar strings para formar XML (lo he visto, peor aún, me ha tocado mantenerlo siendo proyecto de otro proveedor).
Pero viendo la estupenda plataforma de control de calidad que has montado, entiendo que tu problema ha sido que no han sabido justificarte el uso de esas 42 librerías (a todas luces demasiadas) y no que pienses que sólo hacen falta 2 para montar un servicio web.
Y de nuevo, gracias por ser tan exigente con tus proveedores!
Pago, luego exijo... y pongo coondiciones.
Entre vuestra solución y la de mi proveedor media un mundo, pero tampoco deseaba iniciar un debate sobre lo que considero aceptable o no en términos de solución. Quizá mi condicionante es que comencé a programar en Java a finales de 1999. He pasado por todas las euforias de cada momento, y he sufrido los problemas de muchas de ellas. Estoy convencido de que en pequeños proyectos la mejor solución es también la más simple, y eso significa la menor dependencia externa posible. En las reuniones con nuestros proveedores era frecuente la "justificación" del bug de la biblioteca... que ellos elegían utilizar... no es excusa, como si tienen que parchear ese software.
Ramón y anónimo, me ha encantado vuestra mini conversación. Mi perfil es puramente de sistemas, pero siempre me ha picado el gusanillo de la programación. Ahora que le estoy pegando más fuerte, por necesidades laborales y por "gusto" personal, empiezo a ver todo el tema librerías y codificación mucho más cercano. Es más, me pego una semana investigando y viendo si realmente necesito una librería o no... Evidentemente puedo hacer esto porque es a nivel personal, pero en el mercado laboral es diferente, presiones, carga laboral, fechas de entrega, etc... La verdad es que tiene que ser complejo. Una cosa que intento meter en mi mente, y que poco a poco voy viendo como mejora mi código (si, lo veo), es el principio KISS (Keep It Simple, Stupid!). Me ha ayudado mucho. También habéis abierto mi curiosidad por el tema métricas, el cual voy a investigar como se suele hacer. Saludos!
Guao.. me leí todos sus comentarios.. deben ser unos duros en la programación java..yo también quiero ser un experto como ustedes. Algún día, mientras tanto sigo entrenando. Saludos.
Yo no soy un MVC hater ... pero comparto en cierto modo el sentimiento de Luis porque SpringMVC parece estupendo para una aplicación fullstack ... y sí soy un fullstack hater.
Creo que la arquitectura cliente servidor con una API REST abierta para un conjunto de clientes heterogéneo AngularJS, Android, ... es bástante más interesante que un fullstack y ofrece más sinergias de cara a una evolución a microservices, desacoplamiento, más flexibilidad en despliegues, separación de tareas/aspectos, ...
En este sentido SMVC me carga con muchas cosas que no me interesan en absoluto. Actualmente no conozco un framework que cubra mis necesidades, o sea ... una arquitectura plugable (con plugins disponibles estilo grails o play) pero que me permita deshacerme de todo el sobrepeso que no es requerido para una API REST
Me sorprende el poco uso de grails, recien comence a ocuparlo y me parece mucho mejor que JSF, con groovy como lenguaje dinamico y con su paradigma hace las cosas mas sencillas, la verdad se los recomiendo
Deberian probar OpenXava
Buenas gente les dejo la posta de el uso con de tendencia de google:
link