¿Por qué no se utiliza Java para el desarrollo moderno de aplicaciones web? [cerrado]

393

Como programador profesional de Java, he estado tratando de entender: ¿por qué odio a Java por las aplicaciones web modernas?

He notado una tendencia de que de las nuevas empresas web modernas, un porcentaje relativamente pequeño de ellas parece estar usando Java (en comparación con la popularidad general de Java). Cuando le pregunté a algunos sobre esto, típicamente recibí una respuesta como, "Odio Java con pasión". Pero nadie parece ser capaz de dar una respuesta definitiva.

También he escuchado que esta misma comunidad de inicio web se refiere negativamente a los desarrolladores de Java, lo que implica más o menos que son lentos, no creativos, antiguos.

Como resultado, pasé tiempo trabajando para recoger Ruby / Rails, básicamente para descubrir lo que me falta. Pero no puedo evitar pensar: "Podría hacer esto mucho más rápido si estuviera usando Java", principalmente debido a mis niveles de experiencia relativa.

Pero también porque no he visto nada crítico "perdido" de Java, lo que me impide construir la misma aplicación.

Lo que me lleva a mi pregunta (s) :

¿Por qué no se utiliza Java en las aplicaciones web modernas?

  • ¿Es una debilidad del lenguaje?

  • ¿Es un estereotipo injusto de Java porque ha existido durante tanto tiempo (se ha asociado injustamente con sus tecnologías más antiguas y no recibe reconocimiento por sus capacidades "modernas")?

  • ¿El estereotipo negativo de los desarrolladores de Java es demasiado fuerte? (Java ya no es "genial")

  • ¿Las aplicaciones escritas en otros idiomas son realmente más rápidas de construir, más fáciles de mantener y funcionan mejor?

  • ¿Java solo lo utilizan las grandes empresas que son demasiado lentas para adaptarse a un nuevo lenguaje?

acantilado
fuente
142
Creo que eres incorrecto: todavía se usa, solo perdió el factor genial.
41
@Graham Lee: ¿Java ha sido genial alguna vez? Debo haber perdido algo. Bueno, supongo que es café frío, ¿pero genial? Creo que la razón principal es que Java, especialmente los frameworks empresariales de Java, han sido y aún están muy diseñados. No puede considerarlos livianos, solo los usa porque necesita las características de distribución / equilibrio / escalabilidad de la plataforma y desea usar un marco para la interfaz que también se hace con Java, en aras de la homogeneidad.
Falcon
20
Tal vez, porque no es moderno ? : P Y Java nunca fue genial, simplemente porque eliminó la parte de piratería de la programación.
back2dos
28
@Falcon Java fue genial cuando se introdujo por primera vez, Sun hizo un gran trabajo promocionando Java, ya sea que la exageración estuviera justificada o no, no tiene nada que ver con que sea genial o no, se promocionan muchas cosas interesantes sin ninguna razón.
Mahmoud Hossam
11
@Falcon, debería echar un vistazo a la creación de aplicaciones web con JSF 2.0 en Java EE 6 y compararlo con sus experiencias. Puede que se sorprenda gratamente.

Respuestas:

174

Las nuevas empresas modernas deben llegar al mercado lo antes posible. No necesitan pasar unos seis meses para lanzar su aplicación web Java.

Twitter, por ejemplo, se creó con Rails / Ruby, pero una vez que dejó de ser escalable, migraron a la JVM.

Sin mencionar que el proceso de desarrollo no es productivo: código -> compilar -> implementar mientras está en marcos como (Rails / Django / Grails): ejecutar servidor de prueba -> código -> cambiar cosas y ver qué sucede.

La buena noticia es que JRebel le permite ver los cambios de código al instante.

Chiron
fuente
81
Play Framework también es como Ruby on Rails, pero para Java. Código -> actualiza tu navegador.
Jonas
34
Solo trata de deshacerte de algunos conceptos erróneos. Java EE no es lo único en el lado del servidor Java como muchos piensan.
Jonas
22
Facebook también hace algo similar. Su base de código está en PHP, pero debido a problemas de velocidad y escalabilidad, tuvieron que escribir un compilador (HipHop) que compiló PHP a C ++, que luego se compila usando g ++. Es curioso cómo todos hablan de cuán geniales son Ruby y PHP y que todos los sitios están construidos alrededor de ellos, pero luego, cuando miras cuán ineficientes son, la mayoría de las organizaciones grandes tienen que cambiar a otra cosa. Si recuerdo bien, Craigs List tiene una gran cantidad de código de fondo escrito en C / C ++ por esta misma razón.
Kibbee
28
1) Usando Eclipse, la compilación ocurre a medida que escribe y rara vez lo notará. Además, al ejecutar Tomcat dentro de Eclipse, puedo reiniciar una aplicación en menos de un segundo. Raramente me molesta reiniciar mis aplicaciones 2) No hay una bala de plata, muchachos. Ruby o cualquier idioma no te hace 10 veces más rápido. El problema con el desarrollador de Java a menudo es el tiempo de aceleración, pero si sabe lo que está haciendo, puede comenzar a trabajar en un proyecto en <10 minutos.
alex
55
Java y cualquier otro lenguaje estático tienen dos enormes beneficios, una refactorización casi sin preocupaciones y el descubrimiento de API sin documentación.
Eran Medan
136

En mi experiencia, Java para aplicaciones web es excesivo para aplicaciones pequeñas. Un blog simple con una tabla de base de datos contiene entradas de blog, por ejemplo, podría hacerse en algo mucho más simple.

Por lo general, he visto que Java funciona mucho mejor en aplicaciones web mucho más grandes (piense en bancos y compañías de seguros) que se comunican con una serie de otros sistemas (como back-end de mainframe y bases de datos y sistemas de procesamiento por lotes en segundo plano de servicios web similares ... todo en la misma aplicación).

Por lo que he visto, la arquitectura de una aplicación web JavaEE es generalmente más de lo que se necesita para aplicaciones web pequeñas / simples.

FrustratedWithFormsDesigner
fuente
55
Para aplicaciones "pequeñas", esto es aún más cierto si tiene que (porque este es el "estándar" y la compañía lo utiliza) trabajar con servidores de aplicaciones monstruosos como Websphere, mientras que la mayoría de las veces, Tomcat es lo suficientemente bueno. ¿Por qué tengo que trabajar con esa consola de administración desordenada? Suspiro ...
Jalayn
77
@Jalayn: En mi experiencia, es porque solo quieren mantener un programa de servidor de aplicaciones para todo, en lugar de administrar WebSphere para el Equipo A, Tomcat para el Equipo B, Glassfish (o algo más) para el Equipo C ... y puedo entender que también, pero sí, también es frustrante para mí.
FrustratedWithFormsDesigner
3
Esto es cierto para Java EE, pero ahora existe Play Framework que hará que sus aplicaciones web Java sean tan livianas y productivas como Ruby on Rails.
Jonas
99
El nuevo Java 6 EE, especialmente el perfil web, permite algunas aplicaciones web bastante simples.
44
@ ThorbjørnRavnAndersen La aplicación puede ser simple, pero entender el marco no lo es, y tampoco entender las herramientas principales como Ant o Maven. La curva de aprendizaje de un novato es enorme y está llena de capas anidadas de acrónimos, confusión entre las especificaciones (por ejemplo, JAX-RS) y las implicaciones (por ejemplo, Jackson) y más. Es INMENSAMENTE complicado hacer algo simple si realmente quieres entender lo que estás haciendo.
Craig Ringer
135

Programé aplicaciones web de Java durante 10 años antes de cambiarme a Python, hace más de 4 años. Siento que soy mucho más productivo usando Python y puedo hacer mucho más en un período de tiempo más corto, y para ser honesto, estoy mucho más feliz cuando me desarrollo en Python. Estas son algunas de las razones por las que creo que Python es mejor que Java basado en mi experiencia personal, su milagro puede muy.

Marcos web:

Cuando comencé a programar aplicaciones web en Java, Struts acaba de salir, y no fue genial, pero fue lo mejor disponible. Creé un montón de aplicaciones struts, y algunas en otros marcos a lo largo del camino. Cada vez que salía un nuevo marco (Tapiz, Wicket, GWT, stripe, grails, AppFuse, Play, RichFaces, Spring, etc.), lo probaba y veía si era mejor, y la mayoría de las veces era solo un poco mejor , y a veces no mejor en absoluto. Tengo que decir que el marco de juego es un paso en la dirección correcta.

Baterías no incluidas:

Una de las partes más molestas de Java fue el hecho de que la mayoría de las bibliotecas que usa no estaban incluidas en Java, tenía que incluir un montón de librerías de terceros de lugares como apache commons. Si usa algo como hibernar con cualquier otra biblioteca grande, termina en el infierno de dependencia de Jar, donde hibernate necesita una versión de un jar, y algo más necesita otra versión. Si carga los archivos jar en el orden incorrecto, no tiene suerte. Debe depender de herramientas como maven y hiedra para administrar sus dependencias, y esto solo trae más dependencias a su proyecto, lo que resulta en proyectos que son enormes. Tenía algunos archivos de guerra de 100 MB + archivos de guerra para las aplicaciones web más simples.

