¿Cuáles son sus sentimientos en JavaFX?

ria (10)

Actualmente trabajo mucho en ActionScript 3.0, también me gusta programar en Java. ¿Es JavaFX perfecto para mí? ¿Cuál es la sensación general en JavaFX, se convertirá en una casa de máquinas, o tomará el mismo camino que los Applets de Java? ¿Podrían los diseñadores con los que trabajo sentirse cómodos con JavaFX en la misma medida en que se sienten cómodos con ActionScript y JavaScript?

A menos que esté trabajando en una aplicación interna, me mantendría alejado de ella. Los usuarios generalmente no quieren tener que lidiar con otro programa que logre lo mismo que Flash. No creo que su base de instalación sea lo suficientemente grande como para que sea conveniente para los usuarios finales.

A pesar de que parece bastante poderoso en términos de capacidades, soy un poco blah sobre JavaFX debido a su estructura e implementación. Parece un intento poco entusiasta de entrar en el mercado de Flash / Silverlight. Demasiado scripty

Discutiría a favor de ir a la ruta de Silverlight 2, pero soy principalmente un desarrollador de C #, así que estoy un poco predispuesto allí. Si no te gusta esa ruta por el motivo que sea pero aún deseas un UX más completo para tus usuarios, te sugiero Flex; parece mucho mejor organizado que JavaFX para mí.

Solo mis dos centavos sobre el tema.

Si conoces Java pero quieres hacer las cosas que creías que solo eran factibles en Flash, entonces sí, JavaFX sería bueno para ti.

Sin duda, será mucho más fácil fusionar su conocimiento de Java con el diseño.

Y creo que las herramientas solo mejorarán, lo que simplificará su uso.

Dejé mi último trabajo para pasar de Java a desarrollo .NET.

Hubo una serie de razones para realizar el cambio, pero la razón más importante fue que estaba harto y cansado de intentar crear un software UI de primera clase con Java & Swing. Han pasado seis años y estoy tan feliz de haber seguido. No veo ninguna razón para creer que Sun finalmente entienda el desarrollo de la interfaz de usuario con JavaFX.

Estoy convencido de que Microsoft finalmente está en el proceso de proporcionarnos una plataforma para construir aplicaciones interactivas ricas en el navegador. Lo digo después de haber construido un software disponible comercialmente que fue entregado como un complemento de Netscape hace 13 años, seguido por controles ActiveX y applets de Java, y ver que todas estas plataformas no se vuelven omnipresentes en la empresa por una razón u otra.

Me doy cuenta de que Silverlight 2 todavía carece de profundidad y madurez, pero Microsoft me ha mostrado suficiente compromiso en este punto que creo que será la plataforma de RIA dominante en unos pocos años, al menos para proyectos que requieren una programación "real" idioma. Estoy seguro de que Flash et al. no va a desaparecer pronto, pero Flash no es apropiado para los tipos de software que crea mi empresa.

La guinda del pastel es el hecho de que aún podré usar Visual Studio, C # y un gran porcentaje de mi base de código actual (el motor central que está completamente separado de la interfaz de usuario). Por supuesto, si vienes de ActionScript, esto no te ayudaría.

Un punto más importante es el hecho de que Silverlight y WPF comparten mucho en común. Nuestro plan es compartir una gran cantidad de implementación entre las versiones de Silverlight y WPF de nuestro software. Es solo una cuestión de tiempo antes de que WPF sea el estándar para las aplicaciones de Windows. No sé si se trata de un par de años o diez años, pero claramente sucederá con el tiempo. Ser capaz de apuntar a los navegadores / SO más populares con Silverlight y Windows desde la misma base de código es una gran ventaja de la OMI.

Si conoces Java, mudarse a C # es pan comido. Y a menos que esté utilizando uno de los IDE de Java agradables (no gratuitos), incluso las versiones gratuitas de Visual Studio serán una mejora sobre lo que está acostumbrado. El obstáculo será aprender la nueva forma de hacer las cosas con XAML, pero es algo muy bueno para que realmente lo disfrutes.

Un "meh" rotundo.

Cuando lo miré hace un año, tenían una herramienta de conversión SVG a JavaFx de una sola vía. Genial, entonces puedes crear tu contenido visual una vez, marcarlo con mucho comportamiento, y luego la próxima vez que quieras que se vea bien, ¿entonces qué?

