QML vs HTML5
Ayer, en el hangout de Introducción a QML, nuestro buen amigo Cristian Vasquez dejó caer una pregunta muy interesante al respecto de QML vs HTML5.
Hoy, recuperando la pregunta de ayer charlamos nuevamente un rato al respecto.
Con el permiso de Cristian recupero esta conversación para que veáis nuestro enfoque y el de Cristian en detalle:
- Cristian Vasquez: Hablando de movilidad, en cuanto a aplicaciones v7 tu opinión para llevar apps v7 al móvil es esperar un vClient Android Maduro + QML para el interface?
- Jorge: Si, sin dudas. HTML5 no es la solución.
- Jorge: Te pongo un ejemplo claro, Galaxy S4 con pantalla FullHD (retina display) imagínate desarrollando una app que se vea bien en este cacharro y en otro de resolución 800×400. En html5 todo son ñapas para dar solución a esta cuestión.
- Jorge: Otro ejemplo, el tema de las webs responsive y lo de las imágenes en x2 para los retina display, otra ñapa. HTML5+CSS3 es una castaña enfocado de esta forma.
- Cristian Vasquez: Pues sin haber pensado mucho el tema a día de hoy si me toca abordar la movilidad para una app v7 me voy por algún framework tipo Titanium o Triggger.io y lo conecto al aplicación con alguna API ya sea vModApache y porque no hasta Cirrus.js (Al fin de cuentas para eso lo hice jejeje)
- Jorge: Es una opción directa y sencilla, seguramente tardes menos en la implementación y el resultado sea bueno.
- Jorge: Pero siendo sincero yo no lo haría. Es pan para hoy y hambre para mañana.
- Cristian Vasquez: Ahhh y claro también esta la opción que comentas de QML sin Velneo que ya tomando forma con los ports a Android y iOS, pero a lo que me refiero es a depender en aplicaciones Mobile de los desarrollos de Velneo y las limitantes de acceso las funcionalidad del dispositivo que seguro va a tener el vClient
- Jorge: No estoy de acuerdo, QML no tiene limitaciones respecto al acceso al dispositivo, poco a poco se cubren todas las áreas y Velneo no quita nada excepto que tienes que pasar siempre por complementos QML.
- Jorge: QML 2 es muy funcional y responde a problemas que HTML5 nunca podrá cubrir con garantías, yo no tengo ninguna duda. Velneo con QML 2 estará a la altura de los mejores y con un potencial muy fuerte.
- Jorge: Los frameworks basados en HTML5 son pesados e insuficientes. Las empresas grandes, actualmente asumen el sobrecoste de tener que desarrollar para varias plataformas, pero este enfoque no puede ser eternamente ya que pronto aparecerán otras nuevas. No solo de iOS y Android vive el hombre.
- Jorge: Optar a QML sin Velneo es una buena opción pero pierdes algunas de las virtudes en el mundo conectado.
- Cristian Vasquez: Sip me gusta tu razonamiento, habrá que esperar a ver con que sale velneo cuando terminen la migración a Qt5
Bueno… creo que fue interesante la conversación de esta mañana… ¿Y tu que opinas?
Interesante conversación, sin duda.
Solo quería comentar una duda que me ha generado.
Cuando Cristian habla de usar Titanium(y yo añado código nativo de las paltaformas Java, Objetive-C, etc..) y servir los datos con Cirrus, que es lo que y hago, aunque un Cirrus ya muy muy personalizado…dices que es «Pan para hoy y hambre para mañana».
Sinceramente, Jorge, no se que es lo que quieres decir.
Es decir, si tienes skill de Velneo, de Javascript, y del código nativo de plataformas nativas (Java, Objetive-C)…dónde está el problema?
Desde luego, si algún día velneo puede tener clientes estables en las paltaformas móviles, esa será una opción.
Pero incluso si eso llega, este otro planteamiento es igualmente válido.
De hecho, este segundo planteamiento sin duda es más potente.
Porque no creo que a nivel de cliente móvil, nunca QT con Velneo van a ir tan rápido como desarrollar en lenguaje nativo.
Además con lenguaje nativo en movilidad puedes abordar cualquier tipo de software con velneo detrás, no solamente software empresarial.
Es lo que yo pienso.
Espero tu respuesta a «Pan para hoy y hambre para mañana»…
Cualquier planteamiento es válido con sus ventajas e inconvenientes (para nosotros un factor fundamental es el coste).
Cuando digo «Pan para hoy y hambre para mañana» me refiero al sobrecoste que provoca el enfoque de código nativo ya que cada vez habrá más y más distintas plataformas.
@javier con respecto a tu «aunque un Cirrus ya muy muy personalizado», pues te invito a que aportes al proyecto en github con posibles modificaciones o correcciones de bugs que hayas encontrado.
Un saludo,