Demasiadas opciones:

Por alguna razón, parece haber demasiadas formas diferentes de hacer lo mismo en Java. Hay más de 38 marcos web diferentes para java según wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java ) y 23 ORM diferentes ( http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software# Java ) solo por nombrar un par de ejemplos. Si nos fijamos en otros idiomas, tienen un número más razonable. Algunas personas piensan que tener muchas opciones es algo bueno, pero no lo es, lleva a un gran esfuerzo desperdiciado en la comunidad de desarrolladores, todos están reinventando la misma rueda, y si eres una persona nueva en el idioma que tienes demasiadas opciones para elegir.

Servidores de aplicaciones:

Las aplicaciones web Java son realmente pesadas y requieren muchos recursos para ejecutarse. Son especialmente hambrientos de memoria. Al igual que cualquier pieza de software, pueden ajustarse para reducir su huella de recursos, pero en comparación con otros idiomas, su configuración inmediata es horrible. En mi pasado he usado weblogic, websphere, Jboss, tomcat y jetty. Solo usé los primeros tres cuando me vi obligado a usar EJB, pero incluso si no está usando EJB, eran servidores de aplicaciones grandes y, a veces, difíciles de configurar y ejecutar correctamente. Tomcat y Jetty son mucho mejores y más fáciles de configurar, pero siguen siendo grandes recursos.

Alojamiento de aplicaciones:

Si no está ejecutando su propio servidor, es realmente difícil encontrar alojamiento compartido para sus aplicaciones java a un precio razonable. La razón principal es porque las aplicaciones Java requieren mucha más memoria en comparación con otros idiomas, por lo que no tiene sentido que un proveedor de alojamiento compartido gaste su valiosa RAM ejecutando un sitio Java, cuando podrían ejecutar 5 sitios php en el mismo lugar. Eso significa que hay menos proveedores que ofrecen alojamiento Java, lo que a su vez significa mayores costos para ejecutar su sitio web.

Tiempo de desarrollo:

Cuando desarrollé en Java, me encontré mucho más lento que lo que puedo hacer en Python. Tendría que hacer un cambio, compilar, volver a implementar y luego probar, y esto ralentiza el proceso iterativo. Sé que hay formas de hacer esto más rápido, pero incluso en el mejor de los casos, me sentí mucho más lento que lo que puedo hacer en Python.

También hay mucho menos código repetitivo para hacer lo mismo en Python, por lo que también paso menos tiempo desarrollando el código.

Java simplemente se siente sobredimensionado en muchas partes, muchas de las API e interfaces son demasiado complicadas para lo que quieres hacer. Y todos y su hermano piensan que son arquitectos de Java y esto da como resultado grandes sistemas complicados que son difíciles de usar y desarrollar.

IDE:

Cuando estaba desarrollando en Java, me sentí atrapado en el IDE, me perdí sin él. IntelliJ es el mejor IDE del mercado, y fue difícil cambiar a python porque no había nada parecido para python. Entonces, en lugar de un IDE, simplemente utilicé textmate, que es solo un editor de texto normal. Al principio fue difícil, pero como era solo un editor de texto, era una aplicación realmente rápida y receptiva. Podría abrir todo mi proyecto en unos segundos, mientras que cuando quiero abrir un proyecto en un IDE podría llevar un minuto o más, con una máquina con una tonelada de RAM. Los creadores de IntelliJ salieron con un editor de python llamado pycharm, lo compré cuando salió por primera vez, y es genial. Pero me di cuenta de que no necesito un IDE para Python, estoy bien con un editor de texto. Cuando vuelvo a trabajar en aplicaciones web Java que tengo que hacer de vez en cuando, trato de usar el editor de texto, pero todavía no lo he dominado. Personalmente necesito más el IDE para Java porque si estropeo algo, lleva más tiempo volver a compilar y volver a implementar, lo que me ralentiza.

ORM:

Cuando comencé a usar Hibernate como ORM, pensé que era genial, que tenía sus problemas y que no era perfecto, pero era mejor que lo que estaba haciendo antes. Estaba contento con eso, hasta que hice una aplicación con el ORM de Django en un proyecto de Python, y eso me abrió los ojos, así es como se supone que funciona un ORM. Después de ese proyecto, volví a hibernar, y me sentí decepcionado y deseé volver al ORM de Django. Otro gran ORM de Python es sqlalchemy, que es similar al ORM de Django, pero un poco diferente. Tengo una experiencia limitada con el ORM de ROR, pero por lo que recuerdo, también fue bastante bueno.

Plantillas:

Los sistemas de plantillas web en Java no son tan buenos, y creo que los he probado todos (mosaicos, marcadores libres, velocidad, etc.). La mayoría de ellos ofrecen solo funcionalidades básicas y son difíciles de trabajar. En el lado de Python, mis dos favoritos son las plantillas de Django y Jinja2, tienen todo lo que podría necesitar en un motor de plantillas y son realmente fáciles de usar.

Ken Cochrane
fuente
10
Estoy contigo en muchos puntos, pero discrepa con algunos. Compilar / probar el bucle : utilice el módulo web dinámico de Eclipse y / o JRebel, y ya no está; Excelente. Pesadez : JBoss AS 7 es bastante ligero y rápido. y si no quieres EE puedes usar Tomcat o Jetty, que apenas están allí. Pruebas : Arquillian es la mejor herramienta de prueba que he usado en CUALQUIER idioma, aunque solo es lo suficientemente maduro como para ser utilizable. Dependencia del infierno : solo usa Maven; debería ser parte estándar y obligatoria de JAva.
Craig Ringer
Tenga en cuenta que todo lo anterior se suma al problema de "baterías no incluidas", que es enorme. Se siente como Java EE es un sub-marco en el que se supone que debes construir tu propio marco para luego construir tu aplicación. Muy ineficiente Todas las herramientas también tienen errores, y JSF2 es simplemente un instrumento de destrucción de la productividad del desarrollador.
Craig Ringer
2
También creo que te perdiste un punto crítico: la curva de aprendizaje y los errores realmente ralentizan las cosas.
Craig Ringer
@CraigRinger No he usado el módulo web dinámico de eclipse o JRebel, así que tienes razón, podría haber desaparecido.
Ken Cochrane
2
Si te gustó IntelliJ, prueba PyCharm, está basado en el mismo núcleo.
Tamlyn
94

Los principiantes quieren lo brillante. Cualquiera que sea el brillo: RoR, Groovy, Grails, OOP con PHP, Foobar, Wibble, Narf, etc.

Enterprise quiere estable, confiable y escalable: Java y .NET se ajustan a esa factura (cuando se hace correctamente).

Concierto actual: Servicios financieros. Plataforma: ColdFusion (esencialmente una biblioteca de etiquetas Java) y Java.

Conciertos anteriores:

  1. Servicios de pruebas educativas - ColdFusion
  2. Seguro de alto riesgo - ColdFusion y Java
  3. 401k - ColdFusion y Java
  4. Viajes: Java con aplicaciones internas de ColdFusion
  5. Valores - ColdFusion (versión anterior a Java)

Todos estos son sitios de alto volumen y alta seguridad. Nadie en ninguna de estas compañías consideró PHP, algunos miraron RoR y vieron demasiados problemas. La compañía 401k tenía una compañía hermana que ejecutaba una aplicación .NET con desarrolladores competentes, la aplicación seguía fallando cada semana. Finalmente lo convirtieron a Java y ganaron estabilidad.

Las únicas personas que menosprecian a Java son aquellas que tienen poca o ninguna experiencia real con él o han estado involucradas con implementaciones deficientes y ahora son tímidas. Ven el brillo y la figura si todos los niños geniales lo están usando, ¿por qué no yo?

Adrian J. Moreno
fuente
23
"La compañía 401k tenía una compañía hermana que ejecutaba una aplicación .NET con desarrolladores competentes, la aplicación seguía fallando cada semana. Finalmente la convirtieron a Java y ganaron estabilidad". Lol :), he oído hablar del caso contrario.
Den
12
Pues claro que sí. Hay más en las aplicaciones web que escribir código, debe saber cómo ajustar sus servidores, escribir SQL óptimo, etc. Esa compañía tenía 2 desarrolladores de .NET y ningún administrador de servidor real. La compañía que compró la compañía con la que estaba también obtuvo esa aplicación en el trato. Eran una tienda Java masiva y, por lo tanto, tenían más recursos disponibles para garantizar la estabilidad.
Adrian J. Moreno
48
Me parece falso que hayas escrito esa oración declarada como causa y efecto. Convertir a Java = ganancia de estabilidad? Todos sabemos que no es por eso. Además, perdón por toda esa experiencia ColdFusion;)
Jordan
3
Demasiado justo, los inversores tienden a querer ver el sabor del año. Pero personalmente no puedo pensar en una peor opción para el desarrollo rápido de prototipos, salvo los desarrolladores de Java de muy alta calidad que no son fáciles de encontrar.
Erik Reppen
99
desarrolladores Java de muy alta calidad que no son fáciles de encontrar , de hecho.
luis.espinal
73

