LATEST ARTICLES

December 10th 2019

¿Qué es eso de la programación defensiva?

Número de lecturas: 126
{lang: 'es-419'}

Últimamente me he topado en varios sitios con el concepto “Defensive programming” o programación a la defensiva para los hispanohablantes y como parece que es un concepto que se está poniendo poco a poco de moda he decidido preparar un artículo hablando acerca de él. Espero que os resulte interesante y que os proporcione otra visión sobre la forma en que escribís vuestro código. Es probable que muchos de los conceptos de los que aquí hablo ya os resulten familiares; la “programación defensiva” se basa en ellos para conseguir que el código sea resiliente a los fallos que se produzcan en el futuro.

Así que sin entretenernos más vamos a adentrarnos en este concepto tan interesante de la “defensive programming”.


Programación defensiva. El concepto

La programación defensiva podemos entenderla como una forma de programar en la que el desarrollador anticipa los problemas que pueden surgir en el código. Gracias a esta previsión de la que nos dota esta metodología es posible prevenir futuros fallos y, lo que es más importante, conseguir que si finalmente acaban apareciendo, el programa no falle estrepitosamente.

Es decir, la programación defensiva no se basa en la utopía de escribir código que nunca falle, sino en la premisa de que cuando nuestras aplicaciones fallen (recuerda, nadie es infalible) el error se produzca dentro de un entorno lo más controlado posible. Si la programación defensiva fuera un dicho popular estaríamos hablando de

Caer con estilo

Para lograrlo, el código que escribamos deberá:

  • Fallar de forma segura, es decir tras el fallo no deberían quedar ficheros abiertos o bloqueados o transacciones contra la base de datos a medio terminar.
  • Fallar de forma clara, proporcionando siempre un código de error y un mensaje que explique lo que originó el fallo de modo que detectar el fallo y solucionarlo sea mucho más sencillo. Además, proporcionar una pila de llamadas e invocaciones siempre es una gran idea.

Por qué necesitamos la “programación defensiva”

Como comentaba líneas antes, cuando escribimos código nadie es infalible y, de hecho, por mucho cuidado que pongamos siempre habrá casos extremos (los conocidos casos frontera) que no hayamos tenido en cuenta y que provocarán que nuestra aplicación falle en el futuro.

Por tanto, la programación defensiva tiene algo de pragmatismo, es decir, de ayudar a tu yo del futuro a enfrentarse a problemas que hoy no estás viendo.

Este concepto de pragmatismo es desarrollado en el libro Pragmatic Programmer de Andrew Hunt y viene a proponernos que siempre:

  • Protejamos nuestro código de nuestros propios fallos y de todos aquellos que otros desarrolladores puedan provocar.
  • Validemos con tests el funcionamiento de nuestras aplicaciones.
  • Y puesto que es imposible contemplar en los tests todos los casos posibles que pueden suceder, controlemos el flujo de las excepciones y los códigos de error de cara a lograr esa “caída con estilo” de la que os hablaba antes.

Realmente esta idea de “programación defensiva” puede sonarnos a obsesión pero con los años aprendes a que no hay mejor forma de irse a dormir tras subir a producción que saber que el código está protegido contra cualquier fallo que suceda.

Photo by Ben Hershey on Unsplash

Algunas pautas para seguir la programación defensiva

Ahora que ya tenemos claro lo que es la programación defensiva quiero dejaros unas pautas que os pueden ayudar a sentiros más seguros con el código que escribáis y a seguir esta idea de “defensive programming”.

Una de las metodologías que podéis comenzar a emplear desde ya en vuestros desarrollos es TDD.

Su idea subyace en escribir siempre primero los casos de prueba unitarios para a continuación desarrollar la funcionalidad y ver si cumple las pruebas planteadas.

