Mostrando entradas con la etiqueta JavaScript. Mostrar todas las entradas
Mostrando entradas con la etiqueta JavaScript. Mostrar todas las entradas

jueves, 12 de abril de 2018

Cómo Elegir el Mejor Framework de Front-End

Este articulo fue escrito por Giorgi Bakradze. Originalmente publicado en Toptal.
El mundo de JavaScript es un entorno rico con docenas de herramientas, bibliotecas y frameworks. Pero, con muchas opciones, viene mucha confusión. Realmente es una espada de doble filo.
Si bien tienes mucho espacio para la creatividad y la experimentación, a veces no estás seguro de qué biblioteca o framework elegir.
¿Cuál es el mejor framework de front-end?
El framework de front-end que elija puede hacer o deshacer su proyecto en el largo plazo.
En este artículo, veremos algunos de los frameworks de JavaScript más populares y cómo se comparan entre sí. Examinaremos cinco perspectivas diferentes de estos frameworks, lo que generalmente facilita el proceso de tomar una decisión sobre su próximo framework de JavaScript.
Ya sea que elijas uno de estos populares frameworks de JavaScript o algo más esotérico, debes tener en cuenta cada uno de estos aspectos.

Disponibilidad de recursos de aprendizaje

Este es obvio, pero a menudo se pasa por alto. Si bien la elegante página de inicio de algún framework puede llamar su atención, aún necesita algunos cursos, libros, tutoriales y artículos adicionales además de la documentación aburrida y seca para ayudarlo a comenzar.
Crear un framework impresionante es una cosa y comunicar las ideas centrales detrás de esto es diferente. De hecho, hay muchos desarrolladores profesionales que se especializan en coaching. Un recurso de aprendizaje bien diseñado reducirá drásticamente su curva de aprendizaje.
Busca recursos de autores confiables con los que tenga experiencia previa; al final valdrá la pena su tiempo. Si tienes dificultades para encontrar algo útil, ten cuidado: el framework que estás tratando de aprender podría ser nuevo, o aún no haber sido adoptado por la comunidad.
img
Aunque mencioné que la documentación sola no es suficiente, hay excepciones a esto. EmberJS, por ejemplo, tiene gran documentación. Las características principales y los casos de uso están muy bien descritos con ejemplos genéricos aquí y allá. Lamentablemente, además de la documentación, nos quedan pocos libros de recursos, cursos de video u otros materiales.
Por otro lado, hay una gran cantidad de recursos para Angular y Reaccionar. Casi cualquier sitio web educativo orientado al front-end tendrá un artículo o dos sobre ellos, tal vez incluso un video curso o libro completo.
El tipo de Vue toca fondo: tiene buena documentación y hay algunos buenos cursos entre los que puede elegir.
Aurelia, por ejemplo, tiene casi cero recursos; la única esperanza para ti es documentación y suerte.
Prefiero tener opciones.
Incluso si lee un gran libro o curso, existe la posibilidad de que aprenda algo nuevo al exponerse a diferentes recursos. Si está familiarizado con el tema, a menudo puede hojear y buscar posibles áreas que aún no están del todo claras.
Desafortunadamente, esta estrategia no funcionará si estás limitado con tus opciones, lo que nos lleva al siguiente punto.

Popularidad

Puede enorgullecerse de aprender algo exótico, pero si observa esto desde una perspectiva comercial, no es lo mismo. Su empresa o cliente probablemente prefiera un conjunto de herramientas probado en batalla para ser utilizado.
Hay varias razones para esto. Si un framework no es tan popular, significa que hay algunos desarrolladores que se especializan en él. ¿Qué sucede si abandonas el proyecto o encuentras un nuevo trabajo? Su empleador termina atascado en la búsqueda de un desarrollador que conozca el framework que utilizó.
Este proceso puede convertirse en una carga real para una empresa. Lo mismo es válido incluso si te quedas con el proyecto y crece. Ahora el empleador necesita más desarrolladores para acelerar el desarrollo.
Hay otras razones personales por las que puede optar por un framework popular y ampliamente utilizado. ¿Qué sucede si te encuentras atascado con algún problema y no hay realmente una comunidad a la que puedas pedir ayuda? Ya que está solo con la documentación, es probable que pierda mucho tiempo.
Además de eso, desea pensar en oportunidades futuras más atractivas en su carrera. Si te especializas en algo popular y te haces muy bueno, habrá muchos proyectos para ti.
Los líderes obvios aquí son Angular y Reaccionan.
La mayoría de los listados de trabajos relacionados con el front-end requieren uno u otro. Están respaldados por Google y Facebook, respectivamente, y por lo tanto, los empleadores se sienten “seguros” sobre su elección.
A veces, la elección del framework para tu empresa o cliente no depende de usted; tal vez fue hecho por un empleado anterior u otra persona en el equipo. Lo más probable es que sea angular o reaccione. Ahora hay otras opciones, como Ember y Vue. Pero, tienes que buscar deliberadamente compañías que los usen.
Puede determinar la popularidad de un framework analizando rápidamente qué tan bien está funcionando el proyecto en GitHub y en otros lugares. Aquí hay algunas estadísticas recopiladas al momento de escribir este artículo:
 Angular 2ReactEmberVue