Si echas un vistazo a este tutorial , puedes ver a qué me refiero. Estamos dibujando cosas arrastrando las formas de una paleta en el código fuente. OMGWTF. No lo estoy mostrando a mi departamento de gráficos.

Espero estar equivocado sobre JavaFx, pero no creo que lo entiendan. Por favor, ¿alguien de Sun no nos dará una capa de presentación que no tenga sus tentáculos inextricablemente entrelazados con el código?

He pasado el fin de semana ''jugando con eso. No veo nada útil en eso. Es una iteración de swing / awt. Supongo que será bueno para los dispositivos móviles, pero más allá de eso no es nada útil.

Idealmente, me gustaría utilizar el flash pero me resulta doloroso integrarlo con un backend de cualquier tipo.

Solo quería agregar mi $ .02 ... He estado trabajando en JavaFX durante los últimos 4 días en mi primer pequeño proyecto paralelo. Como antecedentes, he estado programando profesionalmente durante aproximadamente 9 años, comenzando con C, y he estado haciendo Java y C # /. NET durante los últimos 6 años.

IMO, JavaFX es mucho más frustrante de lo que debería ser. Aquí hay algunas quejas:

La sintaxis es rara a veces. Podría ser más como Java, desde su Java FX. Pero la sintaxis no es una transición fácil desde Java.
El orden de los elementos en un archivo .fx realmente importa, lo que significa que se encuentra con estúpidos errores de referencia circulares y "oh, no puede usar esta variable aún porque no se ha inicializado", problemas que el compilador debería manejar con facilidad, pero no lo hace
Las cosas aleatorias simplemente no funcionan. Las acciones / eventos en los controles Swing no siempre funcionan, por ejemplo, no parece que se llame a SwingSliderBar onKeyPressed / released.
El manejo de errores es simplemente malo . Si se produce una excepción que no se maneja, no hay una manera real de contar otra cosa que no sea la consola de Java, y los elementos de la IU comienzan a reaccionar de forma divertida. Por ejemplo, crea un cuadro SwingText y vincula su valor a una variable. Ahora, tratar de editar el valor en el cuadro de texto arrojará una excepción porque no puede editar la variable enlazada. Sin embargo, en la interfaz de usuario, el cuadro de texto comienza a suceder cosas divertidas. algunos personajes solo 1/2 pintura, a veces retroceso no hace nada, a veces elimina un carácter, a veces puede presionar 2 teclas en el teclado como "1" y "2" y el cuadro de texto terminará con "21" ingresado en él en lugar de "12", etc.

Aunque mi problema absoluto n. ° 1 con el desarrollo de JavaFX ahora mismo es Netbeans . Es patéticamente malo en JFX. No se puede depurar, los errores se muestran incorrectamente en el IDE (¡he tenido que marcar comentarios como errores!), La intellisencia solo funciona como el 40% del tiempo, las plantillas de código del evento preprogramadas en el IDE para controles de arrastrar y soltar aren '' t correcto. Olvidé cuál, pero uno de ellos arroja un "&" al final del código insertado que nunca es válido y siempre tiene que ser borrado manualmente ... es simplemente horrible , y es inaceptable para una compañía como Sun.

Otra queja es la documentación general. Es solo deficiente. De alguna manera, la API de JavaFX ni siquiera aparece como el resultado de búsqueda número 1 en google cuando se buscan métodos / clases. Toneladas de "ejemplos" en la web ya no funcionan, ya que cada versión tiene importantes cambios de refactorización, y clases eliminadas o renombradas.

En general, le doy a JFX un 4 de 10. Me gusta, pero JFX 1.1 simplemente no funciona ... definitivamente no es lo que yo consideraría "listo para producción".

Bueno, la sintaxis de ActionScript y JavaFX parece compartir muchas similitudes, por lo que tal vez sea "Sí".

Estoy aprendiendo el script JavaFX en este momento y realmente me gusta. Pero lo que no me gusta, y tal vez es su mayor inconveniente, es su documentación horrible, que a menudo no está actualizada o incompleta.

He estado desarrollando aplicaciones Flash con Flex durante aproximadamente 2 años y decidí probar JavaFX porque constantemente obtenemos quejas de los usuarios de que no pueden usar las aplicaciones de sus IPhones (y me encanta Java).

Ese es un golpe para Flash (sin soporte móvil amplio).

Para ser honesto, quedé bastante impresionado con JavaFX (de una manera muy mala).