Por tanto, siempre tendremos una base sólida de pruebas automáticas que nos permitirán asegurarnos de que “nada se ha roto” a medida que el tamaño de nuestra aplicación crezca o refactoricemos la funcionalidad de los componentes. Si queréis, podéis pensar TDD como una metodología en la que cada componente crece en dos direcciones: funcionalidad y casos de prueba, de modo que los segundos aseguren el correcto funcionamiento del componente.

Además seguir una buena metodología TDD también nos ayudará a conseguir diseños poco acoplados pues nos obligaremos a aislar cada una de las funcionalidades cuando escribamos los casos de prueba. Esto nos permitirá tener un control mucho más detallado de cada funcionalidad y, lo que es más importante, asegurarnos de que obtenemos los resultados que esperábamos en cada llamada.

Independientemente de que sigáis la metodología TDD, es importante que revisemos siempre los casos frontera de la funcionalidad que estéis escribiendo.

Por casos frontera entendemos aquellos casos que no están dentro de la funcionalidad normal del componente sino a los que puede llegarse en determinadas ocasiones.

Por ejemplo si una función espera recibir un número natural, ¿qué sucede si le enviamos un número negativo? O si estamos trabajando con campos de texto, ¿se guardan correctamente los emojis en base de datos para us posterior visualización?

Son este tipo de condiciones o casos a las que deberemos prestar más atención cuando realicemos las pruebas ya que es aquí donde suceden la mayoría de los fallos. Por tanto, no os limitéis a preparar pruebas con condiciones esperadas (algo en lo que es muy fácil caer si no somos lo suficientemente críticos con nuestro código) sino pensad en los casos rebuscados e incluso “malintencionados” pues es ahí donde podremos detectar los puntos débiles de nuestra aplicación.

Otra forma de plantearte la programación defensiva es ponerte siempre en el peor caso. De este modo siempre estarás prevenido o alerta sobre casos que a simple vista no pueden parecer tan evidentes.

Por ejemplo, algo que me sucedió recientemente por haberme “confiado”. En el procesamiento de una llamada POST de una API todo funcionaba de forma perfecto (y pasaba todos los tests que se me habían ocurrido para esa funcionalidad) pero sin embargo, el caso más absurdo de todos provocaba fallo: un cuerpo de petición vacío.

Es por eso por lo que la programación defensiva nos insta a ir siempre con todos nuestros sentidos activos de modo que podamos anticiparnos a los futuros fallos de nuestra aplicación. Realmente, más que una metodología de trabajo como puede ser el ya mencionada TDD es una actitud ante la forma en que escribimos nuestro código con el objetivo de añadirle un extra de seguridad; es por eso que me ha resultado tan interesante: basta con tan sólo cambiar el chip para aplicarla, no se necesita ningún conocimiento especial.

Otra de las forma en las que podemos asumir esta idea de la programación defensiva es obligarnos a escribir código limpio y optimizado, de modo que su mantenimiento y la corrección de fallos sea mucho más sencillo.