Una adición a la respuesta de FrustratedWithFormsDesigner : dado que supongo que su pregunta se dirige más a sitios más pequeños, hay un aspecto importante que debe tener en cuenta para muchas personas: el alojamiento es ubicuo para PHP pero es más difícil para los sitios Java o ASP. Sin embargo, esto no es un defecto de esos idiomas.

sebastiangeiger
fuente
Sin embargo, creo que esto ha cambiado, ahora puede alojar aplicaciones web Java en GAE sin costo alguno.
Mahmoud Hossam
+1 para el alojamiento de Java. Aunque ASP.Net no es difícil de encontrar y es barato. Pago $ 8 al mes por mi alojamiento ASP.Net compartido. Por otro lado, quería intentar instalar un sitio en Java y no pude encontrar un host compartido que ejecute Java y tener que usar un VPS no me interesa para un proyecto de aprendizaje.
Jetti
99
+1 por esto. Es mucho más fácil alojar muchos sitios en un servidor para PHP que para Java y, además, es mucho más fácil encontrar soluciones de alojamiento web baratas para PHP que para Java.
Jonas
Tienes razón @ Mark, arreglado.
sebastiangeiger
1
@Kibbee - Arvixe Esa es la persona que uso. Tengo el plan personalASP Pro.
Jetti
70

Java se utiliza absolutamente para el desarrollo moderno de aplicaciones web. Particularmente una vez que llegue al extremo ligeramente más grande / más complejo / escalable del espectro de aplicaciones web.

Si está interesado en herramientas y marcos modernos y productivos, eche un vistazo a:

Pero creo que el desarrollo web más moderno en la plataforma JVM probablemente se realice en uno de los nuevos lenguajes JVM en lugar de usar Java directamente, con Java simplemente proporcionando la columna vertebral en términos de bibliotecas subyacentes e infraestructura de back-end. Hay mucho desarrollo web en Groovy ( Grails ), Scala ( Lift and Play ), JRuby ( JRuby on Rails ) y Clojure ( Noir , Ring / Enlive + muchos frameworks personalizados) por nombrar solo algunos.

Con toda la innovación que está ocurriendo en el nuevo espacio de lenguaje JVM, personalmente sospecho que Java finalmente se convertirá en el "ensamblador de la programación del lado del servidor".

mikera
fuente
Vaadin es una gran herramienta para crear aplicaciones de intranet y grandes empresas. No es tan adecuado para una startup, supongo. Eso es a menos que acepte cómo se ve, porque es demasiado difícil cambiarlo.
naugtur
77
Convenido; Java EE 6 es excelente tan pronto como abandonas JSF2 y usas algo sensato y productivo. Sin embargo, la curva de aprendizaje sigue siendo inmensa .
Craig Ringer
1
Puede agregar Tapestry5 ( tapestry.apache.org ) a su lista de frameworks web Java modernos.
Neeme Praks
@CraigRinger JSF es fácil. Su comentario se lee como la pregunta en sí: una diatriba religiosa
comienza el
@jwenting Bueno, han pasado tres años , por lo que ha mejorado un poco en términos de documentación y herramientas externas desde entonces. En la pila EE 6 cuando estaba trabajando con él, era horrible, más aún si soportaba Glassfish 3 y AS 7.
Craig Ringer
41

¿Google, Amazon o LinkedIn cuentan como modernos?

Java se usa para aplicaciones web modernas. Si observa la empresa, es el lenguaje más utilizado para aplicaciones web (internas).

Dicho esto, Java pasó por un período en el que sus estándares de desarrollo web intentaron ser todo para todos (posiblemente todavía lo sean). "No te repitas" fue una respuesta al infierno xml y a los largos ciclos de desarrollo del desarrollo web Java. Como resultado, Java (EJB, Struts, JSF, etc.) se convirtió en lo que todos los nuevos paradigmas intentaban superar.

Java, el lenguaje es detallado. Eso es un profesional y una estafa (excelente para el mantenimiento, apesta para el desarrollador). Hay una serie de características modernas del lenguaje que aún no se han incorporado a Java que pueden reducir sustancialmente el tiempo de codificación (propiedades, eventos, cierres, generadores, comprensión de listas, etc.). Por lo tanto, puede ser frustrante cuando viene de un lenguaje más moderno. Dicho esto, son difíciles de agregar a un lenguaje maduro sin convertirse en el nido de ratas en el que se está convirtiendo C #.

Muchos lenguajes utilizados en el desarrollo web moderno se escriben dinámicamente. Esto permite herramientas que pueden recargar dinámicamente el código a medida que se escribe (esto es más difícil de lograr en un lenguaje estático: jrebel). Dado que el desarrollo web se presta a iteraciones rápidas, la recarga dinámica es una gran victoria. Reduce significativamente el ciclo de desarrollo en proyectos nuevos y hace que sea más fácil obtener la interfaz de usuario y la experiencia de usuario correctas (prueba y error por naturaleza).

Los idiomas estáticos también tienen su lugar. Para la lógica de backend que es compleja, debe ejecutarse durante años, debe escalar sin problemas, debe ser muy rápida y debe estar completamente libre de errores, se prefieren los lenguajes estáticamente escritos (como Java o incluso C).

Además, a medida que crece el recuento / rotación de desarrolladores y los productos maduran, la probabilidad de que personas bien intencionadas introduzcan errores se dispara. El rigor y la disciplina que impone un proyecto Java bien diseñado (interfaces, patrones y agua bendita para esos vampiros php :)) ayuda a reducir el riesgo a largo plazo. Si bien esto también se puede lograr mediante pruebas unitarias, la red de seguridad derivada de la verificación estática (y analizadores estáticos como findbugs y clang) ofrece un nivel incorporado de cobertura de código que es difícil de replicar con pruebas escritas a mano. No me malinterpreten, debería haber pruebas unitarias y pruebas funcionales, pero las organizaciones reales nunca alcanzan el 100% de cobertura. Por lo que verifican, los analizadores estáticos lo hacen.

Por lo tanto, en proyectos grandes (como se define más por el tamaño del equipo que por el tamaño del código), donde existe una interoperación compleja entre fragmentos de código desarrollados independientemente, aún se prefieren lenguajes como Java. Los ejemplos incluyen aplicaciones web grandes / complejas como las de los corredores financieros (ameritrade), intercambios financieros (nasdaq, nyse, tal vez Londres después de la falla de .net), banca en línea (casi todos), correo electrónico (google), subasta (ebay) etc.

Desde una perspectiva de rendimiento y escala, nada supera a la plataforma Java por su combinación de escalabilidad y rendimiento para aplicaciones web (dependiendo de cómo cuente la partición de aplicaciones de Facebook). Twitter, por ejemplo, tuvo que reescribir grandes partes de su infraestructura de Ruby en Scala en la máquina virtual Java para poder devolver la ballena falsa al mar. He escuchado de otros grandes ejemplos, pero ahora me eluden.

También vale la pena considerar la seguridad. Si bien los complementos del navegador Java han sufrido una buena cantidad de vulnerabilidades de seguridad, la plataforma Java en sí misma es una de las plataformas más seguras creadas. Las aplicaciones web Java tienen la reputación de ser muy seguras. Sus prácticas de codificación, bibliotecas y arquitectura han desalentado durante mucho tiempo los errores que hacen posible ataques como la inyección SQL o el desbordamiento del búfer. Mientras que otras plataformas web (rieles) tienen una buena reputación de seguridad, ninguna supera Java.

En pocas palabras, la mayoría de las aplicaciones web son técnicamente simples. Por simple, Java a menudo es excesivo (al igual que en los viejos tiempos cuando los escribimos en C :)). Sin embargo, si la aplicación web es compleja (backend o no) o se espera que tenga más de 100 desarrolladores, Java es difícil de superar.

-

En una nota personal, uso mucho Grails porque me da lo mejor de ambos mundos (lo mismo se puede decir de JRuby, que escucho que se está volviendo cada vez más popular en el mundo de Ruby).

Por cierto, creo que el aumento de PHP es realmente desconcertante. PHP como lenguaje es el equivalente aproximado de perl en legibilidad y VB en la calidad de los resultados. Fomenta prácticas horribles, es casi imposible de mantener, las bibliotecas de terceros rara vez funcionan como se esperaba, y tiene una sintaxis que llevaría a Larry Wall hacia arriba ... bueno ... un muro. La única explicación que puedo conjurar es que se presta al aprendizaje incremental (como VB). En otras palabras, puede lograr algo útil sabiendo muy poco sobre programación / administración y puede ampliar su conocimiento un poco a la vez. Hay mucho que decir al respecto desde una perspectiva de adopción. Sin embargo, para cualquiera que haya tenido que apoyar o reemplazar una de las miles de millones de aplicaciones VB que fueron escritas por "programadores" en el mundo corporativo / MFG, probablemente esté sacudiendo la cabeza y planeando su jubilación. :)