Stars on GitHub26,92473,53018,15463,438
Contributors on GitHub4951044679122
Tagged questions on StackOverflow66,15254,15821,6518,598
Aunque estas bibliotecas han existido durante el tiempo suficiente como para demostrar que son opciones populares, si está intentando algo realmente nuevo, las estadísticas similares pueden ayudarlo a tomar una decisión.
Aprender sólo Angular o React solo te llevará tan lejos en tu carrera. Por supuesto, tendrá muchas oportunidades, pero hay una razón por la que existen otros frameworks. Intenta aprender sobre ellos en tu tiempo libre y ocasionalmente haz algunos experimentos. Incluso si nunca los usa en proyectos reales, obtendrá valiosos conocimientos que lo ayudarán en su trabajo diario de desarrollo.

Funciones principales

Vamos a ponernos un poco técnicos ahora.
Al principio, desea hacer una breve descripción de las características principales del framework para tener una expectativa adecuada cuando comience a codificar. Para ello, escanee la documentación. Necesita tener una idea de lo que trata este framework en general. ¿Es solo una capa de visualización, completamente desarrollada o algo intermedio?
img
Si tienes una amplia experiencia previa con otros frameworks, este proceso es fácil y rápido. Busca los siguientes temas en la documentación: creación de plantillas, administración de estado, comunicación HTTP, procesamiento y validación de formularios, y enrutamiento. Esas son cosas de todos los días que haces como desarrollador. No todos estos pueden presentarse en el framework central, o puede haber un enfoque diferente para un problema en particular.
Toquemos las opciones populares brevemente.
Comenzaremos con Reaccionar y Vue. No son realmente frameworks; sólo representan la capa de vista de su aplicación. Significa que todas las otras partes — comunicación HTTP, validación de formulario, etc .— dependen de usted.
Como mencioné anteriormente, podría ser una espada de doble filo. Eventualmente, terminará construyendo su propio framework personalizado. Ambos tienen su ecosistema de bibliotecas para proporcionar soluciones a los problemas más comunes, pero la estructura general variará de un proyecto a otro.
El JSX de React siempre me hizo encogerme. Tenía que acostumbrarme a eso. Sin embargo, la creación de plantillas de Vue es realmente agradable, especialmente si vienes de Angular.
Por otro lado, Ember tiene casi todo. Sorprendentemente, el núcleo de Ember no proporciona procesamiento de formularios avanzado. Solo tiene algunos ayudantes de entrada y eso es todo. Es muy obstinado e incluso tiene su propia capa de datos. Todo tiene que hacerse “de la manera Ember”.
Si tienes antecedentes en otros frameworks o JavaScript en general, puedes sentirse frustrado porque Ember usa su propio modelo de objetos. Las clases estándar de ES2015 no se usan ampliamente, como lo indica su documentación. Puede encontrar que asigna el valor directamente a una propiedad y Ember se queja de ello.
Otra cosa significativamente diferente de otros frameworks es Ember Data. Es una capa de datos para aplicaciones Ember. Puedes pensarlo como algún tipo de ORM para el front-end. Usted crea modelos y mapea las relaciones entre ellos.
Ahora, si su servidor usa API JSON (es una especificación para implementar API JSON), se encuentra en un buen lugar con Ember, pero desafortunadamente, la mayoría de los servidores no. Por lo tanto, debe escribir adaptadores y serializadores personalizados. Sin embargo, si haces las cosas al estilo Ember, puede ser muy productivo. Simplemente tiene una curva de aprendizaje empinada.
Angular 2 es un framework rico en funciones. Se envía con muchos módulos como Ember, por lo que tiene un montón de herramientas a su disposición de la caja. Sin embargo, como Angular está destinado a aplicaciones de gran tamaño, promueve TypeScript, que podría desencadenar cierta resistencia antes de intentarlo.
Otra cosa notable es el uso intensivo de observables de la biblioteca Rx, que es realmente agradable. Puede representar casi cualquier cosa como observable y aplicar operaciones de alto nivel como mapa, filtro, etc. Si usó Lodash o Underscore, Rx es similar a los esteroides.
Aquí hay un resumen de las características principales de los cuatro frameworks que estamos discutiendo en este artículo:
Angular 2ReactEmberVue
View/Templating✔✔✔✔
Router✔✔✔✔
Form processing✔ ✔ 
Form validation✔   
HTTP communication✔ ✔ 
Todas esas características que resumimos brevemente son inútiles si necesita quemar la vela en ambos extremos para usarlas efectivamente, que es el siguiente punto.

Usabilidad