Algunos consejos que nos pueden ayudar a escribir código limpio son:

  • Emplear patrones de diseño e intentar adoptar los principios SOLID en nuestros diseños. Los primeros nos permitirán resolver situaciones de una forma estándar (y optimizada) con la que la mayoría de desarrolladores ya estarán familiarizados mientras que los segundo nos ayudarán a obtener aplicaciones con bajo acoplamiento y mucho más fáciles de extender y mantener.
  • Familiarízate con el lenguaje de programación que estés empleando, no te quedes sólo en la superficie. Tómate tu tiempo en leer código de otros desarrolladores, artículos y publicaciones donde se emplee tu lenguaje favorito y descubre nuevas formas de hacer las cosas y todas las herramientas de las que dispones. Tanto Javascript como PHP están constantemente añadiendo nueva funcionalidad y recursos sintácticos para simplificar el código, por lo que no te quedes atrás.
  • Nombra bien los elementos. No hay nada como seguir una buena metodología de nombres para variables, funciones y clases a la hora de mantener el código. Si una función envía un email nómbrala apropiadamente y no recurras a nombres cortos para los elementos pensando que son más elegantes. A la larga agradecerás haber premiado que sean más descriptivos que cortos.
  • No confíes en nada ni des nada por supuesto. Muchos de los errores que suceden en el futuro se deben a dar por supuestos elementos que dependen de terceros por lo que no asumas que siempre serán correctos. Mejor prepara tu código ante posibles casos en los que no recibas lo que esperabas. Esto suele ser muy habitual en el tratamiento de datos introducidos por usuarios o en ficheros de inicialización, donde cometer fallos suele ser bastante habitual.
  • ¡DRY! Es decir, Don’t repeat your self. Evita duplicar funcionalidad por distintas partes del programa. Aíslala y agrúpala en un componente que puedas probar y que te permita realizar modificaciones en un único archivo sin tener que realizar el mismo cambio múltiples veces. Además, familiarízate con los sistemas de caché que tienes a tu disposición de cara a evitar calcular el mismo dato una y otra vez penalizando el rendimiento de la aplicación.
  • Loggea los errores. Otro de los elementos que nos ayudarán a resolver fallos futuros es loggear aquellas partes de nuestro programa que estén más propensas a fallar, de modo que, cuando finalmente se produzca un error podamos recorrer la traza de lo que sucedió y resolverlo más rápidamente.

Photo by NeONBRAND on Unsplash

Conclusiones

Como ya comentaba en un párrafo anterior, todo lo que he leído acerca de la programación defensiva me ha llevado a la conclusión de que se trata de una metodología destinada a ayudarnos a anticipar los fallos, no sólo los del presente (es decir, aquellos que encontramos a medida que desarrollamos el código) sino en el futuro de modo que, cuando se produzcan, nuestra aplicación este preparada adecuadamente para responder a ellos.

¿Verdad que no hay nada más desagradable que encontrarnos con un 500 en una aplicación web con el que no contábamos en ningún momento? Es aquí donde la programación adquiere todo su sentido y por lo que conviene tenerla en mente mientras desarrollemos. Los beneficios a la larga son realmente grandes.

Fuente:

View story at Medium.com

October 22nd 2019

Como utilizar target=”_blank” en un link con Angular

Número de lecturas: 446
{lang: 'es-419'}

En un desarrollo estaba utilizando siempre botones para navegar pero surgio la necesidad de crear un link que se debe abrir en otra página. En este caso se debe realizar lo siguiente.

Primero se define la ruta.

//app.routes.ts

{ path: 'partido/:id', component: PartidosComponent },
Luego en el componente .html se lo detalla de la siguiente forma, donde lo que nos interesa es esto:
[routerLink]="['/', 'partido', calendario.fixture_id]"
El primer campo indica desde donde inicia la ruta en este caso desde la raiz del dominio: / , luego se detalla el nombre que se definio en la ruta en este caso: partido y finalmente el parámetro si es que se necesita: calendario.fixture_id
Se lo puede ver en funcionamiento en este sitio:
Fuente:
https://alligator.io/angular/navigation-routerlink-navigate-navigatebyurl/
October 9th 2019

Simjacker: un ataque mediante la SIM

Número de lecturas: 544
{lang: 'es-419'}

Simjacker: vigilancia de teléfonos basada en la SIM.

Hace poco los expertos de AdaptiveMobile Security descubrieron un método de ataque en teléfonos móviles que se puede llevar a cabo utilizando una computadora normal y un módem USB barato. Mientras que algunos métodos antiguos para la vigilancia de teléfonos móviles requerían un equipo especial y una licencia operativa de telecomunicaciones, este ataque, llamado Simjacker, se aprovecha de una vulnerabilidad encontrada en las tarjetas SIM.

Todo se debe a S@T Browser