user56365
fuente
3
¿Te gustaría elaborar el punto "el nido de ratas en el que C # se está convirtiendo"?
XåpplI'-I0llwlg'I -
1
No estoy muy seguro de por qué dice '' No te repitas '' fue una respuesta al infierno xml y a los largos ciclos de desarrollo del desarrollo web Java '. DRY surgió como un concepto en la comunidad Agile, la mayoría de los cuales usaban lenguajes distintos de Java en ese momento.
Julio
38

Bueno, recientemente me reuní con un chico de Java que estaba realmente entusiasmado con el nuevo proyecto Spring Data, debido al poco código que se necesita para obtener acceso CRUD básico a su base de datos.

Puedo construir una aplicación CRUD usando Rails (no solo db access, sino también vistas y controladores) con algunos comandos.

(Fuera de mi cabeza: nuevo proyecto, 1 comando de andamio por entidad, 1 comando para migrar la base de datos, 1 comando para iniciar el servidor).

No tiene nada que ver con el lenguaje, se trata de las herramientas. Y parece que los lenguajes dinámicos tienden a tener las herramientas y los marcos que eliminan una gran cantidad de código repetitivo. (Para compensar nuestra falta de IDE potentes que generan repeticiones para nosotros).

También siento que los lenguajes dinámicos tienden a facilitar la escritura de tales herramientas y marcos. Puedo asimilar el código para decir, Padrino o Rails (marcos web de rubíes) mucho más fácilmente de lo que puedo asimilar el código para decir Spring Roo. Sin embargo, esto podría deberse al hecho de que conozco a Ruby mucho mejor que Java.

Robbie
fuente
24
Personalmente no me gustan los lenguajes dinámicos. Los lenguajes estáticos me hacen más productivo cuando puedo ver todos los errores de tipo rápido en mi IDE y usar herramientas de refactorización. Debe echar un vistazo a Play Framework , es un marco web Java inspirado en Ruby on Rails y lo hace productivo con Java.
Jonas
44
Un marco potente, como los rieles, también significa que si algo está mal implementado, la mayoría de la gente no puede reemplazarlo por otra cosa, porque ese componente está demasiado ajustado con el marco. Mientras que para Java, si no me gusta Hibernate, puedo usar algo más como cayena o JPA, por ejemplo.
Coyote21
2
Como alguien que lucha contra Django, permítanme decir: Coyote21 tiene toda la razón. Puede obtener CRUD básico en cinco minutos, pero en el momento en que comienza a agregar lógica empresarial (cuando se actualiza este registro, se debe insertar un registro en esta tabla y ...) al CRUD, tiene problemas .
asthasr
Si te gusta Rails pero necesitas Java, mira Seam Forge. Cuidado, usa JSF2, que es muy difícil de trabajar, pero Forge es bastante bueno.
Craig Ringer
puedes construir aplicaciones CRUD en Java usando Roo en minutos, lo mismo con Grails (no exactamente Java, pero aún JVM) Play 1.0 tenía generadores / andamios, aunque me pregunto a dónde fue ...
Eran Medan
24

Java ha sido posicionado en los últimos años para ser "empresarial". Que está al otro lado del espectro de lo que necesita una startup. En el desarrollo de aplicaciones web, necesita 4 cosas: acceso sencillo a la base de datos, excelente manipulación de cadenas, sintaxis de azúcar y proceso iterativo rápido para realizar los numerosos pequeños cambios que su aplicación requiere.

El rendimiento, la escalabilidad y la estabilidad son un poco inferiores en la lista de prioridades.

También Java es un lenguaje muy poco divertido para codificar. Obtuvo ayer la capacidad revolucionaria de usar cadenas en una declaración de cambio. Y javascript es un lenguaje muy hacker, por lo que después de desarrollar su interfaz, se siente muy limitado cuando regresa a java.

Así que supongo que estas son las razones por las que los webstartups evitan Java.

Daniel Iankov
fuente
12
acceso db sin dolor? Spring JDBC o Hibernate funcionan muy bien. ¿Gran manipulación de cuerdas? No piense que la manipulación de cadenas es mucho más del 5% en cualquier proyecto. Sintaxis de azúcar? ¿Qué quieres decir con eso? Proceso iterativo rápido? Java lo tiene (Tomcat dentro de Eclipse es indoloro). Java no funciona? Lo único que falta son clases anónimas concisas / lambdas / etc. Las características "divertidas" en otros idiomas tienden a ofuscar y aclarar las cosas. Cadenas en el interruptor ... sí, debo admitir que apesta (sin embargo, la mayoría de las veces, deberías estar usando enumeraciones).
alex
44
@alex: Syntax sugarJava prácticamente no se puede usar para DSL, por ejemplo, el archivo de configuración y rutas de Play no es un archivo Java, está en una sintaxis externa que hace menos que decir django settings.py y urls.py; sin listas de comprensiones; los tipos de datos cruciales (por ejemplo, mapas, listas) no se importan por defecto; una clase idiota por archivo realmente se interpone en el camino; y las API de Java tienden a ser innecesariamente detalladas. Además, no puede usar enumeraciones cuando cambia entre cadenas que recibió del parámetro GET / POST.
Lie Ryan
44
@alex Interesante. Tiendo a usar genéricos en todas partes en C #, aunque mirándolo desde afuera, probablemente se deba a la mayor funcionalidad de las lamdas, por lo que puedo tener un IRepository<T>con un IQueryable<T> Where(Expression<Func<T, Boolean> Expression). Me pregunto si se volverán más populares en Java cuando tenga lambdas. Probablemente sea una cuestión de zona de confort, pero Java simplemente se siente detallado, y al igual que me han entregado suficientes partes para construir 50 tipos diferentes de automóviles sin garantía de que las 2 partes encajen.
Básico
3
No puedo creer que dos personas hayan argumentado que Tomat dentro de Eclipse es indoloro y hace que el desarrollo de Java sea eficiente. Me parece que hace que cada ciclo de desarrollo sea mucho más rápido, pero requiere un mantenimiento diario, que incluye repetidamente actualizar, reconstruir, limpiar tomcat, volver a implementar, reiniciar y, a veces, reiniciar Eclipse y repetir los pasos anteriores. Si mi auto necesitara tanto mantenimiento, nunca iría a trabajar.
Brandon
1
@ Brandon lo secundé. Nunca, ni una sola vez tuve problemas con un problema de configuración en Node o Python / Django. Pierdo la paciencia con RoR. Nuestra base de código Java basada en la dependencia de Ant / Mvn / Spring / Hibernate / eclipse es una pesadilla antes de llegar al código.
Erik Reppen
18

Actualmente trabajo en una compañía que tiene bastantes desarrolladores de "Odio Java". Solía ​​aturdirme también. Ciertamente odio todas las acumulaciones de tecnologías que están disponibles con Java. Esto hace que tomar decisiones sea demasiado difícil. Es como cuando tienes demasiadas opciones, no tienes otra opción. Tienes que pasar tiempo con cientos de marcos para realmente crear el marco que funcione para ti. La arquitectura estándar de Servelt es muy complicada para la mayoría de las aplicaciones. Este no es el caso con Ruby, Django y otras cosas. Son más un marco único que un lenguaje.

Las mayores quejas que escucho de los desarrolladores

  1. La sintaxis es demasiado larga. Solo para imprimir algo tenemos que escribir System.out.print. Realmente no puede usar un simple editor similar a VI y escribir un código de trabajo en unas pocas horas.
  2. Marcos de prueba débiles. Aunque los marcos de prueba son muy similares en Java y Ruby, Ruby da un paso adelante al hacer que las cosas estén fácilmente disponibles para las pruebas. Esto es especialmente cierto si está utilizando DB ampliamente en su aplicación. Incluso muchos de los marcos web no piensan en las pruebas.
  3. Las plantillas son un dolor. Convierte el lenguaje relativamente simple en una sopa de fideos.
  4. No genial La mayoría de las aplicaciones Java están escritas en grandes empresas, lo que está asociado con la burocracia que no va tan bien con los desarrolladores. La gente no piensa en Google cuando piensa en Java. Google == Python. También tiene que hacer mucho sin que salgan libros que indiquen hacer X en Y días.
  5. No me gusta compilar. Para la mayoría de los desarrolladores, la compilación es un fenómeno de hace una década. Tenía sentido en los años 80 con C, pero las computadoras modernas pueden hacer mucho más. No escriben código en idiomas compilados. Java es uno de los pocos idiomas que se compila y se utiliza para escribir aplicaciones web.
  6. Demasiados conceptos de Uy. A pesar de que los desarrolladores han adoptado en silencio el dominio de Oops. No les gusta por completo. No les gusta cuando escribes una aplicación con 10 clases con cada clase haciendo solo una cosa. Hace que abra cientos de archivos e imagine la interacción entre cientos de clases, a veces con marcos. Hace que toda la actividad de programación sea una tarea rutinaria. Esto podría ser cierto con la mayoría de los lenguajes, pero he visto que los desarrolladores de Java prestan mucha atención a lo que hace una clase. Son los desarrolladores de Java quienes a menudo crean un código con cientos de clases. Esto es bueno desde muchas perspectivas, pero los desarrolladores que no son de Java lo odian.

