Primera Parte. Ecosistema y Tendencias

 

Estos últimos años están siendo muy interesantes por todas las novedades tecnológicas que están apareciendo a disposición de los programadores, ya sea en la capa Front- End, en la capa Back-End, Sistemas o en DevOps.

Concepto Front-End y Back-End

Esquema conceptual Front-End y Back-End

Centrándonos en la capa Front-End, recientemente ha habido gran entusiasmo por los nuevos frameworks que se han ido consolidando o bien que se han ofrecido a la comunidad de programadores en versión estable.

Me animo a escribir este artículo de opinión (para gustos los colores, y actualmente existe  gran variedad a nivel frameworks) ya que muchos clientes nos preguntáis muy interesados acerca de estos temas: hoy esta es mi postura, mañana, viendo la rápida evolución de la tecnología podría ser otra (Web Assembly is coming!!).

Si tras leer este artículo seguís con dudas o no estáis seguros de las alternativas que tenéis (bien porque tenéis incorporada ya una determinada tecnología o por cualquier otro motivo), no dudéis en contactar con nosotros y os ayudaremos a encontrar la mejor solución para vuestras necesidades.

 

En busca del Rayo Verde

El Rayo Verde es un fenómeno óptico atmosférico que ocurre poco después de la puesta del sol o poco antes de su salida, en el que se puede ver un punto verde, normalmente durante uno o dos segundos, sobre la posición del sol.

En la novela de Julio Verne “El Rayo Verde” cuenta la leyenda que dos personas que vean este fenómeno a la vez quedarán automáticamente enamoradas la una de la otra: es un momento mágico en el que dos descubren el amor a la vez. Yo descubrí esta curiosidad viendo la película homónima de Eric Rhomer y me encanta esta leyenda ya que se podría interpretar como que para que surja el amor es necesario que confluyan tanto el instante en el que mires, como la persona con quien lo mires: quizás un artículo pudiera considerarse como un Rayo Verde en el que un cliente, al leerlo en un determinado instante y con un determinado proveedor, pudiera enamorarse de un determinado framework…<3

La presentación de ES2015 / ES6 (y ES7) y la normalización del uso de transpiladores (Babel, Typescript o el fallido Dart) han contribuido a la eclosión de algunos frameworks, ya que nos permite normalizar nuestros proyectos y/o prepararlos para las nuevas funcionalidades que ofrecerá Javascript en sus versiones más modernas.

 

  

(¿fallido Dart? ver anuncio de google sobre Fuchsia OS)

 

Vamos a suponer que, en un contexto empresarial, necesitamos estandarizar de algún modo nuestros desarrollos, por lo que es imprescindible que hagamos uso de frameworks (espero que como lector te parezca bien esta premisa); sin embargo, muchos nos preguntamos cuando iniciamos un proyecto:

 


¿Cuál es el mejor framework a utilizar en Front-End?

¿Cuál es la madre de todos los frameworks?

¿Qué framework me garantiza una larga vida?

¿Qué framework me permitirá lanzar nuevos servicios en tiempo record, garantizando un determinado rendimiento?

¿Quién y cómo me podrá desarrollar mejor la aplicación, adaptándose a lo que busco?


 

A excepción de la última pregunta cuya respuesta es Fecron Consulting Services  (:-)), la respuesta al resto de cuestiones parece incierta. Lo que es seguro es que no hay un framework perfecto del mismo modo que no hay un vehículo perfecto que nos lleve a nuestro destino: todo dependerá de nuestra necesidad. En mi pueblo hubo un chico que se compró un deportivo para ir al campo a trabajar y la cosa no funcionó mucho tiempo… los extremeños somos así… del mismo modo, también puede haber un framework mejor que el resto para cubrir una necesidad concreta: también hay extremeños que pensamos que hay herramientas específicas, para necesidades específicas… 🙂

Entonces, intentemos dar respuesta a la pregunta que realmente nos inquieta:

 


¿Qué framework de Front-End nos conviene más utilizar?


 