La mayoría de las tarjetas SIM que se han puesto a la venta desde principios del 2000, incluidas las eSIM, incluyen un menú sobre el operador. Este menú ofrece información sobre el saldo, opción de recarga, soporte técnico y, a veces, funciones adicionales como el tiempo o, incluso, el horóscopo. En los teléfonos antiguos aparece en el menú principal. Por su parte, iOS lo esconde en los ajustes (en Aplicaciones SIM) y en los teléfonos Android se trata de una aplicación llamada SIM Toolkit.

El menú es básicamente una aplicación (en concreto, varias aplicaciones con el nombre SIM ToolKit [STK]), pero estos programas no se ejecutan en el mismo teléfono, sino en la tarjeta SIM. Recuerda que tu tarjeta SIM es una computadora diminuta con sistema operativo y programa propios. STK responde a comandos externos, por ejemplo, al presionar un botón del menú del operador, y hace que el teléfono ejecute ciertas acciones, como enviar mensaje SMS o comandos USSD.

Una de las aplicaciones que incluye el STK se llama S@T Browser y se utiliza para ver páginas web de un cierto formato y páginas ubicadas en la red interna de la operadora. Por ejemplo, S@T Browser puede suministrar información sobre el saldo de tu cuenta.

La aplicación S@T Browser no se ha actualizado desde el 2009 y, aunque en los dispositivos modernos sus funciones las ejecutan otros programas, S@T Browser se sigue usando de forma activa o, al menos, sigue instalada en muchas tarjetas SIM. Los investigadores no han mencionado las zonas geográficas ni las empresas de telecomunicación en concreto que venden tarjetas Sim con esta aplicación instalada, pero aseguran que hay más de mil millones de personas repartidas en no menos de 30 países que las utilizan, y es precisamente en S@T Browser donde se encuentra la vulnerabilidad de la que estamos hablando.

Los ataques Simjacker

El ataque comienza con un mensaje SMS que contiene una serie de instrucciones para la tarjeta SIM. Siguiendo estas instrucciones, la tarjeta SIM solicita al teléfono móvil su número de serie y el identificador de celular de la estación base en cuya zona de cobertura se encuentre el suscriptor y envía un SMS de respuesta con esta información al número del atacante.

Las coordenadas de las estaciones se conocen (e incluso están disponibles en línea), por lo que el identificador de celular se puede utilizar para determinar la ubicación de los suscriptores que se encuentren a menos de unos cien metros. Los servicios basados en la ubicación dependen del mismo principio para determinar la ubicación sin asistencia satelital, por ejemplo, en interiores o cuando el GPS esté desactivado.

El usuario no se percatará de ningún tipo de manipulación que se realice en la tarjeta SIM. Ni los mensajes SMS entrantes con comandos, ni las respuestas con los datos de la ubicación del dispositivo aparecen en la aplicación de mensajería, por lo que es muy probable que las víctimas de Simjacker ni siquiera sepan que alguien las está espiando.

¿A quién ha afectado Simjacker?

Según AdaptiveMobile Security, los espías han estado rastreando la ubicación de usuarios de varios países no especificados. Y en uno de esos países, terminaron comprometidos entre 100 y 150 números al día. Como norma general, estas solicitudes se suelen enviar solo una vez a la semana; no obstante, los movimientos de algunas víctimas están mucho más monitoreados. De hecho, el equipo de investigación descubrió que varios usuarios recibían cientos de SMS maliciosos a la semana.

Los ataques Simjacker pueden ir mucho más lejos

Los investigadores han descubierto que los cibercriminales no usaban todas las funciones que ofrecía S@T Browser en la tarjeta SIM. Por ejemplo, el SMS se puede utilizar para hacer que el teléfono llame a cualquier número, envíe mensajes con un texto aleatorio a números arbitrarios, abra enlaces en el navegador o, incluso, desactive la tarjeta SIM, dejando a la víctima sin teléfono.

Esta vulnerabilidad da lugar a posibles y numerosas situaciones de ataque, donde los criminales pueden transferir dinero por SMS a un número de cuenta, llamar a números de pago, abrir páginas de phishing en el navegador o descargar troyanos.