En general, Java impone una curva pronunciada al comienzo del proyecto, lo que significa demasiado dinero para comprometerse. Agregue a esto una gran comunidad unida a Java, cada uno pensando de diferentes maneras y nadie realmente encabeza a toda la comunidad. Tampoco ven charlas y conferencias conducidas por la comunidad mostrando todas las cosas nuevas y geniales. No hay nuevos libros geniales. Parece que Java disminuirá porque se usó para resolver muchos problemas diferentes hace unos años.

armadura
fuente
(2) es abordado maravillosamente por JBoss Arquillian ( arquillian.org ). Gran parte del resto es más un problema de JSF2 que un problema de Java. Los mayores problemas de la OMI son la curva de aprendizaje y la gran cantidad de errores de los marcos, pero si evita JSF2, puede hacerlo bien.
Craig Ringer
55
Amo la POO. También sé OOP, por eso no estoy de acuerdo con que la gran mayoría de los desarrolladores de Java estén haciendo demasiado. Puede escribir una clase, pero si su código sigue siendo un lío de spaghetti enredado, todo lo que realmente hizo fue encontrar una manera (beans) de escribir código de procedimiento basura con estructuras sin sentido envueltas en lo que podrían ser funciones o estructuras simples en el mejor de los casos.
Erik Reppen
2
"La gente no piensa en Google cuando piensa en Java". ... Ciertamente pienso en Android y su VM Dalvik (que es una VM Java) cuando pienso en Google. También pienso en cosas interesantes como GWT (generación automatizada de JavaScript desde Java). Si hay una compañía que es "alta" en Java, es Google. Mucho más que Apple o Microsoft. De acuerdo, Oracle e IBM están aún más asociados a Java que Google, pero aún así: miles de millones de dispositivos Android que ejecutan aplicaciones Java en una máquina virtual Java es algo difícil de pensar sin establecer un enlace Google / Java muy fuerte.
Cedric Martin
Mucho odio hacia JSF2 forma @CraigRinger en estos comentarios. :-) ¿Qué es lo que te molesta? Al principio me pareció complejo, pero una vez que me puse en marcha, me encantó . Por supuesto, estaba usando Spring antes de eso, así que cualquier otra cosa se verá como una mejora ... :-)
Brian Knoblauch
1
Soy un desarrollador de OOP en Java y no puedo exagerar los beneficios de OOP para los desarrolladores. Sí, lleva un poco más de tiempo mientras se desarrolla, pero la tasa de error más baja, legible y más fácil de mantener, vale la pena. Sin mencionar que las pruebas unitarias se vuelven mucho más fáciles con una POO realizada correctamente.
IntelliData
14

Los marcos para hacer desarrollo web Java tienen bastante curva de aprendizaje, a menudo son excesivos para lo que necesita, y gran parte de la indirección requerida para hacer que las cosas funcionen es simplemente ... doloroso ... trabajar con ellos.

Solía ​​trabajar para una empresa que hacía desarrollo de Spring / Java, y encontré el marco engorroso en el mejor de los casos. No tengo muchas cosas agradables que decir sobre el marco de Spring, excepto que tenía un amigo que solía hacer el desarrollo de Struts y pensó que Struts era aún peor. El marco web no se parece en nada a las aplicaciones de escritorio o las aplicaciones móviles (p. Ej .: Android), y tiene muchas ideas muy abstractas que tardan un tiempo en captar realmente (aunque, ciertamente, eso le da mucha potencia y capacidad si usted eres un profesional y haces algo realmente complejo como una aplicación de nivel empresarial). Me encanta programar java para dispositivos móviles o de escritorio, pero ¿java para aplicaciones web? No tanto.

No he hecho ninguna programación personalmente en Ruby / Rails, pero mi amigo que solía hacer Struts ahora está haciendo programación web Ruby y testifica que las cosas que son difíciles de hacer en la programación web Java requieren mucho menos código y complejidad para lograrlo. Rubí. Ciertamente, hay una curva de aprendizaje para las diferentes reglas de sintaxis y lenguaje, pero para las aplicaciones de creación de prototipos, tiene ventajas en términos de cuánto código se requiere para lograr el resultado deseado. Como otros han mencionado, la escalabilidad también es un tema a considerar, y una de las razones por las que las aplicaciones más maduras no se ven con tanta frecuencia en los idiomas más modernos.

Jessica Brown
fuente
+1 por exceso de marco. Se está volviendo loco, Spring J2ee Maven Ant Hibernate, pasas todo tu tiempo escribiendo xml config.
Richard
1
+1 para el marco. No solo los intentos de framework originales eran P ** s Pobres (JSP, STRUTS), ahora tenemos alrededor de treinta para elegir, ninguno de los cuales funciona tan bien como RoR.
James Anderson el
No son solo los marcos. Son los niveles obscenos de conformidad con las cosas que no tienen sentido. Exponer muchas propiedades significa que lo estás haciendo mal. Abofetear a un getter y setter de vainilla que simplemente agrega una llamada de método sin sentido y no cambia nada, sin embargo, ningún desarrollador de Java colgará las propiedades de un objeto como ese, porque la comunidad refuerza que de alguna manera está más mal de lo que ya están haciendo. Pero en serio, el XML en lugar del código ... ¿cómo duró más de 5 minutos?
Erik Reppen
14

Se trata de costos y tendencias. La Web 2.0 Startup es creada por un visionario menor de 30 años que tiene más talento que dinero (estoy generalizando, por supuesto, pero esto es lo que verá "en promedio"). Utilizará un lenguaje con el que está familiarizado porque está haciendo la programación (junto con quizás algunos amigos). Es muy probable que sea un programador autodidacta.

Java se ha dirigido como un entorno empresarial (por Java, me refiero al lenguaje, el marco y los estándares). Hay un montón de herramientas costosas que los IBM, Oracles y BEA del mundo quieren vender a las empresas.

Los pasos para dominar Java son complejos y / o costosos. Sé que el paisaje está cambiando allí, pero ¿es demasiado poco y demasiado tarde?

Después de que la startup gana tracción viene el crecimiento. Reclutar desarrolladores talentosos es difícil. La mayoría de los programas de "convertirse en programador en seis semanas" enseñan Java (o .NET) y el mercado está saturado de "programadores de seis semanas" (curiosamente, he visto desarrolladores con currículums que dicen 7 años de experiencia que todavía muestran el conocimiento de un seis programador semanal). El uso de un entorno no convencional y no "empresarial" puede ser un filtro natural para los programadores de seis semanas. Se necesita dedicación e inversión personal para aprender un Ruby o Scala fuera de un requisito de trabajo. Este es el mayor indicador para mí de potencial para un candidato.

El conocimiento viene con la experiencia, pero un programador dedicado / apasionado obtendrá conocimiento más rápidamente (en promedio) que alguien sin esa dedicación / pasión. Al igual que un niño al que le encanta tocar la guitarra, mejorará más rápidamente que un niño que toma lecciones porque su padre lo hizo.

Michael Brown
fuente
Creo que este es un muy buen punto +1
sfrj
1
No estoy de acuerdo con el párrafo que dice: lo más probable es que sea un programador autodidacta. Esto no es cierto en estos días, hoy en día la mayoría de las personas de los años 30 de ese programa son programadores competentes y tienen al menos un título.
Coyote21
1
??? Estoy pintando el inicio web prototípico. No dije nada sobre ellos siendo competentes. Puedes ser autodidacta y competente al mismo tiempo. No estoy seguro de con qué estás en desacuerdo.
Michael Brown
1
Esta fue mi respuesta. Java es prácticamente la única tecnología web actual que no está diseñada para que cualquier desarrollador competente pueda simplemente recogerla y usarla. La segunda parte de su respuesta es más o menos lo que escribió Paul Graham en The Python Pardox
usuario16764
14

Java es demasiado complicado. Hago un montón de trabajo PHP y es más fácil y rápido para la mayoría de las situaciones. La capacidad de simplemente SSH en un servidor, abrir un archivo php, hacer que los cambios se guarden y se haga es excelente. Las pocas aplicaciones Java en las que he trabajado siempre han requerido un reinicio para el cambio más simple. (No digo que siempre sea el caso con lo que he deltido). Además, el alojamiento PHP es barato y está fácilmente disponible.

También creo que lo que tienes al menos con PHP es que muchos desarrolladores que, como yo, comenzaron hace 14/15 años con HTML estático. A medida que las cosas progresaron, comenzamos a agregar PHP a nuestros sitios porque era fácil, simple y asequible. Con los años, el lenguaje ha crecido y ha expandido sus habilidades mucho más allá de sus humildes comienzos y ahora se esfuerza por ser lo que creo que son muchas cosas que realmente no es.

Por otro lado, la mayoría de los desarrolladores de PHP que conozco ven a Java como este gorila gigante de 800 lb demasiado complejo, casi como salir del camión de 18 ruedas para conducir a la tienda de comestibles y obtener una barra de pan.