Hay opiniones para todos los gustos: podemos encontrar tanto fuertes críticas como grandes alabanzas sobre según qué decisiones acerca de qué framework es mejor para uno u otro caso. En ocasiones surge gran polémica interna a nivel de corporación en relación a indecisiones o decisiones precipitadas; no obstante, todas esas decisiones suelen estar marcadas por las necesidades de las empresas de sacar al mercado sus nuevos productos y servicios de la forma más ágil posible y en los plazos que marcan los equipos de dirección. Este aspecto es uno de los que debería regir principalmente en nuestra elección, ya sea planteada esta premisa a corto, medio ó largo plazo; sin embargo, también habría que tener en cuenta otros aspectos, como luego expondremos.

Tomemos como ejemplo Polymer. Este framework se vendió como una biblioteca de webcomponents que nos facilitaría lanzar nuevas aplicaciones sin más que incorporar dichos componentes a nuestra web, permitiéndonos máxima reutilización y ayudando a respetar nuestros Look & Feel.

Desde la versión 0.5, la fugaz 0.8, la primera versión estable de Polymer 1.0, hasta la versión 2.0 actual, se han ido incorporando y eliminado mejoras y conceptos nuevos incluidos en los RFCs (custom elements, shadow-dom/shady-dom, imports, templates) que han convertido al framework en una novedad importante hasta el punto de que grandes empresas han normalizado incluso su uso de forma interna. Por un lado, la decisión de adoptar Polymer en fases tempranas del proyecto podría retrasar la salida de nuestras aplicaciones e incluso que se nos planteen dificultades a la hora de encontrar desarrolladores. Por otra parte, dominar una tecnología desde su inicios ofrece una ventaja competitiva basada en la experiencia y desarrollo a largo plazo.

 


¿Será una buena decisión para nuestra compañía el incorporar Polymer?

¿Será precipitada su elección como framework?


 

El tiempo y sobre todo, el uso que nosotros mismos hagamos de esa tecnología nos lo dirá. De momento observamos un vacío a la hora de encontrar variedad de proyectos basados en Polymer, aunque sí hemos visto que su integración con Angular (nuevo framework basado en muchas ideas del ultra-conocido AngularJS 1.X) es sencilla, a lo cual ayuda el que Google sea el promotor de ambos proyectos. Quizás otro framework como Angular ayude a dar valor a Polymer y salve la inversión de la elección de Polymer como referencia de framework empresarial (si es que lo podemos considerar como un auténtico framework).

Angular, al igual que Polymer, ha sufrido bastantes variaciones desde su publicación inicial en estado beta en diciembre de 2015 hasta su versión 4.1.0 actual (lanzada finales de abril de 2017); de hecho, ambas versiones (2 y 4) no son compatibles del todo y ha pasado casi año y medio desde lo que parecía su inminente liberación (considerando su anuncio y fase alpha: casi dos años).

 


¿Hubiera sido una buena elección abrazar Angular en diciembre de 2015?


 

Si los tiempos de negocio hubiesen establecido el lanzamiento de las aplicaciones a producción en mayo o junio de 2017 la elección hubiera sido correcta, si los tiempos de la empresa hubiesen sido otros, esta decisión habría sido un fracaso rotundo debido al retraso y el coste de oportunidad. Sin embargo, una vez salvada la incertidumbre inicial, la empresa ahora dominaría la tecnología y le sería más fácil iniciar proyectos basados en dicha tecnología. Quizás si hubieras mirado a Angular en diciembre de 2015 buscando el Rayo Verde, quizás habrías encontrado un tormenta de incertidumbres.

Otras polémicas surgieron también con el framework Angular ya que ha habido bastantes críticas hacia Google al tratarse de algo totalmente nuevo e incorporar dicho nombre para denominar al nuevo framework.

Angular está escrito desde cero (inicialmente denominado Angular 2, actualmente en su versión 4 y denominado simplemente Angular) y se ha adoptado un nuevo lenguaje transpilador como Typescript (inicialmente AtScript y Dart) para su programación; no obstante, la estrategia final de Google, además de innovadora, parece acertada: está evolucionando AngularJS 1.X hacia Angular en lo que parece un intento de convergencia en un sólo framework para facilitar la migración, de este modo si tenemos una aplicación escrita en AngularJS, podemos ir actualizando las nuevas innovaciones para finalmente dar el salto a Angular. Sin duda son de agradecer también los esfuerzos de Google en permitir que haya aplicaciones escritas parcialmente en Angular y AngularJS 1.X. El problema de llevar a cabo esta estrategia es que actualmente, por restricciones de compatibilidad de ejecución, siempre será una aplicación AngularJS 1.X, lo cual excluye las verdaderas innovaciones de Angular.