Esta vulnerabilidad es especialmente peligrosa porque no depende del dispositivo en el que se inserte la tarjeta SIM vulnerable, sino que el conjunto de comandos STK está estandarizado y es compatible con todos los teléfonos e, incluso, con los dispositivos IdC con SIM. Para algunas operaciones, como realizar una llamada, algunos dispositivos solicitan la confirmación del usuario, pero muchos otros, no.

¿Cómo puede un usuario evitar los ataques Simjacker?

Por desgracia, no existe ningún método independiente para que los usuarios eviten los ataques de tarjeta SIM. Es responsabilidad de las operadoras móviles garantizar la seguridad de sus clientes. Sobre todo, deberían evitar utilizar aplicaciones de menú de SIM desactualizadas, además de bloquear los códigos SMS que contengan comandos peligrosos.

Pero también hay buenas noticias. Aunque no se necesita ningún hardware caro para ejecutar el ataque, sí requiere amplios conocimientos técnicos y capacidades especiales, por lo que es poco probable que cualquier cibercriminal pueda utilizar este método.

Además, los investigadores notificaron al desarrollador S@T Browser, SIMalliance, sobre la vulnerabilidad y, como respuesta, la empresa expidió una serie de directrices de seguridad para los operadores que utilizan la aplicación. Los ataques Simjacker también se notificaron a la Asociación GSM, una organización internacional que representa los intereses de los operadores móviles de todo el mundo. Por tanto, se espera que las empresas tomen todas las medidas de protección necesarias en cuanto tengan la oportunidad.

Fuente:

kaspersky.com

October 2nd 2019

En el desarrollo de apps ¿Flutter o Ionic?

Número de lecturas: 630
{lang: 'es-419'}
flutter o ionic

Los frameworks agilizan el trabajo de los programadores a la hora de desarrollar apps.

Su utilización garantiza una mayor productividad durante la jornada laboral, agilizando las horas de trabajo volcadas en el desarrollo.

Para ayudar a los desarrolladores y equipos a tomar la decisión correcta, esta breve guía explica las similitudes y diferencias entre Flutter o Ionic.

¿Qué es Flutter?

 

Flutter es un framework de Google. Permite, a partir de un mismo código, el desarrollo de apps compatibles con iOS y Android a una velocidad récord.

Basándonos en nuestra experiencia, Flutter mejora el rendimiento de las aplicaciones. Reduce su tamaño y es en general más estable y

produce menos errores.

¿Qué es Ionic?

 

Ionic es un framework originalmente basado en Angular. Permite a nuestros programadores el desarrollo de apps con tecnologías web. Utiliza estándares como HTML, CSS y JavaScript. Prepara el código de una app para que pueda funcionar tanto en plataformas iOS como en Android. También,  ofrece la posibilidad de realizar una compilación más y hacer una ampliación de escritorio basada en ElectronJS. Dando lugar a una Progressive Web App.

Flutter vs Ionic

Ionic y Flutter comparten una visión común de crear aplicaciones de alto rendimiento que funcionen en todos los dispositivos. Sin embargo, sus filosofías centrales no podrían ser más diferentes.

 

  • El principio de Ionic es utilizar la plataforma web. Adoptando estándares abiertos siempre que sea posible.
  • Al programar con Ionic se aprende sobre las herramientas y los lenguajes de la web. Es un framework diseñado para ofrecer un gran rendimiento en dispositivos móviles, equipos de escritorio y, especialmente, en la web.
  • Flutter, en cambio, crea un ecosistema propio que está en desacuerdo con los lenguajes comunes, conjuntos de herramientas y estándares que se encuentran en el mundo del desarrollo en general.
  • Flutter ofrece un rendimiento muy bueno en dispositivos móviles. Pero las limitaciones fundamentales de su arquitectura hacen que sea una mala elección para implementaciones basadas en web.
  • La elección de la solución debe basarse en dónde y cómo se planea implementar la app y qué habilidades se conoce o se quiere aprender en el futuro.

 