Traté de aprender Java, mis primeras impresiones eran muy largas y provocaban el túnel carpiano. Además, comenzar me dejó con muchas preguntas que probablemente parezcan fáciles para un veterano de Java. OpenJDK o Sun? Tomcat, o Glassfish, o? Además, parece que cada introducción al libro de Java comienza a escribir código para la línea de comandos. Creo que la mayoría de la gente en estos días encuentra que un festival de repetición.

Ciro
fuente
3
Tomaré más opciones y un poco más de complejidad sobre los más de 9000 métodos integrados de PHP.
Kaleb Brasee
1
PHP es tan fácil de configurar.
Barfieldmv
99
pero hace que sea tan difícil escribir un buen código ... más fácil de configurar, más fácil de comenzar, menos aburrido no debería ser el criterio que use para elegir un idioma. Una buena programación requiere disciplina, paciencia y esfuerzo ... es una mala señal si no los tienes mientras eliges ...
alex
A menos que ambos apestan, pero uno es mucho más PITA para configurar que el otro.
Erik Reppen
12

Mi equipo y yo actualmente desarrollando una aplicación web totalmente nueva en Java 6 + rayas. En el último año también trabajé en otra aplicación web totalmente nueva usando Java 6 + Stapler (un marco web algo desconocido desarrollado por Kohsuke Kawaguchi de Hudson / Jenkins).

Java se usa absolutamente para el desarrollo web moderno. Ciertamente no tiene el atractivo "sexy" de Ruby u otros lenguajes dinámicos, pero estoy lejos de estar convencido de que los lenguajes dinámicos son algo bueno una vez que un proyecto comienza a escalar.

Los servidores de aplicaciones Java modernos son muy competitivos con ASP.NET en términos de rendimiento, y ambos son mucho más rápidos que cualquier lenguaje dinámico VM que conozco.

No me malinterpreten ... No digo que Java sea siempre la mejor opción (¡ni remotamente!), Pero tampoco es siempre una elección incorrecta u "desactualizada".

Daniel Pryden
fuente
1
Tiendo a estar en desacuerdo con el "más rápido". En teoría deberían serlo, pero hay algunos sitios de php masivos y casi todas las anécdotas sobre problemas de rendimiento se relacionan con MySQql u otras bases de datos subyacentes. Por otro lado, casi todas las aplicaciones J2EE con las que he entrado en contacto necesitaban un ajuste exhaustivo antes de que el rendimiento fuera incluso aceptable.
James Anderson el
1
@ James: ¿Tienes algo más que vagas anécdotas para respaldar eso? Todos los 10 principales sitios web se ejecutan en plataformas administradas (Amazon en Java, Twitter en Scala IIRC, Google en un back-end personalizado de Java y C ++) o tienen una infraestructura altamente personalizada (Facebook y Wikipedia usan PHP, pero ambos tienen enormes cantidades de código nativo personalizado para la velocidad). Java regularmente supera a los lenguajes dinámicos en puntos de referencia. No soy un fanático de Java, pero el rendimiento no es un problema de Java.
Daniel Pryden
No hay problemas de rendimiento con Java en sí mismo "no tan rápido como C pero más rápido que cualquier otra cosa". Sin embargo, J2EE, más frameworks, más ORM, más inyección de dependencia, más diseño excesivo, casi no garantiza su rendimiento; hay demasiado potencial para cuellos de botella ocultos e interacciones imprevistas
James Anderson
1
@Basic: ¿Cuál es tu punto? Hay muchas bibliotecas y marcos rotos para cualquier idioma. Sí, hay mucha documentación cruda y desactualizada, pero eso tampoco es inusual. Por el contrario, hay algunas bibliotecas, marcos y herramientas fantásticos para Java. ¿Estás tratando seriamente de sugerir que debería haber un marco completo para cada aplicación?
Daniel Pryden
1
@Basic: ¿hacia atrás de qué? En el año y medio desde que escribí esta respuesta por primera vez, me mudé y actualmente estoy trabajando en Google, y puedo asegurarle que Java se usa mucho para el desarrollo de aplicaciones web en Google. Por supuesto, las necesidades de Google son muy diferentes de las de muchas otras compañías, pero Java es una bestia completamente diferente cuando usas las bibliotecas y los marcos correctos: solo echa un vistazo a algunas de las cosas que Google ha abierto (Guava, Guice, GWT, Protocol Buffers, etc.).
Daniel Pryden
12
  1. Java es más complejo de aprender que PHP / Python / Ruby
  2. El ecosistema de Java es muy complejo, muy grande y bastante confuso para los principiantes.
  3. Hay muchos marcos históricamente malos con reputaciones negativas asociadas con Java, debe saber qué marcos evitar para perder el tiempo
  4. Las herramientas de compilación de Java son complejas (maven y ant)
  5. Java no tiene un sistema de módulos que sea fácil de usar (OSGI es demasiado complejo)
  6. Java IDE como Eclipse, aunque es muy potente con características sorprendentes, es difícil de configurar para un desarrollo web efectivo sin mucha experiencia.
  7. Si está utilizando algo que no sea Tomcat o Jetty como servidor, se sentirá frustrado por los largos tiempos de inicio de WebSphere / WebLogic / JBOSS
  8. Java EE resuelve problemas que muchas personas no tienen, como transacciones distribuidas

Un nuevo desarrollador que se inicie en el desarrollo profesional encontrará que Java es un orden de magnitud más difícil que los rieles, python o php para comenzar, por lo que van con lo que es fácil de aprender.

Habiendo dicho todo lo anterior, tomé la decisión de usar Java para mi inicio porque un entorno de desarrollo Java configurado correctamente es muy productivo para trabajar. Quiero decir, configurado correctamente.

  1. Menos de 10 segundos de tiempo de arranque
  2. Espacio de trabajo eclipse configurado correctamente, con todos los marcos configurados y configurados
  3. Buena selección de bibliotecas (Spring, Spring MVC, Spring Social, Spring Security, JPA, Hibernate, Velocity, .... etc.)
  4. Máquinas de desarrollo rápido con SSD
  5. Suscripción a Orielly Safari
ams
fuente
8
Sin embargo, seamos claros. El lenguaje Java, no es difícil de aprender. Son todas las capas de basura construidas en torno al trabajo con Java para compensar sus deficiencias (verbosidad, protegerlo de usted y sus compañeros de equipo al ser inflexible como todo, la cantidad absurda de bibliotecas en las que se basa, etc.) eso es un PITA aprender.
Erik Reppen
2
@ErikReppen Muy cierto. Tengo que trabajar en un proyecto Java pero tengo experiencia en .Net. El lenguaje y la sintaxis son fáciles de entender. Es la verbosidad lo que realmente me está volviendo loco. Lo que solía en 1 línea ahora toma 5-10 y (a menudo) una edición de archivo de configuración XML. Sin mencionar que sin pasar horas y horas leyendo, elegir el marco "correcto" para un trabajo es una pesadilla, y eso es antes de que descubras que tu escenario se considera un caso límite, no es compatible y si no te gusta reescribirlo. Quiero pasar mi tiempo resolviendo los grandes problemas
Básico
"Java es más complejo": ¿alguien puede recordar las órdenes de parámetros para PHP strposo in_array? Y la interfaz XML DOM de PHP es ridícula (¿convertir atributos en cadenas para recuperarlos?). OSGi es absolutamente brillante e independiente del idioma.
jevon
@ jevon: los documentos PHP son muy buenos y mi IDE está ansioso por recordarme de todos modos. Además, SimpleXML.
DanMan
12

Alrededor de 5 años atrás, a mí y a un colega nos asignaron una tarea de programación para algún proyecto interno. Una tarea bastante simple que requería el análisis de comandos.

Se me ocurrió todo en aproximadamente 80 líneas de código de Java y mi colega tomó una semana, alrededor de 20 clases de Java y muchas más líneas de código de Java para hacer lo mismo. No hace falta decir que su código fue elegido.

Esto me hizo preguntarme. En todas partes, la complejidad fue apreciada. (Estaba trabajando en una de las compañías de productos de software más grandes). Java era la herramienta elegida y los patrones de diseño eran LA forma de codificar.

Ahora, ¿es la mentalidad o la arrogancia lo que rechaza la simplicidad? Bueno, siempre pensé que debería prevalecer el sentido común. Ya sea una empresa o una aplicación web simple, los casos de uso básicos son los mismos. Debe ser correcto y verificable.

Ya no uso java por varias razones. Pero uno de los factores, la complejidad, es la mentalidad predominante en una tonelada de desarrolladores de Java cuando se trata de desarrollar software.

En cuanto a escalar lenguajes dinámicos, JVM es el resultado de décadas de investigación. Sucede lo mismo para Ruby, etc.

Scala es un idioma que me parece extremadamente inteligente y práctico. ¡Jugar! con Scala es tan excelente para el desarrollo de aplicaciones web / empresariales como cualquier otro.

En cuanto a que Ruby y Rails son lo nuevo y brillante para las nuevas empresas, es extremadamente difícil contratar a un desarrollador de Rails sólido. En realidad, es un impedimento para cualquier puesta en marcha, mientras que la gran cantidad de desarrolladores de Java debería tener más sentido comercial.