Continuando con la incorporación de frameworks por el mercado, ha sido sorprendente lo rápido que la aparición o evolución de nuevos frameworks (React, Angular, Vue) ha llevado a otros que eran muy populares (Ember, Backbone) a un ostracismo preocupante para las empresas, hasta el punto de que algunos desarrolladores huyen de esos proyectos por encontrarse con código mal estructurado, abuso de malas prácticas (las cuales aunque no son deseables, es prácticamente inevitable que existan en todos los proyectos, ya sea por la impaciencia del cliente o debido a la rotación de personal) o por un escaso recorrido profesional.

Podemos corroborar lo comentado en el párrafo anterior con la información sobre las búsquedas en Google y los intereses de los desarrolladores que buscan empleo:

 

No obstante, cada framework va encontrando poco a poco su hueco, el espacio ocupado anteriormente por AngularJS 1.X lo va ocupando React, el famoso framework de Facebook; pero React es sólo una biblioteca, por lo que no está a la par con, digamos, Angular, AngularJS o Ember. Para hacer que React se acerque más a la arquitectura MVC, Facebook introdujo un enfoque para construir la arquitectura de aplicaciones y lo llamó Flux ¿éxito o fracaso? De momento apunta maneras y la guerra del desconsenso continúa.

 

Si has llegado hasta aquí: ¡estupendo, el tema te interesa y estás en el lugar acertado!… 🙂

Como hemos visto hasta ahora hay muchos frameworks (sólo hemos mencionado algunos), pero si estás de acuerdo conmigo en que cada framework puede tener su ámbito de uso,  aplicación y contexto, sigue leyendo la segunda parte del artículo donde intentaremos mostrar qué framework nos podrían ayudar para construir las aplicaciones que nuestra empresa necesita.

Segunda Parte. La elección más empresarial

 

No debemos perder el foco a la hora de seleccionar un determinado framework a nivel empresarial y es que lo que buscamos es sacar nuestros productos y servicios lo más rápido posible, con un nivel de rendimiento mínimo requerido, con una determinada usabilidad y con cierta facilidad para el mantenimiento y evolucionado. Si somos un banco y queremos modificar el flujo del “enrollment” sería estupendo que se pudiera realizar en 24h sin despliegue: desde Fecron Consulting Services facilitamos a nuestros clientes el poder hacer ésto a través de una interfaz gráfica de usuario, lo que les permite liderar el mercado desde el Departamento de Negocio (si estás interesado en una demo de la magia que hacemos, contacta con nuestro departamento comercial; si buscas rapidez y calidad somos tu equipo).