Si en este momento todavía tienes entusiasmo por el framework elegido, el siguiente paso es ensuciarse las manos.
Tal vez el framework es una buena opción para ti debido a tu formación. Tal vez es un poco diferente y te reta de alguna manera. Aún no lo sabes, y ninguna cantidad de tutoriales de lectura o observación lo ayudará hasta que lo pruebe ti mismo.
La mejor forma de familiarizarse con un framework es utilizarlo en algún mini proyecto. Esto te brinda la oportunidad de resolver problemas cotidianos mencionados anteriormente con un framework dado.
Mientras trabaja en un proyecto, tómese su tiempo y reflexione si está siendo productivo o no. ¿Qué tan fácil es lograr el resultado deseado? ¿Tienes que buscar bibliotecas externas? Tal vez necesites algunos complementos de la comunidad. ¿Hay alguna estructura o directrices convencionales dentro del contexto del framework? Tal vez haya una CLI para acelerar el proceso de desarrollo. En este paso, está reuniendo experiencia básica para que pueda pensar cómo sería si usa este framework para próximos proyectos o incluso transición de los existentes.
Ember se considera un framework muy productivo, al menos para sus usuarios principales. Viene con un CLI, que realmente ayuda. Puede generar rutas, controladores, componentes y modelos con sus propios conjuntos de prueba. Hacer todo eso manualmente es una tarea tediosa. Generar un nuevo proyecto también es posible. Creará la estructura de carpetas básica, instalará los paquetes necesarios, las herramientas de compilación, el entorno de prueba, etc. Si nunca ha utilizado una CLI en esa medida, estará muy satisfecho. Pero, como mencioné antes, Ember es muy obstinado; a pesar de toda esa bondad, puede encontrarse frustrado al tratar de realizar tareas comunes.
Ahora, para React y Vue, tienen algún tipo de CLI, create-react-app y vue-cli. Pero además de generar un proyecto inicial con algunas opciones, no ofrecen mucho en comparación con Ember o Angular. Es comprensible ya que ambos representan una capa de vista. Si le gustan los flujos de trabajo personalizados, la experimentación o las diferentes estructuras de proyecto a proyecto, entonces se encuentra en un buen lugar. Para algunos desarrolladores, la flexibilidad es la clave que inherentemente viene con el uso de React o Vue.
Angular 4 viene con un CLI como lo hace Ember. Puede generar componentes, directivas, servicios, etc. También genera la estructura inicial para una aplicación, por lo que solo debe preocuparse por el producto. El entorno de prueba es muy bueno ya que, con cada aplicación generada, el banco de pruebas vive cerca de él (literalmente). Además de eso, TypeScript podría proporcionar un impulso de productividad real. Este es el por qué:
¿Cuántas veces has encontrado el código con líneas como esta …
function doSomething(someData) {
    // do something
}
… y se preguntó qué diablos es ‘someData’, qué propiedades debería tener, qué funciones debería proporcionar y cuál es su comportamiento. Con TypeScript, usted define el tipo y espera los datos apropiados. Puede ir más allá si usa algún IDE con soporte de TypeScript. Puede explorar diferentes partes de la aplicación en un abrir y cerrar de ojos.
No hemos abordado los IDE pero, para la mayoría de los frameworks populares, existen algunos complementos que hacen que el desarrollo sea realmente fácil. WebStorm, por ejemplo, se envía con soporte integrado para Angular, React y Vue.

Facilidad de integración (con otras bibliotecas)

Por último, pero no menos importante, esto podría considerarse como parte de la usabilidad, pero es tan importante que merece su propia sección.
No importa qué tan rico en funciones tenga el framework seleccionado, es probable que se enfrenten a problemas donde se necesitan herramientas adicionales. Hay excelentes bibliotecas enfocándose en un problema, ya sea manipulación de DOM, procesamiento de datos, formateo de tiempo, edición de texto enriquecido, etc. Si intentas integrar una de ellas y dedicar horas cada vez, quizás esa no sea la mejor opción.
Probando esto es muy fácil. Puede encontrar rápidamente un escenario imaginario donde necesite una determinada biblioteca. Mira tus proyectos pasados; ¿Qué herramientas has estado usando y en qué escenarios? Lo más probable es que se encuentre nuevamente en las mismas situaciones y quiera estar preparado para eso, o al menos tener una expectativa.
No todas las bibliotecas admiten TypeScript. Como Angular lo usa en gran medida, algunas de las bondades de TypeScript podrían desaparecer al usar dicha biblioteca. Por supuesto, puede encontrar una solución, pero es un poco más complicada. Debido a la popularidad Angular, puede integrar las instrucciones en la página de la biblioteca en sí.
Para Vue y React, usted es responsable de casi todo, y el uso de otras bibliotecas no es una excepción. Si usa Webpack o una herramienta de compilación similar, puede consultar directamente las bibliotecas instaladas mediante NPM. Me parece un poco molesto para Vue el uso de complementos de la comunidad, especialmente cuando también contienen la lógica de la interfaz de usuario.
Ember tiene EmberObserver, que es un sitio web de complementos de la comunidad. Cada uno de ellos tiene un puntaje en una escala de cero a diez. Es un gran lugar para buscar algo que necesita. Si escribe el nombre de sus bibliotecas favoritas, como Lodash, Rx o Ramda, encontrará los complementos relacionados de envoltorios simples para completar las reescrituras. Por supuesto, hay repositorios Awesome React y Awesome Vue que reúnen recursos relacionados. incluyendo bibliotecas, pero encontré que EmberObserver es especialmente útil.

