¿Aplicaciones web o aplicaciones

nativas?
No es la primera vez que hablamos de aplicaciones web o nativas y las ventajas
de unas sobre las otras. Actualmente, como ya hemos visto, romper la barrera entre
ambos campos es más fácil con herramientas como Titanium, de Appcelerator (el
curso que nosotros tenemos de aplicaciones móviles), PhoneGap o, en campos más
avanzados, Ionic. Estos entornos de desarrollo tienen la ventaja de que dar el paso de
un lado a otro es relativamente fácil. Relativamente porqué no debemos olvidar que
debe haber cierta habilidad de nuestra parte a la hora de programar y estructurar el
proyecto, como también vemos en el curso.

Pero entonces, si el paso de una categoría a otra es tan “sencillo”, ¿de qué sirve en la
actualidad plantearnos si tirar en una dirección u otra? La respuesta es sencilla. No
siempre tenemos los recursos físicos o económicos para hacer una app nativa, o la
sencillez del proyecto no requiere la dificultad de la segunda opción. Vamos a ver
cual es el panorama actual en esto.

Aplicaciones nativas vs aplicaciones web

Si bien es cierto que las aplicaciones nativas son más estables que las web, en las
segundas podemos encontrar ciertas ventajas que para iniciar el proyecto nos puede
venir de maravilla. Los tiempos han cambiado y en la actualidad hay muchos
recursos para hacer aplicaciones con lenguajes 100% web, como
JavaScript, HTML5 o editar estilos con CSS. De hecho, otras plataformas han
adoptado esta característica haciendo de la sintaxis algo propio. ¿Qué significa esto?

Por ejemplo, Android Studio de Google utiliza una hoja de estilos en XML para que,
de manera sencilla, podamos editar el aspecto de nuestra aplicación. Hasta la fecha,
esto lo hacíamos con “pico y pala”: con el lenguaje nativo, si queríamos hacer una
marquesina, primero debíamos declarar una caja para que seguidamente en las
propiedades designáramos el color, tamaño, etc. Pero esas propiedades sólo servían
para ése elemento, no se compartían.

Si observamos CSS, su magia es la capacidad de crear una hoja de estilos general,

para todos los elementos, y luego asignar clases más concretas para objetos
específicos. En vista de que esto era lo más óptimo, y el crecimiento del uso de los
smartphones y las tabletas, los desarrolladores decidieron que era lógico trasladar
dicha facilidad a la programación de aplicaciones, y lo cierto es que fue lo más
sensato. Esto dio pie al nacimiento de las aplicaciones web, programas que, si bien
no aprovechan del todo los recursos físicos de nuestro teléfono, eran capaces de
generar una página que se visualizaba correctamente en todas las plataformas.
Podías visitarla desde el PC o desde el teléfono que siempre se pintaba todo en
pantalla como tocaba (recordad que en el PC la pantalla es horizontal mientras que
en el teléfono, por lo general, vertical). Pero seguimos hablando del pasado.

¿Cuál es la realidad actual? ¿Alguna vez habéis entrado en Google maps y os ha

pedido que compartáis vuestra ubicación? Las aplicaciones web cada vez son más
capaces de comunicarse con vuestro dispositivo y esto está creando una evolución en
la que, poco a poco, la barrera entre las apps web y nativas se cierra. Aquí es donde
entra el papel de los entornos híbridos. Para que me entendáis, cojamos la
plataforma de Apple como ejemplo, iOS. Necesitamos su paquete de desarrollo,
Xcode, para poder hacer apps, y si queremos entrar en el mundo nativo, usaremos
ObjectiveC o Swift. Si no los conocéis, como todo lenguaje al principio, deberéis
pasar por una fase de aprendizaje, y os podéis preguntar “Sería maravilloso poder
hacer una app en iOS con mis conocimientos de lenguajes web...”. Y por eso nacieron
dichos entornos híbridos. Aunque al principio algo arcaicos, en la actualidad son tan
potentes como uno que se dedique únicamente a la programación nativa, y por eso
han ganado tanta popularidad.

Una vez más insisto en que nada será tan óptimo como un lenguaje nativo, pero
cuando el tiempo va a contrarreloj, se agradece mucho que con un sólo código
podamos compilar en distintas plataformas, y este es el otro punto a tener en cuenta
de todo esto.

Multicompilación

Antes he dicho que dar el paso del campo de las aplicaciones web a las nativas
es muy sencillo pero no os he dicho por qué. Esto es gracias a que disponemos de la
posibilidad de compilar en varias plataformas. “¿Por qué si mi aplicación se ve bien
en todas las plataformas debo hacerla de nuevo para añadir alguna función sólo
presente en el teléfono?” como puede pasar en el caso del acelerómetro. Sería perder
tiempo, ¿no? Es mejor coger toda la base que ya os habéis creado y definir que
cuando entres con el teléfono, te de las funciones restantes, y una vez lo tienes,
generar la aplicación en las plataformas que deseáis publicar: Android, iOS,
Windows Phone. Incluso Blackberry, el eterno olvidado en combate.

Mi conclusión a todo esto es que ya no hay un factor determinante a la hora de

decidir si hacer una aplicación nativa o una web. Debemos cogerlo como algo escalar,
empezar con lo más sencillo (web) para finalmente evolucionar a la más compleja
(nativa), ya que, gracias a esto, podemos tener listo un producto e ir mejorando poco
a poco hasta llegar a las expectativas que teníamos al inicio del proyecto. Quiero
dejar también escrito que todas estas palabras son aplicables a las aplicaciones por lo
general. Los juegos si que necesitan un tratamiento más cercano, pese a haber
motores que gozan de multicompilación. Pero, como todos sabemos, un juego ya es
una estructura mucho más compleja que una aplicación, y es algo que, sin haber
programado jamás, no debemos meternos de cabeza de buenas a primeras, mas bien
ir creciendo como desarrolladores e ir alcanzando nuestro objetivos poco a poco.

¿Conocíais todos estos aspectos? Como podéis ver, el panorama actual

de las apps web o nativas ha cambiado mucho, y desde luego tenemos
muchas posibilidades en nuestras manos a diferencia de hace 3 o 4 años
atrás.

Curso relacionado: Curso de Desarrollo de Aplicaciones Móviles