Ar Wen
fuente
No soy un fanático de Java, pero esa "complejidad" a la que te refieres puede haber sido abstracción. La abstracción es muy útil tanto para pruebas como para mantenimiento (cuando se usa con moderación). Es difícil decirlo con certeza sin poder comparar el código
básico el
11

En una entrevista reciente con Joseph Snarr, director técnico de google plus, explicó cómo la aplicación usa Java Servlets para el back-end y JavaScript en el front-end.

Entonces, para responder a su pregunta, Java todavía se usa para el desarrollo web muy moderno. Simplemente no para las nuevas empresas que han recibido tanta prensa recientemente.

Creo que la razón por la cual muchas de las nuevas empresas están utilizando otras tecnologías es porque son más sexys y tienen un impulso de código abierto más publicitado detrás de ellas.

Greg Guida
fuente
44
Las nuevas empresas usan otras tecnologías porque quieren hacerlo ahora. Después no. Y lo hicieron para hacerlo ahora como 3 personas, no 30.
Erik Reppen
Citar a una persona solo puede proporcionar sus puntos de vista y sus elecciones, pero no valida que lo que él / ella eligió sea / fue la decisión correcta.
DivKis01
9

Como mencionó el desarrollo web y Java, muchas personas tienden a olvidar que al principio el uso de Applets Java en un navegador web no se realizó bien, no solo eso, sino que el "entorno limitado" para los applets no se desarrolló completamente y hubo problemas de seguridad con Java Applets pudiendo ejecutarse en el navegador y acceder a los datos de la máquina local (también conocido como problema de seguridad del lado del cliente). Claro que Java era sólido en el backend y en las aplicaciones independientes, pero creo que asociar Java el lenguaje con los applets de Java (ejecutados en el navegador) juntos arruinó algunas percepciones sobre Java como un componente de desarrollo web. No creo que se hayan recuperado de eso.

LocoTx
fuente
99
¡Absolutamente no! En realidad, Java es un lenguaje dominante en el mundo del lado del servidor. Applets extinguidos tal vez hace una década.
Quirón
55
Flash hizo lo que Applets intentó ser. Inicio rápido, descarga rápida, huella de memoria baja.
44
Conozco a muchas personas que ni siquiera pueden distinguir entre Java y Javascript. A pesar de que no tienen relación alguna. Esta es otra cosa que le da a Java un mal nombre.
Kibbee
55
@Kibbee ... o le da un mal nombre a Javascript :)
Matthew Schinckel
9

La pregunta debería ser "¿Por qué las startups o los proyectos pequeños no utilizan Java?". Java ciertamente se usa para "aplicaciones web modernas". En Google, Java se usa en el backend para muchos servicios, y JS o GWT compilados para el cierre se usan para la interfaz. El problema es uno de velocidad vs escala. Las startups necesitan llegar al producto mínimo viable. Por lo general, son pequeños equipos de 1-3 ingenieros, y valoran la velocidad de iteración sobre el rendimiento o la capacidad de mantenimiento. Enfrentarse a problemas de escalabilidad o problemas de mantenimiento del código de código del equipo es un problema "que le gustaría tener", es decir, para cuando llegue a esa etapa, es una señal de que su implementación inicial lo ayudó a superar el obstáculo inicial de conseguir clientes o inversión. Puedes permitirte reescribir la aplicación en ese momento.

Una empresa como Google puede permitirse el lujo de construir cosas para escalar por adelantado, a pesar de que pueden estar desperdiciando su tiempo implementando el escalado para algo que podría no tener usuarios, porque pueden absorber la pérdida.

Al menos, esa es mi opinión, que muchas empresas "modernas", "modernas" y "modernas" crean pequeñas aplicaciones con pequeños equipos donde la velocidad de iteración y la simplicidad son los requisitos más importantes.

cromwellian
fuente
1
¿Dónde está tu fuente indicando que las startups no usan Java? Haga una copia de seguridad de su suposición con algunos datos.
Walter
7

Las aplicaciones web tradicionales en Java, aunque bien estructuradas, están muy lejos de "desarrollarse rápidamente". Aunque solo he escrito una aplicación web completa (Java / Tomcat / Struts), fue extremadamente exigente, tardó más de lo esperado en depurar y fue generalmente doloroso al implementar la capa de lógica de negocios. En defensa potencial de Java, era la única aplicación web que había escrito en Java (aunque estoy acostumbrado a programar aplicaciones de nivel de sistemas en Java), y creo que podría escribir otra aplicación web un poco más rápido la segunda vez.

Dicho esto, también he escrito aplicaciones en PHP y C #, y funcionan mejor, y son mucho más indulgentes que Java. Más que eso, Ruby on Rails fue escrito específicamente para el desarrollo rápido de aplicaciones, que, como dijo Robbie, permiten un fácil acceso CRUD a las bases de datos. El problema es que la mayoría de los sitios web que desarrollará por su cuenta no necesitan el nivel de personalización que ofrece Java (y requiere que lo realice). Además, cada objeto de conexión de base de datos debe escribirse a mano y no es tan fácil de configurar. Puede haber un mejor marco, especialmente uno que aproveche las nuevas características de soporte de lenguaje dinámico de Java 7 , pero aún no he investigado.

Brian
fuente
3
Debe echar un vistazo a Play Framework , es un marco web Java que lo hace productivo con Java y está inspirado en Ruby on Rails.
Jonas
2
@Jonas, considera escribir algunas buenas publicaciones de blog que expliquen todo esto de manera concisa.
@Jonas lo que dijo Thorbjorn! Le daría una lectura completa. :)
Brian
@ Thorbjørn: no tengo un blog. En resumen: con Play Framework, solo guarda el código fuente de Java y luego actualiza el navegador web. El código se compila automáticamente del lado del servidor utilizando el compilador Eclipse. JPA se utiliza para acceder a la base de datos. Aquí hay un artículo al respecto Play! Usabilidad del marco
Jonas
2
@ Thorbjørn y Brian: Vea el video en la página principal del sitio web de Play Framework, lo explica muy bien, diría yo.
Bjarke Freund-Hansen
7

Respuesta simple: curva de aprendizaje para basar la productividad.

Los sistemas basados ​​en framework como RoR tienden a poner la "magia" en el lenguaje / sintaxis. Es muy fácil aumentar su sintaxis básica de RoR y poner en marcha una aplicación.

Java fue primero un lenguaje, y las herramientas y los marcos aparecieron más tarde. Entonces, primero debes aprender Java, y luego debes aprender Spring, o Grails, o tu súper IDE, o lo que sea. Ejemplo favorito de Ruby, no requiere setters y getters. El hecho es que los IDE de Java también se deshicieron de la codificación manual ... pero todavía está en su fuente. El beneficio de este enfoque es que, debajo del marco, hay un lenguaje coherente con el que todos los desarrolladores de Java pueden trabajar.

Este beneficio es dudoso para las nuevas empresas pequeñas donde el tiempo es esencial. Por lo general, están haciendo muy poco que no podrían hacer con un marco fuera de la caja. Para que puedan tomar su sistema RAD de elección y tener una aplicación en vivo al día siguiente.

Pero si nos fijamos en Facebook y Twitter, a medida que se expandieron, encontraron cosas que no podían ser manejadas por los marcos de fábrica y, por lo tanto, tuvieron que usar tecnologías de nivel inferior.

Esta guerra santa que tienen los desarrolladores de frameworks de que pueden hacer cualquier cosa más rápido es falsa, pueden hacer mucho de lo que necesitan de manera más simple y con menos curva de aprendizaje. Y para muchas cosas, eso es "lo suficientemente bueno". Use lo que sea correcto para el problema.

Lucas McGregor
fuente
6

Depende de cómo se defina el "desarrollo moderno de aplicaciones web". Si está hablando de sitios web de inicio rápido y de respuesta rápida, deberá considerar los idiomas y los marcos diseñados para ese propósito. Si busca un desarrollo web estable, escalable y de nivel empresarial, busque lenguajes y marcos que admitan esos ideales. En mi libro, esos son dos objetivos muy diferentes. RoR, Groovy, etc., son buenos para el primero y Java es más apropiado, en general, para el segundo.

cdkMoose
fuente
6

Google App Engine es compatible con Java, por lo que puede escribir toda su aplicación web en Java, utilizando Eclipse como IDE e interfaz de implementación, con una API de Google razonablemente documentada, por lo que no diría que no se usa o no usable.

Pablo
fuente
5

En el inicio para el que trabajo, elegimos usar Java y JRuby para implementar nuestra API porque se complementan entre sí.

Para la infraestructura, la distribución de procesos y las comunicaciones, aprovechamos la solidez de Java, mientras que para la implementación real de los puntos finales API elegimos JRuby ya que todas las llamadas involucran a JSON y tiene mucho más sentido manipular una representación de tipo libre (JSON) usando lenguaje tipo (Ruby).

Si vemos que una de nuestras clases JRuby se está convirtiendo en un cuello de botella, simplemente la volvemos a implementar directamente en Java (básicamente, una traducción línea por línea). Esto puede suceder con bastante frecuencia con clases que deben hacer muchos cálculos, y en este contexto JRuby se comporta de manera muy similar a un lenguaje de creación de prototipos.