Comprometerse con un framework de JavaScript

Elegir el framework de JavaScript correcto es uno de los pasos más importantes para hacer que su proyecto web sea un éxito. Ya sea que esté trabajando en un proyecto pequeño o uno grande, ya sea que trabaje solo o en equipo, cada uno de estos detalles juega un papel crucial para determinar qué framework es el mejor para su proyecto (y menos de qué framework prefiere )
En cuanto a las características principales y la usabilidad, he enumerado los puntos que afectarán la productividad de los desarrolladores en diversos grados. La usabilidad es especialmente complicada porque depende en gran medida de su experiencia y antecedentes, así como de la empresa u organización en la que esté trabajando.
Con el tiempo, los frameworks que hemos discutido en este artículo pueden evolucionar, sus opiniones pueden cambiar y los proyectos para los que son adecuados pueden cambiar, pero este artículo debería brindarle una idea general de dónde cada uno de estos frameworks puede funcionar mejor.

lunes, 11 de septiembre de 2017

Init.js: Una guía de los Por Qué y Cómos en el conjunto de tecnologías de JavaScript View all articles

La Historia

Entonces, tú y tu cofundador tienen esta genial idea para un negocio, ¿verdad?
Has estado agregando características en tu cabeza.
Frecuentemente, le preguntas a tus potenciales clientes sus opiniones, y todos ellos la aman.
Ok, entonces la gente la quiere. Hay hasta un poco de dinero para hacer. Y la única razón por la cual ellos no pueden obtenerla es porque no las has implementado—todavía.
Entonces, finalmente, te sientas un día y dices “¡Hagámoslo!”. Pronto, estás tratando de averiguar cómo aplicar la lógica de negocio de tu aplicación, la funcionalidad asesina que va a llevar adelante al producto: tienes una idea de cómo hacerlo, y ahora sabes que puedes hacerlo.
“¡Listo!¡Funciona!” dices. ¡Tu prueba de concepto es un éxito! Todo lo que queda por hacer es empaquetarlo en una aplicación web.
“Ok, hagamos el sitio”, dices.
Y entonces, te das cuenta de la verdad: necesitas elegir un lenguaje de programación; necesitas elegir una plataforma (moderna); necesitas elegir algunos frameworks (modernos); necesitas configurar (y comprar) espacio, base de datos y proveedores de alojamiento; necesitas una interfaz de administración; necesitas un sistema de permisos; necesitas un administrador de contenidos.
Tienes que tomar decenas y decenas de decisiones de arquitectura . Y quieres tomar las correctas: quieres usar tecnologías que te permitan desarrollo rápido, iteración constante, máxima eficiencia, velocidad, robustez y más. Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir.
“Estoy abrumado”, dices, mientras te vas sintiendo abrumado. Tu energía no es la misma de antes. Tratas de encajar las piezas, pero es demasiado trabajo.
Tu prueba de concepto se marchita y muere lentamente.

La Propuesta

