El origen de Bootstrap, el framework CSS líder

Hace unos días me daba vueltas en la cabeza quiénes eran las personas que desarrollaron Bootstrap, este framework tan amigable (que a muchos nos ha aliviado en más de un par de ocasiones), me hacía preguntas como ¿son personas normales? ¿dónde viven? y ¿qué otras cosas hacen? por este y otros cuestionamientos más, hoy me dí a la tarea de investigar y este fue el resultado de mi investigación.

Bootstrap fue desarrollado por Mark Otto (@mdo) y Jacob Thornton (@fat) desarrolladores del famosísimo Twitter, proveedor de servicios de microblogueo.

¿Pero quiénes son Mark Otto y Jacob Thornton?

Mark Otto es un diseñador viviendo y trabajando en San Francisco, trabajó como freelance durante la secundaria y la universidad, antes de mudarse a California para trabajar en la empresa de diseño ZURB, en 2007.

Durante su estancia en ZURB diseñó y desarrolló docenas de proyectos con grandes y pequeños clientes, incluido un sitio web para Britney Spears -¡Cool! – .

Después de un periodo de dos años y medio en ZURB, renunció para comenzar a trabajar en Twitter como diseñador de productos.

En Twitter trabajó en numerosos proyectos y varias herramientas internas, ahí fue donde creó el popular kit de herramientas para front-end de código abierto Bootstrap con ayuda del buen Jacob Thornton.

Bootstrap nació en Twitter como un medio para crear mejores herramientas internas, comenzó como algo simple de HTML/CSS, luego Jacob construyó complementos encima y así es como comenzó “Bootstrap de Twitter” llamado así originalmente.

Bootstrap es un framework de código abierto para diseño de sitios y aplicaciones web. Entre sus herramientas contiene una gran variedad de plantillas de diseño con tipografía, botones, menús de navegación, tarjetas y otros elementos de diseño basado en HTML y CSS, así como también extensiones de JavaScript.

Hasta la fecha Otto y Jacob han puesto más de 1000 horas en Bootstrap, sino es que más. Semanalmente trabajan de tiempo completo en sus respectivos empleos, pero suelen realizar esfuerzos durante algunas horas por la noche y más los fines de semana, esto quiere decir que ellos no trabajan de tiempo completo en Bootstrap.

Actualmente Otto se desempeña como Director Principal de Diseño en GitHub, administra un equipo de aproximadamente 25 diseñadores web, ingenieros y artistas.

Por su parte Jacob Thornton es cofundador de Bumpers (aplicación de podcasting). Trabajó en Medium y Twitter, dondé junto a Otto creó Bootstrap.

Jacob hace un tiempo solía mantener un blog, donde escribía una serie de artículos de filosofía, sociología, teoría crítica y tecnología, donde abordó diferentes temas “con los que estaba luchando en ese momento”.

Jacob en particular tiene ideas que dan vueltas en su cabeza como ¿los robots o la inteligencia artificial se volverán demasiado inteligentes y tomarán el control? ¿ya vivimos en una realidad virtual? y cuestiones como “necesitamos colonizar Marte, o de lo contrario nos vamos a extinguir” y temas por las que la gente como él está obsesionada.

Jacob dice que no se deprime demasiado por este tipo de aspectos humanistas, pero sí es juicioso al respecto y tiene la tendencia a enloquecer al respecto.

Él es una persona muy filosófica y de ideas futuristas, sufre de alergias y le encantaría tener un ‘gato robótico’, y que no estaría nada preocupado si su gato intentara atacarlo.

Soy alguien que realmente quiere que haya destinos y experiencias radicales, únicas y diferentes, especialmente en Internet.

Bootstrap 4

Finalmente, Bootstrap es un proyecto que recientemente se ha actualizado a su versión 4, añadiendo diversas funcionalidades y mejoras, las cuales les invito a conocer en un muy entretenido y amigable curso impartido por nuestro amigo Alex Arriaga donde serás testigo de la genialidad de estos dos personajes.

https://webtraining.zone/cursos/curso-profesional-de-bootstrap-4

Conclusión general

Creo que Otto y Jacob son personas como tu y como yo, que con el esfuerzo y dedicación de su día a día han logrado proyectos muy interesantes e innovadores.