Visión compartida

Tanto Ionic como Flutter son únicos entre todos los otros enfoques de desarrollo de aplicaciones. Comparten la visión de crear un framework para diseñar la interfaz de usuario que funcione en todas partes. Ofreciendo un gran rendimiento y una buena experiencia de usuario dondequiera que se ejecute.

Mientras que la mayoría de los enfoques multiplataforma, como React Native, se centran casi exclusivamente en dispositivos móviles. Ionic y Flutter están diseñados para abordar dispositivos móviles, equipos de escritorio y la web. Todo esto con una base de código compartida.

La distinción clave entre ellas es la forma en que cada solución trata de realizar esta visión y en que medida pueden cumplirla.

Filosofías opuestas

Las diferencias entre Ionic y Flutter comienzan con la filosofía central de cada framework. Que no podría ser más diferente. En todo lo que hacemos en Ionic, el principio rector es “utilizar la plataforma” mediante la adopción de estándares y capacidades web abiertas siempre que sea posible.

Cuando se elige Ionic, no se apuesta realmente por Ionic. Se está apostando en la web.

Esto se debe a que Ionic y sus herramientas se basan en tecnologías web abiertas. Desde los lenguajes web que utiliza para crear aplicaciones (HTML, CSS, JavaScript) hasta los componentes de interfaz de usuario basados en estándares que se ejecutan dentro de la app.

Flutter ha optado por realizar su visión creando un ecosistema completamente nuevo y propio desde cero. Desde Dart, el lenguaje que usa Flutter para crear aplicaciones, hasta su motor de renderizado personalizado. Casi todo Flutter se basa en su propio conjunto de estándares que no aprovechan las capacidades del navegador, los lenguaje web y las librerías JavaScript de hoy en día.

Estas filosofías opuestas tienen un profundo efecto en lo que se puede hacer con cada framework, y el impacto que tienen tanto hoy como en el futuro.

Cómo funciona Flutter
El lenguaje central de Flutter es Dart, un lenguaje poco conocido que comenzó en 2011. Aunque lleva unos años, pocos desarrolladores lo conocen hoy (menos del 2%, según la Encuesta StackOverflow de 2019), y rara vez se usa fuera de la comunidad de Flutter.

Al compilar para dispositivos móviles, Flutter usa el compilador Dart para convertir su código Dart en un código nativo que se ejecutará en la plataforma del dispositivo. Junto con un motor de renderizado personalizado para mostrar su interfaz de usuario dentro de una app móvil.

Las aplicaciones móviles de Flutter acceden a las funciones nativas del dispositivo mediante una biblioteca de complementos similar a Ionic y React NativeFlutter no usa los elementos de la interfaz de usuario nativos. Como encontrarías en React Native, ni utiliza componentes web como Ionic. En su lugar, Flutter ofrece su propia biblioteca de widgets de interfaz de usuario.

Las aplicaciones móviles de Flutter acceden a las funciones nativas del dispositivo mediante una biblioteca de complementos similar a Ionic y React Native. Los paquetes listos para usar están disponibles para acceder a las funciones comunes del dispositivo. También se puede escribir código personalizado específico para la plataforma si el paquete o el complemento que se está buscando no está disponible. Utilizando una plataforma de mensajería asíncrona específica de Flutter que maneja la correspondencia entre el cliente (UI) y el host (sistema operativo de la plataforma).

En resumen, para cumplir con los objetivos establecidos de crear un “framework de IU que funcione en todas partes”. El equipo de Flutter utiliza el lenguaje Dart. Flutter utiliza un motor de renderizado personalizado, una implementación nativa y un framework web personalizado para el navegador. Reflejando su decisión de construir una arquitectura independiente.