Luego de abandonar toneladas de ideas de esta forma, decidí diseñar una solución. La llamo el proyecto ‘Init’ (Inicio)(ó init.js).
El corazón de la idea es tener un simple proyecto que inicie todos los demás, dejar que el desarrollador o el fundador técnico tomen esas decisiones al mismo tiempo y recibir una plantilla apropiada para empezar basada en esas decisiones. Se lo que van a decir los detractores, “Una solución no puede aplicarse a todos los problemas” (Odiadores odiarán). Y puede que estén en lo cierto. Pero podemos hacer nuestro mejor esfuerzo para crear una solución aproximada, y creo que Init se acerca bastante.
Para lograr mejor este objetivo, tenemos que tener algunas ideas claves en mente. Cuando estaba desarrollando Init, consideré:
  • Componentes
    La modularización es una característica clave de cualquier sistema ya que te permite reusar componentes de software a través de distintos proyectos—lo cual es el principal objetivo de Init. Pero la modularización también viene con una “reemplazabilidad” por producto, la cual será nuestra mejor aliada a la hora de atacar varios tipos de problemas con “casi” la misma solución.
  • Facilidad de Desarrollo
    Para algunos problemas, en algún lado hay una mejor solución escrita en [Brainf*ck](https://en.wikipedia.org/wiki/Brainfuck). ó jodecerebros). Pero implementar esa solución (en Brainf*uck) sería casi imposible de escribir, y mucho menos de leer. Te costaría tiempo y una enorme cantidad de esfuerzo. En general, deberías usar lenguajes y plataformas que hagan al desarrollo fácil, y no difícil para tí (o alguien que puede trabajar con él más tarde).
  • Comunidad
    Cualquier plataforma que elijas, asegúrate que tenga una gran comunidad, y una que te pueda ayudar con los problemas más comunes y con los que no lo son tanto. Recuerda: jQuery puede no ser la librería más rápida, la más limpia, o la más elegante—pero es un ganador sólo por su comunidad.
Teniendo estos objetivos en mente, voy a mostrarte como hice mis propias decisiones al crear Init.
En su núcleo, Init se aprovecha del paradigma ‘full-stack JavaScript’ (algunas personas se refieren a él, o a una parte de él, como el MEAN Stack). Al trabajar con este conjunto, Init es capaz de usar solamente un sólo lenguaje mientras crea un ambiente increíblemente flexible y con todas las funciones para desarrollar aplicaciones web. En resumen, Init te permite usar JavaScript no solamente para desarrollo del lado cliente y servidor, pero también para construir, testear, maquetar, y más.
Pero bajemos un poco la velocidad y preguntémonos: ¿es realmente una buena idea usar JavaScript?

Por qué elegí JavaScript

Soy desarrollador web desde 1998. Por esas épocas usabamos Perl para la mayoría de nuestro desarrollo del lado del servidor, y aún desde esos tiempos teníamos JavaScript del lado del cliente. Las tecnologías web del lado servidor han cambiado inmensamente desde entonces: fuimos a través de oleada tras oleada de distintas tecnologías y lenguajes cómo PHP, ASP, JSP, .NET, Ruby, Python, solo por nombrar algunas. Los desarrolladores comenzaron a darse cuenta que usando dos distintos lenguajes para ambientes cliente y servidor estaba complicando las cosas. Los intentos iniciales para unificar bajo un mismo lenguaje intentaban crear componentes cliente del lado del servidor y compilarlos en JavaScript. Esto no funcionaba como se esperaba y muchos de esos proyectos fallaron (por ejemplo, ASP MVC reemplazando los formularios web de ASP.NET, y podría decirse que GWT será reemplazado por Polymer). en un futuro cercano). Pero era una excelente idea, en esencia: un lenguaje único en el cliente y el servidor, permitiéndonos reusar componentes y recursos (esta es la clave: recursos).
La respuesta era simple: usar JavaScript en el servidor.
De hecho, JavaScript nació con JavaScript Server Side en Netscape Enterprise Server, pero el lenguaje simplemente no estaba listo en esa época. Luego de años de prueba y error, Node.js finalmente emergió, lo cual no solo puso a JavaScript en el servidor, pero además promovió la idea de programación no-bloqueante, cambiando la forma en la que escribimos “fread”(I/O) para siempre (lee más aquí.
En una oración: la programación no-bloqueante apunta a poner tareas que consumen tiempo a un lado, usualmente especificando que se debería hacer una vez que estas tareas se hayan completado, y permitiendo que el procesador maneje otros pedidos mientras tanto.
Pero esas ideas no eran nuevas—entonces, ¿por que se volvieron tan populares con Node.js? Simple, la programación no-bloqueante puede ser alcanzada de distintas formas. Tal vez la más fácil es usar callbacks y un evento en bucle. En la mayoría de los lenguajes, esa no es una tarea fácil: mientras que los ‘callbacks’ son una característica común en algunos lenguajes, un evento en bucle no lo es y usualmente te encuentras aferrándote a librerías externas (por ejemplo: Python, con Tornado). Pero en JavaScript, los callbacks son construidos dentro del lenguaje, como también el evento en bucle, y casi cualquier programador que haya incursionado en JavaScript está familiarizado con ellos (o al menos los han usado, aunque no entiendan del todo que significa un evento en bucle). De repente, cada una de las startup en el Planeta Tierra podía reusar desarrolladores (por ej., recursos) tanto en el lado cliente cómo en el lado del servidor, resolviendo el problema de “Se necesita Gurú Python”.
Entonces, ahora tenemos una plataforma increíblemente rápida (gracias a la programación no-bloqueante) con un lenguaje de programación que es increíblemente fácil de usar (gracias a JavaScript). Pero, ¿Es suficiente? ¿Perdurará? Estoy seguro que JavaScript va a tener un importante lugar en el futuro. Déjame decirte por qué:
  • Programación Funcional
    JavaScript fue el primer lenguaje de programación que llevó el paradigma funcional a las masas (por supuesto, Lisp llegó primero, pero la mayoría de los desarrolladores nunca han construido una aplicación en Lisp lista para ser usada en producción). Lisp y Self, influencias principales de Javascript, están llenos de ideas innovadoras. Esas ideas pueden liberar nuestras mentes para explorar nuevas técnicas, patrones y paradigmas. Y todos ellos llevan a JavaScript. Mira monads, codificación Church, o incluso (para un ejemplo más práctico) la colección de funciones](http://underscorejs.org/#collections), de Underscore.js las cuales pueden salvarte líneas y líneas de código.
  • Objetos Dinámicos y herencia Prototipada
    La programación orientada a objetos sin clases (y sin las interminables herencias de clases) permite rápido desarrollo (crear objetos, agregar métodos y usarlos) pero, lo más importante, reduce el tiempo de refactorización durante tareas de mantenimiento dejando que el desarrollador modifique instancias de objetos en vez de clases. Esta velocidad y flexibilidad pavimenta el camino para el desarrollo rápido.
  • JavaScript es Internet
    JavaScript fue diseñado para Internet, ha estado aquí desde el principio, y no va a irse. Todos los intentos por destruirlo han fallado, mira, por ejemplo, la caída de los Applets Java, el reemplazo de VBScript de Microsoft, TypeScript (que compilaba a JavaScript), y la caída de Flash en manos del mercado móvil y HTML5. Es imposible reemplazar Javascript sin romper millones de páginas web, así que nuestro objetivo a largo plazo debería ser el de mejorarlo. Y no hay nadie mejor para esa tarea que el Technical Committee 39 de ECMA.
    Ok, alternativas a JavaScript nacen todos los días, cómo CoffeeScript, TypeScript, y los los millones de lenguajes que compilan a JavaScript. Esas alternativas pueden ser útiles para etapas de desarrollo (por medio de mapeos de código fuente), pero fallarán al tratar de suplantar JavaScript a largo plazo por dos razones: sus comunidades nunca serán más grandes, y sus mejores funcionalidades serán adoptadas por el script de ECMA (por ej., JavaScript). JavaScript no es como un lenguaje ensamblador: es un lenguaje de programación de alto nivel con código fuente que puedes entender—entonces deberías entenderlo.
Ahora, gracias al proyecto Esprima, puedes crear tus propias herramientas para jugar con el código fuente, modificándolo, cambiando su estilo, agregando comentarios, instrumentando, y todo de tipo de cosas que puedas imaginar al jugar con el Árbol de Sintaxis Abstracta de tu programa como si estuvieses jugando con un Árbol DOM.

JavaScript de extremo a extremo: Node.js y MongoDB

Entonces, esas son las razones para usar JavaScript. Ahora, voy a usar JavaScript como una razón para usar Node.js y MongoDB.
  • Node.js
    Node.js es una plataforma para construir aplicaciones de red rápidas y escalables—eso es básicamente lo que dice el sitio de Node.js. Pero Node.js es más que eso: es el entorno de ejecución preferido por cualquier aplicación con acceso de E/S en JavaScript. Incluso si no planeas escribir tu aplicación del servidor principal con Node.js, puedes usar herramientas creadas construidas encima de Node.js para mejorar tu proceso de desarrollo. Por ejemplo: Mocha.js para unit testing, Grunt.jspara tareas de construcción automatizadas, o incluso Brackets para completar edición de código.
    Entonces, si vas a escribir aplicaciones de JavaScript para servidor o cliente, deberías familiarizarte con Node.js, porque vas a necesitar usarlo diariamente. Hay algunas interesantes alternativas), pero ninguna de ellas llega siquiera al 10% de la comunidad de Node.js.
  • MongoDB
    MongoDB es una base de datos NoSQL basada en documentos que usan JavaScript como su lenguaje de consultas, permitiendo completar de extremo-a-extremo la plataforma JavaScript. Pero esa no es siquiera la razón principal para elegir esta base de datos.
    MongoDB es una base de datos sin esquema que permite persistir tus objetos de una manera flexible y por lo tanto adaptarse más rápidamente a los cambios en los requisitos. Además, es altamente escalable y basado en map-reduce, lo cual lo hace adecuado para aplicaciones con muchos datos. MongoDB es tan flexible que puede ser usado como una base de datos de documentos sin esquema, un almacén de datos relacional (aunque le faltan transacciones),o incluso almacenamiento de clave-valor para respuestas de caché.

