¿Cuando tienen sentido en internet clientes más pesados que el HTML?

Aunque por distintas razones sólo se puede descargar en forma de EXE de Windows, ProjectioPM esta desarrollado en Java, y es ejecutable vía Java Web Start, nuestra primera intención. En realidad, su editor (el que permite crear las preguntas, más noticias en breve), también es una aplicación Java Web Start. Tengo que reconocer que desde hace años estoy enamorado de algo tan simple y tan elegante como Java Web Start, que permite instalar y actualizar aplicaciones de escritorio a través de la red sin (demasiados) problemas.


Esto me ha hecho considerar la opción de que la interface de Projectio Office (del que ya he hablado por aquí) tenga una aplicación web mínima, pero que el grueso de la misma fuera una aplicación de escritorio.


¿Razones?.


  • Cada vez soy más vago y perezoso como para pelearme con el HTML.

  • Tengo la sensación de que aún hay muchos usuarios no informáticos de que siguen sin tener claro la diferencia entre aplicación web y aplicación de escritorio. Y que incluso no les gusta la parte web.

  • Incluso para los informáticos… ¿abrir una página web?. ¿Y por qué no integrarlo en el IDE (opcionalmente, claro)?.



Inconvenientes también los hay, aunque de momento me los callo, simplemente me gustaría recoger el feedback sobre esta idea. ¿Comentarios?.

4 Respuestas a “¿Cuando tienen sentido en internet clientes más pesados que el HTML?”


  1. 1 anonimo

    Supongo que es lo que te diran la mayoria, para mi la principal y más importante pega: instalar la JRE.
    Es lo que más me echa atras cuando me planteo hacer una aplicación asi.
    Explicale al usuario que se baje e instale el JRE… Luego los problemas de versiones, etc…
    MS como domina su escritorio es capaz de imponer su runtime aunque el usuario no quira….

  2. 2 Al

    Hola anónimo. Me imaginaba esa respuesta. Demasiado tópica incluso. Espero no sonar demasiado borde, no es mi intención.

    Curiosamente el del JRE… me parece el “menor” de los problemas. Primero porque cuesta encontrar un sistema windows sin “nada de java” (otra cosa es el JDK), y segundo porque la versión del jre se puede definir en el jnlp y actualizarse de forma automática. Tampoco creo que en un entorno empresarial que necesite este tipo de herramientas sea algo demasiado difícil si llegado el caso no existiera el JRE en la máquina. Sin querer faltar, el usuario es tan borreguil que si en la página en el que le pones el link de java web start le dices que se lo tiene que instalar, lo hará sin preguntar.

    Como he dicho, projectio pm soporta JWS, y en realidad las betas las hemos distribuido de esa forma, y para mi sorpresa, en la encuesta de evaluación, la facilidad de instalación y actualización era un punto muy valorado.

    Mis dudas van más desde el punto de vista operativo que desde el de instalación.

  3. 3 Luis

    Pienso que lo que decís en tu artículo es cierto. Nososotros estamos en un proyecto que requiere la posibilidad de interconectarse varias sucursales a una casa central. Hicimos un análisis de las posibilidades que teníamos y terminamos eligiendo java web start debido a que:
    - permite una mejor interacción con el usuario (se van a cargar una gran catidad de datos)
    - se puede redistribuir rápidamente una nueva versión (si hay un bug se distribuye el nuevo jar con el bug corregido)
    - se disminuyen los tiempos de desarrollo al haber una mayor cantidad de IDE con herramientas para la creación de formularios y controles.
    - Los archivos jar no son tan grandes permitiendo una distribución casi tan rápida como con algunas aplicaciones ajax.

    Este último punto me parece importante, ya que he visto una gran cantidad de aplicaciones ajax que requieren una gran cantidad de tiempo en la primera descarga.
    Si quiero poner una desventaja adicional a las aplicaciones ajax es que a pesar de la gran cantidad de frameworks que hay todavía los agentes de usuario o browsers no son 100% compatibles con los estándares de la W3C. Por tanto si uno quiere usar una característica más avanzada tiene que anlizar cómo funciona en IE, Firefox, Opera que son los más usados.
    Aunque les resulte extraño tengo más experiencia trabjando con PHP y javascript que con JAVA. Sin embargo debido a la seguridad que requiere la aplicación elegimos J2EE y clientes swing debido a que nos simplifica los tiempos y es una tecnología mucho más madura y robusta que ajax.

  4. 4 batch4j

    Nosotros tenemos un proyecto que se descarga el JRE, un DESASTRE.

    Tenemos numerosos usuarios con lineas de 64 Kb. Hay numerosas aplicaciones que imponen su maquina virtual y sin la cual no pueden trabajar con lo que te obliga a mantener versiones con parches para casi todas las MVJ disponibles.

    Tampoco tengo claro que lo mejor para un cliente sea trabajar en un sistema “no nativo”.

    Sigo pensando que en Java falta un verdadero sistema de aplicaciones de desktop, ya que se deja al desarrollador mucha libertad que en J2EE, por ejemplo, la hace el servidor de aplicaciones, quiza si se diseñase un servidor de escritorio que al igual que pasa con java en el servidor nos diese parte del trabajo hecho, las aplicaciones en swing seria mas robustas, llevo usando swing desde la version 0.2.0 y aunque ha mejorado mucho todavia esta lejos de dar un buen rendimiento.
    Supongo que una aplicacion de escritorio sencilla sin necesidades propias de diseñadores graficos es mas o menos facil de implementar pero normalmente el diseño grafico impone sus leyes.

Añade un Comentario





Close
E-mail It