Así que sigamos trabajando todos los días “pasito a pasito” y así poco a poquito alcanzaremos y construiremos cosas más grandes y mejores para bien de todos.

Corre tras tus sueños…

Truco de Vue.js #2: Quiero usar Vue.js en un proyecto grande y viejo.

Tenemos el siguiente escenario: Eres el nuevo miembro de un equipo de desarrollo que lleva unos años perfeccionando una aplicación Web. Dicha app está hecha con tecnologías como .NET y usa jQuery a todo lo que da. Tu primera tarea es “arreglar” el sistema de comentarios pero al analizarlo por un rato descubres cosas como esta:

$('#comment-' + commentId2)
  .toggleClass('comment-state-02')
  .css('display', displayFlag);

Intentas sacarle explicación a cada variable, clase y ID para medio comprender qué están tratando de lograr. Te ves en 2 meses arreglando el parche que arregló el parche que arregló el parche, te deprimes y luego te armas de valor y propones rehacer el módulo.

Y para tu sorpresa… ¡TE LO ACEPTAN! Es tu momento de meterle tecnología de punta que no solo sea novedosa sino eficiente. ¿Pero qué puedo usar que sea eficiente y al mismo tiempo fácil de integrar? OJO: Fácil de integrar es que al meterlo al proyecto no te rompa todo y tome días ajustarlo. Mi sugerencia es obviamente Vue.js.

¿No te convence? Considera que añadir solamente 32kb al proyecto acelerará tu productividad y mantendrá un buen nivel de escalabilidad si creas una abstracción de componentes decente. ¿Qué piensas ahora?

¡Acepto! ¿Cómo empiezo?

Importar el script de Vue.js, sea por CDN o guardando el archivo en el proyecto, es sumamente fácil. Considero que es algo que podemos saltarnos en este post, pero te dejo el link de la documentación oficial aquí.

Ahora, siendo un curioso de la web que conoce Vue.js, sabrás que trabajar con componentes es lo ideal. Y dividir la lógica de cada uno en un archivo con extensión .vue es la cereza del pastel. Sin embargo, el proyecto al que te enfrentas no usa Webpack y, honestamente, integrar Webpack en un proyecto que no se pensó desde un principio con él es una lata. Y tú, siendo el nuevo que ya convenció al Project Manager de usar Vue.js, debes entregar resultados ASAP.

Dale, no pasa nada. Afortunadamente Vue.js tiene más de una manera para declarar un entorno de componentes. En un escenario como este yo te sugiero estas dos formas:

  1. Declaración con strings inline.
  2. Declaración con X-Templates.

Preparación

Checa el repositorio que preparé para ti: https://github.com/enriqued93/truco-vue-2. La rama master contiene el ejemplo para la declaración con strings inline, y la rama x-templates para el segundo ejemplo.

En este repositorio están los pasos necesarios para integrar Vue.js en cualquier proyecto de manera segura. Hay comentarios suficientes dentro del código para comprender qué está sucediendo, así que te recomiendo fuertemente que le des un vistazo.

En el archivo comments.module.js está la definición e inicialización del widget de comentarios y sus componentes. Mi enfoque se basa en definir funciones descriptoras cuyo único fin es devolver objetos con la estructura especificada para un componente de Vue.js.

¿Por qué usar este tipo de funciones y no escribir el objeto inline? En mi humilde opinión, englobar dichos objetos de esta manera ayuda a tener un código más limpio y estructurado. Si estamos trabajando con una herramienta que promueve el uso de componentes, debemos estar consientes de que tener una estructura mantenible y reusable es primordial. Otra ventaja es que si tienes la necesidad de utilizar un componente en otro lado, puedes copiar y llevarte la función completa y no se romperá absolutamente nada ya que la función descriptora debe ser ajena al contexto donde se define.

Declaración con strings inline

Quizá sea la manera más simple de definir un componente en Vue.js. Primero te dejo algunas ventajas y desventajas de este método.

Ventajas

  • Como desarrollador, es imposible perder referencia visual entre lógica y template del componente, pues se encuentran en el mismo sitio.
  • Al mover la declaración de lugar (posiblemente a otro archivo) el componente no se romperá ya que está todo en el mismo objeto.
  • Los problemas que surgen por ejecutar JavaScript antes de tener listo el DOM no te afectarán por declarar este componente porque el template que necesita viene integrado.