Modularización de Servidor con Express.js

Modularización en el lado del servidor nunca es fácil. Pero con Express.js (y Connect.js) vino la idea de ‘middleware’(ó software intermedio). En mi opinión, middleware es la mejor forma de definir componentes en el servidor. Si quieres compararlo con un patrón conocido, se acerca bastante a los tubos y filtros.
La idea básica es que tu componente es parte de una tubería. La tubería procesa el pedido (entrada) y genera una respuesta (salida), pero tu componente no es responsable por la respuesta completa. En cambio, solo modifica lo que necesita y luego delega hacia la otra pieza de la tubería. Cuando la última pieza de la tubería termina su proceso, la respuesta se envía al cliente.
Nos referimos a estas ‘piezas de tubería’ como ‘middleware’. Claramente, podemos crear dos tipos de middleware:
  • Intermedios: Esos que procesan el pedido y la respuesta, pero no son del todo responsables por la respuesta en sí, entonces delegan al siguiente middleware.
  • Finales: Esos que toman la responsabilidad por completo en la respuesta final. Ellos procesan y modifican el pedido y la respuesta, pero no necesitan delegar al siguiente middleware. En la práctica, se recomienda que delegues a un siguiente middleware, de todas maneras, para permitir flexibilidad en la arquitectura (por ej., agregar más middleware después), aunque ese middleware no exista (en ese caso la respuesta irá directamente al cliente)