Implementamos nuestro propio cargador de clases dinámico, lo que significa que podemos cambiar las clases de Java sobre la marcha sin reiniciar el servidor, y estamos muy contentos con la elección. Por lo tanto, el argumento "necesita compilar y reiniciar cada vez" no tiene mucho peso.

La clave es evitar todas las cosas de Java EE: es enorme, engorroso y anti-ágil.

David Semeria
fuente
5

Todavía tengo la sensación de que Java se está utilizando en muchos desarrollos web. Pero generalmente está en el tipo de desarrollos más orientados a los negocios, no principalmente a las grandes empresas tecnológicas, que generalmente son menos abiertos que las nuevas empresas que tienen que obtener cierta tracción y promover su propio trabajo, así como más interesados ​​en la tecnología . Por lo tanto, incluso si se usa en muchos sitios web corporativos, probablemente nunca lo sabrás, ya que realmente no les importará contar públicamente sobre su pila de tecnología.

Dicho eso, comentando todas las preguntas originales ...

¿Es una debilidad del lenguaje? En comparación con otros lenguajes como Python o Ruby, Java es detallado y tiende a necesitar más código para hacer cosas similares. Pero no son solo las capacidades del lenguaje, también la comunidad que lo rodea y el tipo de desarrolladores que usan esas herramientas. Por lo tanto, la mayoría de los módulos y herramientas en Python, Ruby, PHP, etc. son de código abierto y son más fáciles de encontrar que en el mundo Java, solo porque este está más enfocado en dar (y cobrar) servicios. Por ejemplo, la comunidad Ruby está realmente orientada al desarrollo web, por lo que cada desarrollador que pueda usar Ruby sabrá sobre los problemas y las herramientas disponibles para un proyecto web. Eso no es necesariamente cierto para los desarrolladores de Java, que podrían haber estado trabajando en otro tipo de sistemas, como los sistemas de informes. Por supuesto, cualquier buen desarrollador se pondrá al día,

¿Es un estereotipo injusto de Java porque ha existido durante tanto tiempo (se ha asociado injustamente con sus tecnologías más antiguas y no recibe reconocimiento por sus capacidades "modernas")? Java no es realmente tan viejo y, para ser justos, ha mejorado mucho. Fue la plataforma interesante y relevante hace unos 10 años. Pero desde entonces, ha habido nuevas plataformas con nuevos problemas en mente, como Ruby on Rails. El sector central de Java ha sido principalmente el mundo corporativo, con diferentes problemas, por lo que las personas que buscan nuevos proyectos fuera de ese país han estado buscando diferentes herramientas. Además, la principal ventaja del diseño de Java, al ser multiplataforma, no es tan relevante hoy como lo era antes.

¿El estereotipo negativo de los desarrolladores de Java es demasiado fuerte? (Java ya no es "genial") Eso también tiene algo de verdad. Java sigue siendo el lenguaje para aprender "a conseguir un trabajo". Entonces, si no te importa, pero solo quieres aprender algo para ganar dinero, terminarás aprendiendo un poco de Java y no volverás a preocuparte por mejorar. Nuevamente, se trata mucho de percepción y visibilidad. Hay toneladas de grandes desarrolladores de Java que están codificando sin compartir sus conocimientos, mientras que hay muchos desarrolladores de PHP, tal vez no tan buenos, que están escribiendo blogs y colaborando en código abierto. Eso lleva a pensar que los desarrolladores de PHP son mejores que los de Java, ya que tiene ciertos comentarios sobre ellos.

¿Las aplicaciones escritas en otros idiomas son realmente más rápidas de construir, más fáciles de mantener y funcionan mejor? Yo diría que son más rápidos de construir. Los principios de lenguajes como PHP, Python o Ruby los hacen bastante buenos para generar software que puede cambiar constantemente. Por ejemplo, la escritura dinámica facilita el cambio de una interfaz. En Java, tener una interfaz bien definida es importante, lo que lleva a interfaces más estables (y difíciles de cambiar). Esto es muy importante en una nueva startup, cuyo principal problema es obtener un producto antes de que se quede sin dinero. Sobre el rendimiento, es muy fácil entender mal las necesidades e intentar usar trucos de magia para lograr el rendimiento requerido, como "Java es más rápido que Ruby. Period" o "MongoDB es escala web".

¿Java solo lo utilizan las grandes empresas que son demasiado lentas para adaptarse a un nuevo lenguaje? Definitivamente, tener un equipo existente de desarrolladores de Java en la compañía, hace que sea más fácil seguir usando el mismo lenguaje para nuevos proyectos. Esto se percibe como "la apuesta segura", especialmente si el núcleo de la empresa no es la tecnología. Pero, de todos modos, Java NO se usa SOLO en grandes empresas, todavía hay muchas startups que usan Java para cosas geniales (por ejemplo, FightMyMonster o Swrve usa Java ampliamente), pero diría que la tendencia general en el inicio La escena es usar otros idiomas. Esa también es una forma de atraer a la gente, ya que la mayoría de las personas será más emocionante trabajar con Ruby, Python o PHP, percibido como más "amigable" y "divertido".

Khelben
fuente
5

Esto es cierto, pero no por Java y su ecosistema. Es a causa de las personas que, cuando usan Java, tienden a crear grandes problemas y abominaciones pesadas.

Hay suficientes marcos (spring-mvc, grails, play, etc.) que le permiten construir cosas rápidamente. El hecho de que las personas diseñen en exceso sus sistemas es un problema que viene con el mayor conocimiento que las personas obtienen cuando trabajan con el ecosistema de Java: usted sabe muchas más cosas y las tiene disponibles (hay herramientas para todo) y "todo parece una uña".

Si eres "hacky", puedes hacer más o menos lo mismo con Java que con otros lenguajes, y aquí hay un estudio que indica que:

Estudio de 49 programadores: el sistema de tipo estático no tuvo efecto en el tiempo de desarrollo ... http://www.cs.washington.edu/education/courses/cse590n/10au/hanenberg-oopsla2010.pdf

Bozho
fuente
3

Para agregar un poco a lo que ya se ha dicho, creo que mucho tiene que ver con la rapidez con la que puede pasar de la nada (literalmente) a una aplicación web funcional.

Si todo lo que tiene hoy es una idea, pasar de donde está ahora a escribir su aplicación web es casi tan fácil como caerse, ya sea que elija un proveedor de alojamiento o su propia infraestructura (como una imagen EC2). Elegir Java, en mi experiencia, suele ser más trabajo y, a menudo, también cuesta más.

Además, si utiliza Linux y PHP / Python / Ruby, las herramientas y la plataforma son complementarias y están diseñadas para apoyarse mutuamente. Con Java, a veces parece que los dos mundos (SO y Java) a veces no parecen funcionar en armonía entre sí.

Matt Ryan
fuente
La curva de aprendizaje es absolutamente vertical. Pasarás las primeras SEMANAS solo para descubrir cuáles son las siglas, cómo se relacionan los estándares con sus implementaciones, cómo está todo en capas, etc. Luego, en las próximas semanas, descubrir qué estofado de bibliotecas y marcos usar. Luego, las próximas semanas reportando errores en ellos ...
Craig Ringer
3

¿Quién dice que no lo es?

Spring MVC + Spring Data JPA o Mongo + Thymeleaf para crear plantillas + coffee-maven-plugin para Coffee to JS transpiling y listo.

Martin Spa
fuente
Estoy totalmente de acuerdo contigo +1
Arshad Ali
3

Muchos podrían asociar el desarrollo de aplicaciones web y Java con los horrores de J2EE que, junto con los monstruosos servidores de aplicaciones J2EE de las grandes corporaciones azules y rojas, equivalía a semanas de trabajo antes de que el "Hello World" básico estuviera en línea.

Es cierto que las especificaciones e implementaciones recientes de JEE son más livianas, pero aún así pensaría tres veces antes de sugerir algo como esto para un proyecto de desarrollo rápido de ciclo corto.

Esta sigue siendo la forma basada en estándares de desarrollar aplicaciones web en Java. Las alternativas, muchas de las cuales se mencionan en otras respuestas, transmiten una imagen más confusa y confusa con demasiadas opciones para tomar.

Otros idiomas representan una única solución llave en mano en lugar de esta multitud. Esto hace que esta elección parezca más adecuada para su propósito cuando tiene que freír peces más importantes.

Asgeir S. Nilsen
fuente
Java EE 6 puede ser "ligero" (excepto JSF2), pero sigue siendo una curva de aprendizaje increíblemente enorme, una pila gigante de especificaciones complicadas y un sistema de capas inmensamente complicado. Ligero tal vez, pero seguro no es simple.
Craig Ringer
2

Creo que se usa mucho más de lo que piensas: el uso está justo debajo de la línea de flotación. Hay muchos, muchos envoltorios de rubí en rieles alrededor de servicios gruesos y elegantes de Java. Especialmente cuando comienzas a lidiar con cualquier cosa que se acerque a Big Data. . .

Wyatt Barnett
fuente