Cómo funciona Ionic
Las aplicaciones de Ionic se crean utilizando los lenguajes web: HTML, CSS y JavaScript. Por lo tanto, si se sabe cómo construir una aplicación web básica, se sabe cómo crear con Ionic.

Con Ionic se puede implementar una aplicación nativa de iOS o Android, una aplicación de escritorio nativa o una aplicación web. Todo desde una base de código compartida única. Cuando se ejecuta en dispositivos móviles, Ionic se ejecuta dentro de un contenedor nativo utilizando Cordova o, más recientemente, Capacitor. Permite el acceso completo a cualquier API o características del dispositivo nativo. La interfaz de usuario de la aplicación móvil hecha con Ionic se ejecuta en un sitio web. Se trata de un navegador que es “invisible” para el usuario. En una implementación de escritorio, Ionic se ejecuta dentro de un contenedor de escritorio nativo como Electron, o directamente en cualquier navegador móvil o de escritorio como una aplicación web progresiva.

Ionic utiliza el estándar de componentes web. Por lo que se ejecuta en cualquier navegador web y son compatibles con cualquier framework JS, incluidos React, Vue y Angular. Ionic proporciona una biblioteca de más de 100 componentes de interfaz de usuario que puede personalizar con CSS para adaptarse a las pautas de la marca. También puede usar Stencil. Un compilador de componentes web de código abierto del equipo de Ionic. Para crear una propia biblioteca de componentes web personalizados. De hecho, cualquier componente de interfaz de usuario basado en web o biblioteca web se ejecutará en Ionic. Lo que ofrece la libertad de aprovechar cualquier elemento de la web para el proyecto.

flutter o ionic
En el desarrollo de apps ¿Flutter o Ionic?

Es importante tener en cuenta los siguientes factores:

Rendimiento

Flutter podría ser una mejor opción en cuanto a rendimiento. Sin embargo, en muchos casos, Ionic da el mismo rendimiento si está escribiendo una aplicación para un consumidor más estándar o para el uso de empleados. Hay que tener en cuenta que el rendimiento casi siempre se reduce a cómo se escribe el código. No depende de la plataforma o framework que se elija.

Ionic utiliza el tiempo de ejecución y los recursos del navegador estándar. Por lo que el tamaño de la aplicación suele ser muy pequeño. Flutter requiere una gran cantidad de código para aplicaciones muy básicas, porque envia todo ese tiempo de ejecución a pesar de que el navegador ya tiene funciones disponibles para casi todo. Por lo tanto, si se está buscando alcanzar los estándares de rendimiento de Google para aplicaciones web progresivas (PWA) o ocupar un lugar destacado en las páginas de resultados del motor de búsqueda, resultará casi imposible con el rendimiento actual de Flutter en la web.

Portabilidad de código

Cuando se trata de implementar una aplicación en dispositivos móviles y de escritorio, tanto Ionic como Flutter aparecen uniformemente emparejados. Con Flutter puedes crear algunas aplicaciones de iOS y Android con un solo código. Se puede compilar la aplicación para ejecutarse de forma nativa en una serie de plataformas de escritorio.

La pregunta es si se desea implementar la aplicación a través de la web. Ya sea como una aplicación web de escritorio tradicional o como PWA. Las limitaciones inherentes de la implementación web de Flutter probablemente nunca funcionarán para aplicaciones que requieren tiempos de carga rápidos y un rendimiento ágil. Sin mencionar que su enfoque propietario limitará el número de bibliotecas web que se puede aprovechar. Dado que Ionic se basa en la web y se basa completamente en los estándares web, creemos que es justo darle a Ionic la ventaja cuando se trata de dispositivos móviles, equipos de escritorio y la web.

Look & feel nativo

Aunque ninguno de los frameworks utiliza los elementos de la interfaz de usuario nativos de cada plataforma. Flutter e Ionic actualizan automáticamente el diseño de sus elementos de la interfaz de usuario para que coincida con la plataforma en la que se ejecuta la aplicación: Material Design para Android y Cupertino para iOS.