La documentación está incompleta.
El guion es simplemente horrible; es este extraño híbrido entre JSON y R con la sensación de un Java-deja-vu.
Pasé los primeros 3 días pintando polígonos y haciendo gradientes con CODE ... WTF !!
Traté de convencer a mi departamento de gráficos para que lo probara y simplemente no se dan cuenta de cómo se supone que debe funcionar el conjunto de producción, siguen quejándose de que Flex Skinning es mucho más fácil y se ve mejor al final (lo cual es absolutamente cierto).
El "soporte CSS" es simplemente una mala broma.
Por lo general, se siente como un intento mediocre de ofrecer una opción para el frontend de RIA.

Solo puedo pensar en un par de cosas buenas al respecto:

Se puede ejecutar desde un iPhone / iPad y casi todos los dispositivos móviles.
Usted tiene acceso a todo el código Java que desee, lo cual es excelente teniendo en cuenta las limitaciones que tiene ActionScript (sin sobrecarga, sin constructores privados, etc.). Esto es algo grandioso para nosotros los programadores, pero recordemos por un segundo que esta es una tecnología de frontend / presentación ... eso significa que los usuarios tendrán que ver realmente la cosa, por lo tanto, si no se ve bien y tienen un aspecto genial animaciones / efectos que no va a cavar.
El script es mucho menos detallado que los archivos MXML (con el costo de ser ininteligible).
Hablando de rendimiento ... Flash Player es esta gran mancha verde que sigue creciendo y creciendo hasta que no queda memoria RAM comparada con cómo se ejecuta JavaFX (JVM dice: desafortunadamente, esto no tiene nada que ver con la API de JavaFX real simplemente es que la JVM ... ¡Bueno, eso es genial!).
Tiene esta característica genial en la que puedes arrastrar el applet fuera del navegador web.

Al final, estoy contento de tener una opción para ir a dispositivos móviles, pero esta es una forma de años de madurez que Flex / Flash ha logrado con respecto a las aplicaciones de RIA. El futuro de Flex / Flash como una tecnología web de amplia distribución no está claro (puede que solo se use para banners y juegos en línea molestos), nadie quiere depender de una tecnología cercana como Flash Player, por eso el conjunto La comunidad web se esfuerza por sacar Flash de la escena (soporte de video HTML5, No Flash Player para dispositivos Apple, etc.). Así que un intento de tener uno abierto siempre es bienvenido, es solo que JavaFX se siente como esta versión incompleta de una versión beta apresurada de algo que Sun se sintió obligado a encontrar en un fin de semana durante una mala resaca.

Espero que esto sea útil para alguien (y ofensivo para alguien en Sun / Oracle = p).

He estado trabajando en una aplicación JavaFX desde hace varios meses. Personalmente, amo el lenguaje. Me parecieron haber tomado algunas decisiones muy inteligentes al elegir la sintaxis y el lenguaje (puedo aburrirte con una lista si lo deseas). He estado programando en él durante unos meses y parece un lenguaje muy eficiente e incluso divertido para programar.

Creo que su mejor uso en este momento es para aplicaciones de escritorio y / o aplicaciones implementadas a través de webstart. En el escritorio, tiene un amplio conjunto de características y aún puede hacer uso de las otras funciones de Swing y el resto de Java. Por lo que he escuchado, los applets aún son lentos en algunos sistemas y, sin el soporte de Android, las capacidades móviles no son características. El soporte de applet / móvil / TV / web me parece más una ventaja para los desarrolladores de escritorio que las características clave que te permitirán utilizar la tecnología.

Entonces todo depende de lo que planee usar. Si está creando aplicaciones de escritorio que desea ejecutar en la máquina virtual de Java que pueden hacer uso de controles multimedia fáciles de usar y de interfaz de usuario rica, entonces creo que hay buenas razones para mirar el idioma. WebStart ha mejorado bastante y es una buena herramienta de implementación. Si está buscando construir aplicaciones web, entonces podría ser interesante, pero por ahora diría que HTML5 / ajax son más relevantes (es posible que desee ver a ZK en este caso). Sin embargo, incluso con HTML5, ajax tiene sus limitaciones, y si te encuentras con ellas, entonces JavaFX puede ofrecerte opciones. Para las plataformas móviles, no será relevante hasta que haya compatibilidad estable con Android; en ese caso, solo me quedaré con la plataforma Android por ahora.