Desventajas

  • Como el template se está definiendo como un string, te será muy dificil escribir un componente muy grande.
  • La mayoría de los IDEs (o tal vez todos) tratarán el template como un vil y plano string, omitiendo cualquier tipo de Syntax Highlighting.
  • Para escribir un string multilinea puedes usar las Templates Literals de EcmaScript2015, pero dado que existen navegadores que no implementan esta especificación es un poco arriesgado usarla (a menos que tus requerimientos no incluyan este tipo de navegadores).

Enfoque

Si has usado el framework sabrás que debemos crear un objeto que funja como “descriptor” de nuestro componente y que tiene una estructura como te muestro acontinuación:

{
  template: ...,
  data: ...,
  methods: ...,
  computed: ...
}

Existen ciertas consideraciones que debemos tener en cuenta respecto a este objeto, pero por ahora solo me estoy enfocando en la propiedad template por el alcance de este post.

En el repositorio que te compartí encontrarás que defino el template de los componentes de manera inline, es decir, el HTML con directivas de Vue.js es un string asignado a la propiedad template del objeto descriptor. Este string lo defino usando sintásis diferentes para que de acuerdo a tus gustos o requerimientos uses la que más te acomode. Recuerda que las Template Literals no son soportadas por todos los navegadores (checa la compatibilidad actualizada aquí).

function getCommentListDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['comments'],
        components: {
            'comment': getCommentDescriptor()
        },
        template: `
            <div class="wt-comment-list">
                <comment v-for="c of comments" :key="c.id" :model="c"></comment>
            </div>
        `
    }
}

function getCommentEditorDescriptor() {
    return {
        data: function () {
            return {}
        },
        template: '<div class="wt-comment-editor"><textarea class="wt-comment-editor__input" placeholder="Escribe algo..."></textarea><button class="wt-comment-editor__button" type="button">Enviar</button></div>'
    }
}

Declaración con X-Templates

Bueno, pero entonces ¿debo tener forzosamente mis archivos JavaScript con todos esos strings que tienen una sintáxis más parecida a HTML? La respuesta es NO.

Ventajas

  • Ciertos IDEs pueden ayudarte con Syntax Highlighting ya que el template se encuentra en un archivo HTML.
  • Resuelve el impedimento de los templates multilinea.
  • Si creamos un componente con un template muy extenso, el código se aligera visualmente al quitarlo del descriptor.

Desventajas

  • Si no tenemos cuidado y olvidamos incluir los X-Templates en el contexto, el componente no encontrará su respectivo template y explotará.
  • Si el componente se inicializa antes de tener listo su respectivo X-Template dentro del DOM, también explotará.

Enfoque

Hagámosle unos cambios al ejemplo anterior. En lugar de tener los templates en nuestro JavaScript, lo moveremos al HTML de la siguiente manera.

<script type="text/x-template" id="vue-comment-template">
    <div class="wt-comment">
        <p class="wt-comment__subject">{{model.subject}}</p>
        <p class="wt-comment__body">{{model.body}}</p>
    </div>
</script>

El punto clave es englobar el template en un <script> con la propiedad type=”text/x-template”. El ID del script reemplazará al template inline del ejercicio pasado.

function getCommentDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['model'],
        template: '#vue-comment-template'
    }
}

No olvides que para que la inicialización de un componente se lleve a cabo adecuadamente, es necesario que el X-Template en cuestión exista en el DOM en dicho momento. Puedes usar $(document).ready() o la estrategia que prefieras para asegurar que el JavaScript se corra cuando el DOM se haya cargado (en el repositorio encontrarás una estrategia usando solamente JavaScript por si has superado jQuery).

Conclusión

En mi humilde opinión, establecer una buena abstracción y arquitectura de componentes en tu aplicación es primordial. Si lo haces no importará si tu app debe seguir creciendo pues soportará nuevas funcionalidades (escalabilidad); arreglar bugs dejará de ser tarea de andar descifrando código ajeno (mantenibilidad).

Si usas Vue.js o estás considerando en usarlo, aprovecha todas las bondades que ofrece y sácale todo el jugo. Recuerda que puedes tener el mejor framework del mundo pero si no lo usas como se debe no hará ninguna diferencia.