Como ejemplo concreto, considera un componente ‘usuario administrador’ en el servidor. En términos de middleware, tendríamos tanto finales como intermediarios. Para nuestros finales, tendríamos características tales como crear un usuario y listar usuarios. Pero antes que podamos realizar esas acciones, necesitamos nuestros intermediarios para autenticación (ya que no queremos pedidos que creen usuarios sin autenticar). Una vez que creamos estos intermediarios para autenticación, podemos simplemente conectarlos en cualquier lado que queramos para convertir una característica sin autenticación existente en una con autenticación.

Aplicaciones de una sóla página

El proyecto Init enfoca en crear aplicaciones de una sóla página (SPAs-Single-Page Applications). Muchos desarrolladores web se han tentado más de una vez en probar construir SPAs. Desarrollé usando varias (principalmente propietarias), y puedo decir con confianza que son simplemente el futuro de las aplicaciones web. ¿Alguna vez comparaste una SPA con una aplicación web regular en una conexión móvil? La diferencia de respuesta es de decenas de segundos.
Las SPA son el futuro de la web—¿entonces por que harías tu producto en un formulario antiguo? Un argumento común que escucho es que la gente está preocupada por el SEO. Pero si manejas las cosas correctamente, esto no debería ser un problema: Google mismo tiene un muy buen tutorial sobre como hacerlo, y hay muy buenos comentarios aquí también.

MV* del lado del cliente con Backbone.js, Marionette.js y Twitter Bootstrap

Mucho se ha dicho acerca de los MVC* frameworks para SPAs. Es una decisión complicada, pero voy a decir que el top 3 son Backbone.js, Ember.js, y Angular.js.
Los tres son bien considerados. ¿Pero cual de ellos es el mejor para tí?
Desafortunadamente, tengo que admitir que tengo una experiencia muy limitada con Angular.js, así que voy a dejarlo fuera de esta discusión. Ahora, Ember.js y Backbone.js representan dos maneras distintas de atacar el mismo problema.
Backbone.js es minimalista, simplista y te ofrece lo suficiente para crear una simple SPA. Por otro lado, Ember.js es un framework completamente profesional para crear SPAs. Tiene más adornos, pero también una curva de aprendizaje más grande.
Dependiendo del tamaño de tu aplicación, la decisión puede ser tan fácil como mirar el ratio de featuresUsed/featuresAvailable(características Usadas/Disponibles), lo cual te dará una gran pista.
En el caso de Init, quería cubrir la mayoría de los escenarios, así que elegí Backbone.js para creación fácil de SPAs, con Backbone.Marionette.View para modularización. De esta forma, cada componente es una simple aplicación, y la aplicación final puede ser tan compleja como queramos que sea.
Estilizar es también un desafío, pero podemos, de vuelta, contar con frameworks para rescatarnos. Para CSS, no hay nada mejor que Twitter Bootstrap, que ofrece un completo set de estilos que ya están listos para usar y son fáciles de personalizar.
Booststrap fue creado usando el lenguaje LESS que es de código abierto, así que podemos modificarlo si así lo necesitasemos. Viene con una tonelada de controles de usabilidad que están bien documentados en el sitio de Bootstrap. Además, hay un modelo de personalización que te permite crear tus propios controles. Definitivamente es el hombre para este trabajo.

Mejores prácticas: Grunt.js, Mocha.js, Chai.js, RequireJS y CoverJS