Angular (desmarcándose en muchos aspectos de AngularJS 1.X) parece que está centrando sus esfuerzos en construir un framework orientado a grandes corporaciones debido a su adopción de Typescript y a la transpilación desde un lenguaje pseudo-tipado. Aunque actualmente cualquier framework puede (y debe */**) ser programado en Typescript, esta decisión ha sido fundamental para enmarcarlo dentro de los frameworks ideales para proyectos a largo plazo que pueden recibir una alta rotación de personal ya que, esas malas prácticas antes mencionadas, quedan mucho más acotadas en la estructuración del código tipado. Además, la adopción de Java por parte de muchas empresas y la similitud en muchos aspectos con Typescript, permite a los desarrolladores una curva de aprendizaje suave  desde el perfil Back-End hacia el Front-End (y viceversa) formando, en algunos casos, equipos Scrum con perfiles Fullstack sin tener que conocer en detalle exhaustivo todo un ecosistema.

* Todos los desarrolladores (incluso los gurús superdotados que nos iluminan con sus nuevas ideas) en algún momento de nuestra carrera profesional hemos generado código que dista del Clean Code: esto sucede principalmente en las primeras fases de nuestro aprendizaje, pero también cuando estamos iniciándonos en una determinada tecnología e incluso cuando estamos aprendiendo la estructura de un proyecto al que nos incorporamos. Muchas veces los desarrolladores somos controladores: eres desarrollador y, como tal, no te gusta usar un transpilador como Typescript ya que introduce un nuevo punto de fallo difícilmente trazable. Pero quizás como desarrolladores opinamos teniendo en cuenta nuestro trabajo y no las circunstancias. Y la realidad es que en proyectos empresariales trabajamos en equipo y somos prescindibles y sustituibles, por lo que prima el orden, la coherencia, la buena estructuración del código, mejorar la mantenibilidad, la facilidad de evolución y muy importante, también, que los nuevos miembros del equipo no tengan la sensación de incorporarse a un campo de minas: Typescript nos ayuda a todo esto y mucho.

** Otra ventaja de usar Typescript (que junto con Visual Studio Code son de las pocas cosas que me entusiasman de Microsoft)  es que nos permite seleccionar sobre qué versión de Javascript  (ES5, ES6, ES7, experimental y lo que venga) queremos transpilar nuestro código, por lo que podemos aprovechar todas las ventajas que vayan incorporando los navegadores soportados en el proyecto sin tocar apenas nuestro código, aspecto que a futuro nos evitará refactorizaciones y supondrá un ahorro de costes importante.

 

La Ensalada Definitiva

Hace algunos años cuando trabajaba para una gran multinacional española de tecnología, me “tocaba” viajar mucho para dar soluciones de comunicaciones a grandes bancos. En uno de mi viajes a Andorra me di el capricho (me pagaban muy bien las dietas de desplazamiento al extranjero) y cené en un restaurante una ensalada que me entusiasmó: tomé nota de los ingredientes y posteriormente la he preparado en varias ocasiones, siempre con gran éxito entre mis invitados. La llamé “la ensalada definitiva” (no la llamé “la mejor ensalada del mundo mundial”): tenía los ingredientes justos y estaba especialmente buena (si tenéis curiosidad sobre la receta podéis contactar también… eso sí, los ingredientes son gourmet ;-)) En mi opinión parece que a Angular le va a ocurrir lo mismo que a mi ensalada favorita, creo que es el mejor posicionado para convertirse en el Framework Definitivo ya que tiene los ingredientes justos y es especialmente bueno.

Aunque con AngularJS 1.X ya era posible incorporar la funcionalidades de lazy load y cacheado en forma de código Javascript (con las templates, por ejemplo) a través de ciertos servicios y herramientas ($templateCache, gulp, gulp-angular-template-caché, junto con gulp-inject, por ejemplo), ahora Angular lo facilita proporcionando “de caja” una importante mejorar en la carga de las aplicaciones que puede impresionar a más de uno.

Así, una aplicación de Angular consiste en una gran cantidad de componentes y sus respectivas templates en HTML. Antes de que el navegador pueda renderizar la aplicación, los componentes y las plantillas se deben convertir a código Javascript ejecutable. Este proceso lo realiza el propio compilador de Angular en tiempo real, el cual se carga en el navegador (Just-in-Time) o previamente en el despliegue, para posteriormente ser ejecutado desde su core en el navegador (Ahead-of-Time), es decir, de forma laxa:

 

  • En el caso de la compilación Just-in-Time de Angular, la template se recupera y se pasa por el compilador de Angular cargado en el navegador para generar código Javascript, de modo que es ejecutado por el core de Angular, también descargado y ejecutado en el navegador.
  • En el caso de la pre-compilación Ahead-of-Time de Angular, se ofrece una herramienta en el angular-cli que permite pre-compilar la aplicación al código Javascript que necesita el core de Angular del navegador, por lo que de esta forma no es necesario pre-compilar a Javascript en el navegador. El código precompilado ocupa menos que el original (en el modo JIT) y ya no es necesario cargar en la aplicación el precompilador de Angular (que en bytes es aproximadamente el 50% de la biblioteca Angular) por lo que la aplicación se carga más rápido (archivos más pequeños) y se ejecuta más rápido (se evita el compilado de los componentes en el navegador). Puedes ver un resumen más extendido aquí sobre diferencias de rendimiento.

 

Pero ahí no queda todo, Angular es más que un framework de plataforma para el Front-End en el lado del cliente (bien pensado y con pocas improvisaciones) en sus versiones estables para producción; parece más bien que es una idea que va más allá, intentando universalizar toda la arquitectura con Angular Universal.

Logo oficial de Angular Universal

El proyecto Angular Universal (se incorporó en www.angular.io, aquí, la documentación del proyecto recientemente) consiste en una API de base y en las herramientas ofrecidas que permiten al desarrollador realizar renderizaciones en el lado del servidor (o pre-renderizado) de aplicaciones escritas en Angular. Esto sería un gran paso en su intento de universalizar Angular como tecnología, tratando de desmonopolizar las aplicaciones de servidor donde Java y .NET mandan en el mundo corporativo.

 

 


¿Será Angular, junto con Angular Universal, la alternativa de Spring framework?

¿Se convertirá Angular, junto con todo el ecosistema que está surgiendo a su alrededor en el Framework Definitivo empresarial?


 

Hasta hace muy poco tiempo, no eran muchos los que se hacían estas preguntas; si estás interesado en el tema una buena opción es este link de Michael Prentince.

Si observamos las pruebas de rendimiento que ofrece la página oficial de Angular, vemos unas diferencias significativas:

Rendimiento de Angular en modalidad JIT, AOT y Angular Universal

Pruebas de rendimiento de Angular en modalidad JIT, AOT y Angular Universal

Las tres soluciones de la gráfica anterior, marcan unos tiempos aceptables en un entorno normal de trabajo; sin embargo, cuando la capacidad de computación del dispositivo es menor y la red está saturada o hay una mala conexión (forzando la simulación a dispositivos 5 veces más lentos y simulando una red más lenta de 3G network:750kb/s) se obtienen los siguientes resultados:

Rendimiento de Angular en modalidad JIT, AOT y Angular Universal en dispositivos y redes lentas

Pruebas de rendimiento de Angular en modalidad JIT, AOT y Angular Universal en dispositivos y redes lentas

Vemos que los resultados asombran en aspectos de rendimiento en la versión con Angular Universal. La versión Angular Universal carga la página principal en 0,4s, ya que no tiene que esperar el código Javascript para cargar. La aplicación no estaría completamente disponible funcionalmente hasta que el bundle de Javascript hubiera cargado, lo cual sería comparable en tiempo a la versión AOT (5,5 seg), pero el usuario podría ver la página principal inmediatamente; así, si queremos que la aplicación sea usable en redes lentas debemos elegir AOT y Angular Universal debería usarse si la primera impresión de página fuese importante.

Vaya rollo os estoy metiendo… continuamos que hay algunos ingredientes verdes más a tener en cuenta… 🙂

 

Tercera Parte. Divide y Vencerás, Repite y Perderás

 

Aún no hemos hablado de un aspecto muy importante a la hora de seleccionar el framework y es la reutilización del código. Cualquier desarrollador con algo de experiencia sabe que repetir código es lo que mata a un proyecto, por lo que se debe cuidar mucho este aspecto tanto en lo escrito para Javascript (o Typescript), templates y HTML, como en CSS.

Si repetimos tendremos que mantener y testear reiteradamente, algo que a ser posible deberíamos evitar hacer sobre nuestro código. Pero al igual que para nuestro código, idealmente también deberíamos trasladar esta premisa a nuestra colección de aplicaciones (evitar repetir partes de código o funcionalidad en otros lenguajes) así como a nuestros componentes.

Ya que tienes una aplicación web, ¿por qué no mostrarla con pantallas táctiles en tus oficinas? Si hay cola quizás obtengas nuevos clientes en el acto. Considerando el caso más típico, ¿por qué no reutilizar el mismo código para dispositivos móviles? Y ya que estamos, ¿por qué no también para televisores? Si es posible (que hoy en día lo es) esto lo haremos ejecutando el mismo código sobre cada dispositivo: ¡maravilloso!

¿Y si pudiéramos generar aplicaciones para dispositivos móviles que no necesitan descarga del market de turno? Estaría bien, ¿verdad? Pero estaría  mucho mejor si no tuviéramos que reescribir la aplicación. Esto es posible de lograr con las PWAs, cuyo acrónimo se refiere a las Aplicaciones Web Progressivas o Progressive Web Apps en sus siglas en inglés y según Google:

 

Una PWA utiliza las últimas tecnologías disponibles en los navegadores para ofrecer una experiencia en móviles lo más parecida a la de una aplicación nativa.

 

En la mayoría de los casos, gracias a la generación de aplicaciones híbridas con tecnologías como Cordova (sin tilde: [kor’ðoβa]) o Phonegap es viable gestionar dichas aplicaciones y desplegarlas con código Javascript/HTML/CSSs. Así, hay frameworks para aplicaciones híbridas (Ionic, Intel xdk, framework7) que utilizan internamente otros frameworks o paradigmas (Angular, VanillaJS, Vue) para establecer esa reutilización de forma optimizada, por lo que es extremadamente interesante tenerlo en cuenta antes de la elección.

Como aspirantes de transpiladores a código nativo compilado y para re-aprovechar nuestro código, tenemos a ReactNative que transpila y compila tu código escrito en React a código nativo para tus aplicaciones móviles y también ha surgido NativeScript, que permite reutilizar el código en Angular con algunas modificaciones (también Typescript o VanillaJS) para hacer lo propio. Aunque estas tecnologías están en fases tempranas y en ocasiones suponen verdaderos quebraderos de cabeza para los equipos de desarrollado (además del encorsetamiento a la hora de utilizar determinados componentes), parecen tecnologías prometedoras, debido, sobre todo, a la mala fama que supusieron ciertas aplicaciones híbridas en relación a la fluidez.

Ahora bien, gracias a los web-workers, service-workers y a las mejoras que han introducido algunos frameworks a nivel de rendimiento, entre los que destaca (de nuevo) Angular, se ha permitido a frameworks para aplicaciones híbridas, como Ionic (actual versión 3 de Ionic está basada en la versión 4 de Angular), suplir esas carencias y desarrollar aplicaciones para móviles (y escritorio desde la versión 2.2.0 de Ionic) que permiten ejecutar multihilo con desarrollados basados en Javascript (transpilado desde Typescript).

Todo esto puede parecer una opinión sesgada, pero Ionic (Angular) nos ofrece:

 

  • Aplicaciones híbridas con rendimiento perceptible similar a las aplicaciones nativas
  • Reutilización y flexibilidad de programación con Javascript (TypeScript)/HMTL5/CSS3
  • Mantenibilidad de un lenguaje tipado (Typescript) como en las aplicaciones Nativas
  • Posibilidad de generar Progressive Web Aplications (PWA) (cosa que no permiten las aplicaciones nativas)

 

Por lo anterior, podríamos concluir que la elección de hacer uso de las tecnologías que generan aplicaciones híbridas puede ser una muy buena decisión a nivel empresarial y corporativo, ya que sus ventajas superan la mala fama de las aplicaciones híbridas en sus inicios y de nuevo, el Framework Definitivo de Google, Angular, aparece en escena.

Es quizás también importante recalcar que un equipo de expertos, al igual que un framework, es también una herramienta para las organizaciones que necesitan desarrollos. Y esta herramienta es clave a la hora de valorar opciones y tomar las decisiones más adecuadas a las necesidades de cada organización… ¿Lo ves? Está justo aquí… es el Rayo Verde:

 

Muchas gracias Eduardo Redondo, Verónica Sánchez y Juanjo José Ramírez por vuestro feedback… 🙂

REFERENCIAS:

  • TRANSPILADORES

    • https://babeljs.io/
    • https://www.typescriptlang.org/
    • https://www.dartlang.org/
  • FRAMEWORKS

    • https://www.polymer-project.org/
    • http://aurelia.io/
    • https://marionettejs.com/
    • http://knockoutjs.com/
    • https://www.emberjs.com/
    • https://facebook.github.io/react/
    • https://vuejs.org/
    • https://angular.io/
    • https://angularjs.org/
  • OFICIAL:

    • https://angular.io/docs/ts/latest/guide/ngmodule.html#!#bootstrap
    • https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
    • https://universal.angular.io/
    • https://developers.google.com/web/updates/2016/09/devtools-digest#cpu_throttling_for_a_mobile-first_world
    • https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#throttling
  • OTROS:

    • https://w3c.github.io/webcomponents/spec/custom/
    • https://w3c.github.io/webcomponents/spec/shadow/
    • https://www.polymer-project.org/blog/shadydom
    • https://www.campusmvp.es/recursos/post/Que-son-las-Aplicaciones-Web-Progresivas-o-Progressive-Web-Apps.aspx
    • https://www.w3schools.com/html/html5_webworkers.asp
    • https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
    • http://blog.ionic.io/ionic-2-2-0-is-out/
    • http://webassembly.org/
    • https://www.campusmvp.es/recursos/post/JavaScript-ECMAScript-ES6-Existe-ES7-Aclarando-las-diferentes-versiones-del-lenguaje.aspx
  • WIKIPEDIA:

    • https://en.wikipedia.org/wiki/AtScript
    • https://en.wikipedia.org/wiki/Dart_(programming_language)
  • ESTADÍSTICAS:

    • https://trends.google.com/trends/explore?q=backbone.js,vue.js,ember.js,knockout.js,react.js
    • https://www.indeed.com/jobtrends/q-Angular.JS-q-backbone.js-q-knockout.js-q-ember.js-q-ext.js-q-react.js-q-vue.js-q-Angular2.html
    • https://www.indeed.com/jobtrends/q-Angular.JS-q-backbone.js-q-knockout.js-q-ember.js-q-ext.js-q-react.js-q-vue.js-q-Angular2.html
  • DEBATES:

    • http://stackoverflow.com/questions/12694530/what-is-typescript-and-why-would-i-use-it-in-place-of-javascript
  • APLICACIONES MÓVILES/HÍBRIDAS:

    • https://cordova.apache.org/
    • http://phonegap.com/
    • https://ionicframework.com/docs/
    • https://software.intel.com/es-es/intel-xdk
    • http://framework7.io/
    • https://facebook.github.io/react-native/
    • https://www.nativescript.org/
mayo 5, 2017

Frameworks Front-End 2017 para grandes empresas

Normalmente las grandes empresas utilizan frameworks Front-End para el desarrollo de sus proyectos, pero en 2017: ¿Cuál es el mejor framework a utilizar en Front-End? ¿Cuál es la madre de todos los frameworks? ¿Qué framework me garantiza una larga vida? ¿Qué framework me permitirá lanzar nuevos servicios en tiempo record, garantizando un determinado rendimiento? ¿Quién y cómo me podrá desarrollar mejor la aplicación, adaptándose a lo que busco? En este articulo buscamos dar un rayo de luz a todas estas preguntas que soléis hacernos.
abril 5, 2016

SDL XPM y Smart Target: simulación de footprints

SDL Smart Target permite ofrecer al visitante contenido personalizado según los datos que conocemos de él. Pueden ser datos genéricos, como la ubicación desde la que accede a internet, datos personales, si se trata de un usuario logado, o información que podemos haber rastreado, como las páginas que ha visitado. De esta manera se ofrece al usuario una experiencia personalizada, adaptada a sus gustos y necesidades particulares.
enero 21, 2016

Nuevo tarificador de autos y motos MAPFRE

El pasado mes de Noviembre vió la luz el nuevo tarificador de automóviles para dispositivos móviles de MAPFRE. El proyecto tenía como objetivo el desarrollo de una versión del tarificador de autos y motos adaptada a dispositivos móviles. Con el objetivo de ajustarse al máximo a las necesidades de los usuarios que utilizan un terminal móvil, se simplificaría el número de campos en comparación con el antiguo tarificador web.
diciembre 22, 2015

Sublime Text

Un editor de texto Multiplataforma para código, de una interfaz muy limpia e intuitiva, que soporta Plugins , Snippets y Build Systems. Está escrito en C++ y Python, e incluye CPython2.6 y una consola embebida. A demás tiene soporte nativo para infinidad de lenguajes.
octubre 24, 2015

Metodologías ágiles en proyectos CMS

CMS es un tipo de proyecto, en el que la base son las paginas de contenidos. Son los portales de contenido, corporativos, fundaciones, etc. El desarrollo de este tipo de portales mediante metodologías ágiles, tiene desde nuestra experiencia, muchas ventajas.