Ojalá esto te sea útil y no olvides dejarme tus comentarios diciendo qué cosas te interesarían aprender, cómo te pareció este post o qué opinas de mi escritura. Te mando un saludo, nos leemos en el próximo post.

– Enrique D.

 

 

¿Por qué se sigue usando Java?

Hoy recibimos una pregunta muy interesante de uno de nuestros webtrainees desde Youtube, sobre por qué Java aunque es un lenguaje que parece “antiguo”, sigue siendo uno de los que recomendamos aprender en Webtraining.Zone. Aquí está parte de la pregunta:

Necesito ayuda,…, nunca programé en Java, mas bien fui formado en frontend, me incliné fuertemente por la programación funcional: manejo Haskell, Rust, PureScript y Elm. Siempre me gusto la programación, pero…

Java siempre me ha parecido un lenguaje feo y tortuoso, lo siento mi idea no es ofender, el hecho de no tener inferencia de tipos, tener que crear clases para todo e incluso tener que manejar estado dentro de una clase me resulta raro, extraño o no natural.

Quiero saber por qué me parece terrible tener que trabajar con Java, y siempre que empiezo proyectos intento evadirlo, tal que argumento con las estadísticas StackOver Flow para demostrar que esta siendo relegado. Quiero que alguien pro como Alex me de su punto de vista.

Mil gracias.

Primero que nada quisiera comentarte que Java es un lenguaje que al ser un predecesor de todos los lenguajes que mencionas, definitivamente no tiene todas las características “modernas” para hacer desarrollos a los que estás tienes acceso con lenguajes como Rust.

Ahora bien Java no es funcional por lo tanto no podemos hacer cosas usando ese paradigma al estilo de Haskell, en todo caso Scala sería un competidor para éste (entonces ahí la comparativa tomaría otra vertiente).

Java no es sólo un lenguage

Cuando hablamos de Java, no sólo se toma en cuenta el lenguaje en sí, sino todo el ecosistema que tiene a su alrededor, sólo por darte un ejemplo: en el mundo empresarial (aplicaciones de alta demanda y muy distribuidas como las que usan los bancos, los grandes corporativos y los gobiernos) el lenguaje predominante es Java, y eso es gracias que muchos de los frameworks y productos más poderosos están creados con Java.

Tal es el caso por ejemplo de los servidores de aplicaciones como IBM WebSphere, JBoss (RedHat), Weblogic (Oracle). Plataformas de creación de contenido como IBM Web Content Manager, Liferay DXP también están construidas sobre Java.

Mientras empresas como IBM, Oracle, Amazon y Google, sigan creando productos empresariales en Java, es muy difícil que otra plataforma se posicione a su nivel.

Ingeniero de Software vs Arquitecto

Es cierto, como Ingenieros de Software nos gustan los lenguajes nuevos y brillantes, pero… como Arquitectos de Soluciones vemos más allá del lenguaje:

  • Vemos quién da mejor soporte,
  • Quién tiene más madurez en herramientas,
  • Qué tan complejo es encontrar profesionales con conocimientos avanzados,
  • Qué tantas empresas pueden implementar sistemas en tal o cual lenguaje,
  • Cuánto nos costaría mantener nuestras aplicaciones,
  • Qué tan riesgoso es elegir tal o cual tecnología,
  • Quién va a pagar el costo de los errores de producción cuando se presenten.

Haciendo la suma de todos los puntos anteriores, la verdad es que la lista de dónde podemos elegir se limita a dos plataformas: .NET de Microsoft o Java de Oracle, no hay más.

Los otros lenguajes se pueden usar para proyectos de otra naturaleza, pero no para el mundo de aplicaciones empresariales, donde una mala decisión puede costar millones de dólares o una buena decisión puede ahorrarlos.

Una decisión de millones

Ahora mismo, estoy involucrado en un proyecto de un gobierno de uno de los países más poderosos del mundo, y ahí por ejemplo este tipo de decisiones de arquitectura son decisiones que repercutirán por al menos 5 años.

Imagínate… 5 años es un tiempo muy largo en software, que cuando se tiene una buena base esos 5 años pueden ser muy productivos. O bien estos cinco años pueden ser de muchas pérdidas.

¿Y tu qué piensas sobre Java?

Te gustaría aprender otras cosas interesantes, qué tal sobre Los 10 mandamientos de un buen Ingeniero de Software.

Saludos cordiales.