Finalmente, deberíamos definir algunas de nuestras mejores prácticas, y buscar en como Init puede ayudarte a implementarlas y mantenerlas. Nuestra solución está centrada en varias herramientas, que están basadas en Node.js.
  • Mocha.js and Chai.js:
    Estas herramientas te permiten mejorar tu proceso de desarrollo aplicando TDD o BDD, proveyendo la infraestructura para organizar tus tests unitarios y un lanzador para correrlos automáticamente.
    Hay miles de frameworks para test unitarios para JavaScript. ¿Entonces, por que usar Mocha.js? La respuesta corta: es flexible y completo.
    La respuesta larga: tiene dos características importantes (interfaces, reporters) y una ausencia importante (assertions). Déjenme explicarles.
    • Interfaces: tal vez estés acostumbrado a los conceptos de TDD de suites y tests unitarios, o tal vez prefieras ideas BDD de especificaciones de comportamiento con “describe” y “it should”. Mocha.js te permite usar los dos acercamientos.
    • Reporters: correr tu test generará reportes de resultados, y puedes darle formato a esos resultados usando varios reporters. Por ejemplo, si tienes que alimentar un servidor de Integración Continua, puedes encontrar un reporter para hacer exactamente eso.
    • Falta de una librería de assertions: : lejos de ser un problema, Mocha.js fue diseñado para dejarte usar la librería de assertions que prefieras, ofreciendo más flexibilidad. Hay muchas opciones, pero ahí es donde Chai.js entra en acción.
    Chai.js es una librería de assertions flexible que permite usar cualquiera de los tres más importantes estilos de assertions:
    • Assert: Estilo de assertion clásico de la vieja escuela. Ej.:
        assert.equal(variable, ”valor”);  
      
    • Expect: Tipo de assertion encadenable más comúnmente usado en BDD. Ej.:
        expect(variable).to.equal(“valor”);
      
    • Should: También usado en BDD, pero prefiero Expect porque Should porque suena repetitivo con la especificación de comportamiento _’it _(“should do something..”-” eso debería hacer algo”). Ej.:
        variable.should.equal(“valor”);
      
    Chai.js se combina perfectamente con Mocha.js. Usando solamente estas dos librerías, puedes escribir tus test en TDD, BDD, o cualquier estilo imaginable.
  • Grunt.js:
    Grunt.js permite automatizar tareas de construcción, cualquier cosa desde simples archivos concatenados copiados y pegados, a plantillas precompiladas, estilo compilado de lenguaje (por ej., SASS y LESS), test unitario (con mocha.js), linting y compresión de código (ej., con UglifyJS o Closure Compiler). Puedes agregar tu propia tarea automatizada a Grunt, o buscar en el registro de Grunt, donde hay cientos y cientos de plugins disponibles (de vuelta, usando herramientas con grandes comunidades detrás paga bien). Grunt también puede monitorear tus archivos y disparar acciones cuando estos son modificados.
  • RequireJS:
    RequireJS puede sonar como otra forma de cargar modulos con AMD, pero puedo asegurarte que es mucho más que eso. Para entender por qué, primero debemos mencionar la idea del namespacing de modulos (ej., demo.views.hola), lo que evita contaminar el namespace global envolviendo cada módulo en su propio namespace. El problema es, estos módulos no son reusables: si modificas el namespace de una ‘instancia’, estás modificando el namespace de todas las ‘instancias’. En contraste con eso, RequireJS permite definir módulos reusables desde el principio. (Además, te ayudará a adoptar Dependency Injection para evitar que tus modulos accedan variables globales).
  • CoverJS:
    Cobertura de código es una medida métrica para evaluar tu testing. Como el nombre implica, te dice cuanto código está cubierto en tu conjunto de tests actual. CoverJS mide la cobertura de código de tus tests instrumentando declaraciones (en vez de líneas de código cómo JSCoverage) y generando una versión instrumentada de tu código. También genera reportes para alimentar tu servidor de integración continua.

Usando _Branches_ (_ramas_) para alternar características

Cuando empecé Init, necesitaba una manera para que los usuarios activen y desactiven varias características que podrían llegar a querer en su proyecto. Decidí tomar un enfoque radical con el sistema de ramas de git para implementar esta funcionalidad.
En esencia, cada rama representa una característica o funcionalidad que un usuario podría querer incluir. Si estás empezando un proyecto desde el principio, empieza por la rama mínima que necesitas, y luego agrega otras tecnologías fusionando la rama con las otras deseadas. Por ejemplo, digamos que quieres empezar tu proyecto con Backbone.js y Marionette.js. Bueno, puedes empezar en la rama Backbone.js y fusionarla con la rama Marionette, continuando desde ahí para cada pedazo de funcionalidad que quieras agregar.
Por ahora, la idea de fusionar para agregar funcionalidad puede solo ser usada para plantillas de tecnología (ej., Backbone, Node, Express). Pero en el futuro, serás capaz de alternar entre back-end (ej., desde MongoDB a Postgres) e implementaciones del lado cliente.

Empieza un proyecto con Init y haz un deploy en Heroku hoy

Nunca ha habido una manera más fácil de empezar un proyecto. Dirígete al repositorio de GitHub, fijate la rama con los últimos commits (ahora mismo es usermanager, aunque esto puede cambiar en el futuro) y entonces:
  1. Crea un directorio para tu proyecto (o usa uno existente).
  2. Crea tu repositorio con “git init” (o usa un repositorio existente)
  3. Agrega un servidor remoto con Init
     git remote add init git: //github.com/picanteverde/init.git
    
  4. Descarga la rama que quieras
    git pull init usermanager
    
  5. Obtén el archivo de procesos de Heroku
     git pull init heroku-webprocess
    
  6. Con el Heroku Toolbelt instalado, crea una aplicación
     heroku create
    
  7. Haz un push a la rama master a Heroku
     git push heroku master
    
  8. Visita tu aplicación en funcionamiento en Heroku!
Ahora puedes empezar a desarrollar tu característica asesina con solo unas líneas de código. No solo eso, sino que estarás desarrollando con las últimas y más eficientes tecnologías en una suite de desarrollo lo más automatizada posible.
Espero que puedas usar Init para comenzar tu próxima gran idea. Recuerda Revisar el repositorio de Init para ver correcciones y características—su desarrollo es bastante activo, y espero con ansias escuchar sus comentarios.

Contenido traducido por Pablo Fabregat, miembro de TransBunko, un mercado de traducciones técnicas.
Este articulo fue escrito por Alejandro Hernandez. Originalmente publicado en Toptal.