Ambas soluciones le permiten acceder a los servicios de la plataforma y las API nativas a través de una biblioteca de complementos predefinidos, con un conjunto de herramientas para crear sus propios complementos personalizados según sea necesario.

Sin embargo, debe tenerse en cuenta cómo es la implementación móvil nativa de Flutter. Si se está haciendo un trabajo nativo personalizado con Flutter, se debe aprender la manera en que Flutter trabaja con iOS y Android.

Conocimientos y habilidades

Aquí es donde las distinciones entre Ionic y Flutter se hacen realmente evidentes.

Primero, a menos que seas uno de los 1.9% de los desarrolladores que ya conocen Dart, en comparación con el 70% que conoce JavaScript, tendrás que pensar que quieres aprender un nuevo idioma. JavaScript es, por supuesto, una apuesta bastante segura para cualquier desarrollador. La necesidad de los desarrolladores de aprender Dart dependerá únicamente del éxito o fracaso de Flutter como solución viable a largo plazo.

Segundo, debido a que Flutter opera en su propio ecosistema altamente personalizado. Hay que aprender la forma de Flutter de hacer las cosas. Por ejemplo, si está resolviendo problemas de interfaz de usuario. Se aprenderá y dominará el motor de renderizado personalizado de Flutter. No las aplicaciones web en general. Cuando se interactúe con plataformas de dispositivos nativos, se debe aprender la interpretación de Android y iOS de Flutter, no Android o iOS en general. Este factor es uno de los mayores a considerar, al saltar a un silo de desarrollo que no comparte estándares y herramientas con otras plataformas.

En contraste, cuando estás creando con Ionic, no necesariamente estás aprendiendo Ionic. Estás aprendiendo cómo construir aplicaciones web en general. Se aprende a escribir con JavaScript, con CSS y a crear interfaces de alto rendimiento con componentes web basados en estos estándares.

Oportunidades para el futuro

El último factor a considerar es la vida útil del proyecto, la libertad y flexibilidad que se tendrá a medida que la aplicación madure.

Con Ionic, se apuesta por el desarrollo en la web. Por lo que incluso si eliges construir en otras plataformas en el futuro, todo lo que construyas se basará en estándares web abiertos. Y, dado que Ionic se basa en componentes web, puede usarlo con cualquier framework JS. Con Ionic se tendrá la libertad de aprovechar lo que sea que traiga el mañana.

La tecnología está en constante evolución y cada vez más rápido. Por lo que es necesario seleccionar la tecnología más versátil en cada momento. Que permita crear productos digitales y soluciones reusables, modulares, que puedan acoplar y desacoplar componentes fácilmente sin tener que rehacer el producto.

 

Gráfica comparativa

Para ayudar a resumir las distinciones clave entre Flutter y Ionic, esta tabla de comparación proporciona un desglose de algunas de las dimensiones que se deben considerar.

 

flutter o ionic

 

El principio de Ionic es utilizar la plataforma web y adoptar estándares abiertos siempre que sea posible. Cuando se trabaja con Ionic, se aprende y aplica las herramientas y los lenguajes de la web. Utilizando un framework diseñado para ofrecer un gran rendimiento en dispositivos móviles, equipos de escritorio y, especialmente, en la web.

Flutter, en cambio, ha optado por hacerlo solo. Creando un ecosistema propio que está en desacuerdo con los lenguajes comunes, los conjuntos de herramientas y estándares que se encuentran en el mundo del desarrollo en general. Por lo tanto, si se elige Flutter, se debe aprender la forma de Flutter de hacer las cosas. Por supuesto, hay beneficios claros para una arquitectura personalizada.

La mejor manera de descubrir cuál es el adecuado para un desarrollo es comenzar a construir con ambos y luego comparar las experiencias.

Fuente:

syntonize.com