Las tecnologías web como javascript y HTML5 cada vez son más potentes para aprovechar el hardware de los dispositivos móviles, las webs son más accesibles para todos los navegadores, al final desarrollar y desplegar para web es mucho más fácil y asequible para el desarrollador que hacer una app nativa que además conlleva aprender un lenguaje según el dispositivo móvil y pagar una licencia, terminal, etc.
Pero eso a final al usuario le importa un pepino! quiere apps que sean rápidas y fluidas, actualmente la velocidad de conexión móvil no son lo suficientemente rápidas y las tarifas de internet son bastante limitadas, aunque con el tiempo va a ir mejorando.
Compañías como Facebook y Linkedin ya se han dado cuenta de ello y han pasado sus apps HTML5 a nativas, dado las críticas de los usuarios.
También lo puedes ver a tu alrededor: ¿Cuantas personas conoces que usen twitter a través de la web móvil y cuantos una app nativa? Seguramente la mayoría la app nativa ;)
Cuando descargas una app app nativa esta contiene normalmente la lógica, la vista y gráficos con lo que para actualizarse sólo tiene que bajar los datos, en cambio una webapp/web móvil normalmente en cada petición descargas todo a la vez, si las conexiones fueran más rápidas a lo mejor no se notaría tanto la diferencia de tiempo de respuesta.
Dejo un estudio de ADSL Zone sobre conexiones 3G ya que las velocidades dependen del proveedor y de la ciudad donde te encuentres.
Por ahora el principal problema de que una webapp sea lenta respecto un app nativa es la conexión a internet móvil del usuario, también influye el como haya sido desarrollada:
1- Lo ideal sería hacer separar vista de datos, crear templates y una API, lo malo de esto es que estamos renunciando a ser indexados por google y no todo tipo de webs se lo pueden permitir.
2- Están las webs adaptadas sólo a móviles que tendríamos en un dominio distinto m.dominio.com, dominio.mobi, dominio.com/m, lo bueno es que son webs que tienen lo minimo para verse en dispositivos móviles pero lo malo de esta practica es que si no se hace bien con la etiqueta meta canonical, google te puede penalizar por contenido duplicado.
3- Por último tenemos la opción de responsive design en la que adaptamos la vista por CSS, no tenemos que cambiar las urls y no perdemos el posicionamiento SEO, pero eso supone tener varios gráficos y estilos CSS para varios tipos de pantalla haciendo que la web sea un poco más pesada.
Siendo crítico con el desarrollo web móvil, sigo pensando que el futuro es web, pero por ahora la demanda de los usuarios son las aplicaciones nativas.
Depende mucho del tipo de aplicación, si estás haciendo algo con mucha animación (tipo juego) sólo algo nativo (bien hecho) puede servir.
Cuidado con lo que se lee por ahí. Seamos sinceros la excusa de FB y de LinkedIn son malas; la app de FB apestaba en HTML y en nativo… tarda una eternidad en consultar tus notificaciones pendientes y decirte "no hay", eso no es culpa de HTML5. Y Linkedin explica/justifica muy mal sus cambios tecnológicos.
Tanto el hardware como el software en los móviles está mejorando más rápido que lo que avanzamos los programadores en aprovecharlo; eso hay que tenerlo en cuenta; dentro de 3 meses se estarán haciendo cosas en HTML5 en un móvil de 200€ que solo eran posibles un iOS nativo en un 4S. Hay que evaluar bien cual es el tipo de aplicación y dónde se va a destacar.
Tampoco hay que confundir un website con una app; si como dice Miquel es algo que va de SEO, contenidos que cambian y el user solo consume contenido, probablemente un website alcance; en ese caso la app aportaría comodidad en el uso para el lector. Otros casos son apps puras y duras y ni siquiera hay un website asociado o no es más que una homepage (es nuestro caso con www.gusapp.com).
Con HTML5, tratando bien el pushState, el cache de los recursos estáticos (imágenes, css) y luego con unos XHR trayendo JSON y rearmando el DOM (con cuidado que ahí está buena parte del truco de la velocidad) ya tienes una pseudo-app que no va a tener problema alguno con la velocidad de acceso y responderá realmente rápido.
App nativa SIEMPRE.
El único motivo para usar HTML5 es tratar de abarcar muchos dispositivos, pero escatimando en recursos (programadores, diseñadores, Q&A...), y en consecuencia se obtienen malos resultados, o si no malos, al menos no unos resultados tan pulidos como deberían ser.
Bajo mi punto de vista, si no hay dinero suficiente para hacer Apps nativas, lo mejor es seguir con una web "normal", y seguir ahorrando.
Sobre lo del futuro en webapps... pues yo creo que no.
En casa con conexiones de 20, 50 y 100 MB la gente sigue usando Apps nativas... es cierto que se usan más webapps que en móvil, pero en muchos casos por que no existe otra opción a la altura (Ej: Facebook, Gmail, Youtube...).
Ahora mismo con las webapps no puedes hacer ni la mitad que con apps nativas
Pero ojo, estan las aplicaciones hibridas, que puedes programarlas con tecnologias web y tener acceso al hardware y publicarlas en las stores
Es evidente que si por requisitos la aplicacion tiene que ser nativa (rendimiento, fiabilidad, integracion con interfaces nativas), no hay discusion. Pero cuando en mi caso se ha abierto el debate los puntos de discusion han sido:
1. Recursos. Das una patada y contratas desarrolladores JS razonablemente competentes
2. Releases. No tener que pasar por el filtro del app store y poder desplegar versiones a tu antojo, sin esperar una semana para corregir un bug es una ventaja enorme.
Aprovecha convenientemente los recursos del dispositivo, no solo el webkit. Además, en mi opinion el estandar HTML no se pensó para que las conexiones a internet tuvieran limite de datos. y la labor de "ahorrar" recae demasiado en el programador y demasiado poco en el protocolo, siendo un fastidio hacer webs "ligeras" que consuman poco, frente a la comodidad maxima de las apps.
Una app es codigo, lógica que corre por encima del procesador, y para la labor concreta de enviar datos (si es que esto fuera necesario), se usa la conexión a internet.
Todo dependerá de lo que necesites que haga la app o web app, si necesitas que aproveche funcionalidades del dispositivo, etc.
En este post te muestran las principales diferencias entre webapp, app nativa e, incluso, una híbrida: http://www.prosolutions.es/blog/app-la-solucion-para-tu-negocio/
Pero eso a final al usuario le importa un pepino! quiere apps que sean rápidas y fluidas, actualmente la velocidad de conexión móvil no son lo suficientemente rápidas y las tarifas de internet son bastante limitadas, aunque con el tiempo va a ir mejorando.
Compañías como Facebook y Linkedin ya se han dado cuenta de ello y han pasado sus apps HTML5 a nativas, dado las críticas de los usuarios.
También lo puedes ver a tu alrededor: ¿Cuantas personas conoces que usen twitter a través de la web móvil y cuantos una app nativa? Seguramente la mayoría la app nativa ;)
Cuando descargas una app app nativa esta contiene normalmente la lógica, la vista y gráficos con lo que para actualizarse sólo tiene que bajar los datos, en cambio una webapp/web móvil normalmente en cada petición descargas todo a la vez, si las conexiones fueran más rápidas a lo mejor no se notaría tanto la diferencia de tiempo de respuesta.
Dejo un estudio de ADSL Zone sobre conexiones 3G ya que las velocidades dependen del proveedor y de la ciudad donde te encuentres.
Por ahora el principal problema de que una webapp sea lenta respecto un app nativa es la conexión a internet móvil del usuario, también influye el como haya sido desarrollada:
1- Lo ideal sería hacer separar vista de datos, crear templates y una API, lo malo de esto es que estamos renunciando a ser indexados por google y no todo tipo de webs se lo pueden permitir.
2- Están las webs adaptadas sólo a móviles que tendríamos en un dominio distinto m.dominio.com, dominio.mobi, dominio.com/m, lo bueno es que son webs que tienen lo minimo para verse en dispositivos móviles pero lo malo de esta practica es que si no se hace bien con la etiqueta meta canonical, google te puede penalizar por contenido duplicado.
3- Por último tenemos la opción de responsive design en la que adaptamos la vista por CSS, no tenemos que cambiar las urls y no perdemos el posicionamiento SEO, pero eso supone tener varios gráficos y estilos CSS para varios tipos de pantalla haciendo que la web sea un poco más pesada.
Siendo crítico con el desarrollo web móvil, sigo pensando que el futuro es web, pero por ahora la demanda de los usuarios son las aplicaciones nativas.
09/05/2013 16:43
Cuidado con lo que se lee por ahí. Seamos sinceros la excusa de FB y de LinkedIn son malas; la app de FB apestaba en HTML y en nativo… tarda una eternidad en consultar tus notificaciones pendientes y decirte "no hay", eso no es culpa de HTML5. Y Linkedin explica/justifica muy mal sus cambios tecnológicos.
Tanto el hardware como el software en los móviles está mejorando más rápido que lo que avanzamos los programadores en aprovecharlo; eso hay que tenerlo en cuenta; dentro de 3 meses se estarán haciendo cosas en HTML5 en un móvil de 200€ que solo eran posibles un iOS nativo en un 4S. Hay que evaluar bien cual es el tipo de aplicación y dónde se va a destacar.
Tampoco hay que confundir un website con una app; si como dice Miquel es algo que va de SEO, contenidos que cambian y el user solo consume contenido, probablemente un website alcance; en ese caso la app aportaría comodidad en el uso para el lector. Otros casos son apps puras y duras y ni siquiera hay un website asociado o no es más que una homepage (es nuestro caso con www.gusapp.com).
Con HTML5, tratando bien el pushState, el cache de los recursos estáticos (imágenes, css) y luego con unos XHR trayendo JSON y rearmando el DOM (con cuidado que ahí está buena parte del truco de la velocidad) ya tienes una pseudo-app que no va a tener problema alguno con la velocidad de acceso y responderá realmente rápido.
09/05/2013 15:19
El único motivo para usar HTML5 es tratar de abarcar muchos dispositivos, pero escatimando en recursos (programadores, diseñadores, Q&A...), y en consecuencia se obtienen malos resultados, o si no malos, al menos no unos resultados tan pulidos como deberían ser.
Bajo mi punto de vista, si no hay dinero suficiente para hacer Apps nativas, lo mejor es seguir con una web "normal", y seguir ahorrando.
Sobre lo del futuro en webapps... pues yo creo que no.
En casa con conexiones de 20, 50 y 100 MB la gente sigue usando Apps nativas... es cierto que se usan más webapps que en móvil, pero en muchos casos por que no existe otra opción a la altura (Ej: Facebook, Gmail, Youtube...).
09/05/2013 18:33
Pero ojo, estan las aplicaciones hibridas, que puedes programarlas con tecnologias web y tener acceso al hardware y publicarlas en las stores
10/05/2013 14:59
1. Recursos. Das una patada y contratas desarrolladores JS razonablemente competentes
2. Releases. No tener que pasar por el filtro del app store y poder desplegar versiones a tu antojo, sin esperar una semana para corregir un bug es una ventaja enorme.
14/05/2013 12:16
Aprovecha convenientemente los recursos del dispositivo, no solo el webkit. Además, en mi opinion el estandar HTML no se pensó para que las conexiones a internet tuvieran limite de datos. y la labor de "ahorrar" recae demasiado en el programador y demasiado poco en el protocolo, siendo un fastidio hacer webs "ligeras" que consuman poco, frente a la comodidad maxima de las apps.
Una app es codigo, lógica que corre por encima del procesador, y para la labor concreta de enviar datos (si es que esto fuera necesario), se usa la conexión a internet.
30/01/2014 11:44
En este post te muestran las principales diferencias entre webapp, app nativa e, incluso, una híbrida: http://www.prosolutions.es/blog/app-la-solucion-para-tu-negocio/
http://www.appsolutions.es