Frontend Developer Learning Roadmap, porque seguro que en algún momento todos hemos empezado
alguna vez y la duda era, bueno, ¿por dónde empiezo? ¿Qué tengo que aprender? ¿Y por
dónde debería ir creciendo? Entonces me parece muy interesante esta página porque de esta
forma podemos ver en qué punto estamos, por dónde podemos tirar, podemos ir evolucionando.
Así que si os parece, creo, no sé cómo va esto, pero pone read now, vale, no sé si,
ah, vale, es que es cuando le das un clic, entiendo que, no, uno es aquí, vale, además cuando le das un
clic, fíjate que te lo explica todo, todo, todo, todo, es brutal, lo que estaría genial es poder hacer un
zoom, ¿no? Ah, vale, es que el zoom se hace con el, qué bueno, vale, vale, ahora genial, vale, pues esto
sería el comienzo, ¿no? The Frontend Developer Learning Roadmap, y le puedes dar clic y te explica cada uno
de los roadmaps. Esta sería un poco la profesión, The Frontend Developer Profession, estos serán los
topics, overview of the, esto sé, si le das, pues te explica este trozo, ¿no? Y te dice, bueno, ¿qué hace un
Frontend Developer? Cada vez más cosas. No conocía esta, DeskGap, esta no la conocía, no sé si todavía
sigue teniendo esto relevancia o es nuevo, no lo conocía para nada, pero entiendo que es para hacer
aplicaciones de escritorio. Con HTML es como un electrón, yo no lo conocía, lo desconocía totalmente,
pero lo he visto antes y he dicho, ostras, pues me gustaría saber exactamente qué es. Vale, si volvemos
para atrás, vamos a ver por dónde van los tiros, porque aquí veis las flechas que te dicen para
dónde tienes que tirar. Entonces, ¿cómo conseguir un trabajo de Frontend? Vale, pues lo que tendrías que
tener, las comunidades, cómo encontrar trabajo y todo esto. Luego estaría más el overview un poco de
qué se trata, los tópicos que tiene un Frontend Developer. Luego, aquí ya vamos empezando a qué es lo que
tenemos que ir aprendiendo, ¿no? Aquí, por ejemplo, tenemos las mecánicas básicas de la World Wide Web.
Pues Internet, TCP, los protocolos IP, DNS, HTTP, luego HTTP y WebSockets. La verdad es que me sorprende WebSockets
aquí de una, pero bueno. Luego la plataforma web, conocer la plataforma de la app y de la web, los editores de código.
Me parece que es muy, algunas cosas es como que, no sé si es como de cero a, ¿sabes? El principio especialmente
me parece que se salta algunas cosas, pero bueno, es mi opinión, ¿eh? Porque, por ejemplo, editor de código
me parece algo muy básico antes de ponerte a poner esto. Desarrollando para browsers, web platform APIs.
Bueno, luego HTML, por supuesto. Y aquí es donde ya empieza un poco a poner algunas flechitas ya de más.
Esto, SEO. SEO yo también lo vería más adelante, porque bueno, si es verdad que puede ser interesante
barget y tal. Fundamentos de las imágenes, accesibilidad, luego CSS. Esto es CSS, CSS fuentes, layout, media queries.
Y aquí otra vez, más flechitas. Fíjate, de CSS, pues ya te dice esto de HTML e-mails, que esto muchas veces
la gente no le da mucha importancia. Y si quieres buscar trabajo en un marketing digital, en cosas así,
el maquetar e-mails es brutal. Brutal. Te da muchísimo, muchísimo trabajo. Sobre todo si estás en una agencia
que tiene muchos clientes y hacen este tipo de trabajo. Pero bueno, ya veis que queda aquí en una esquinita.
Así que, bueno, luego arquitectura de CSS. Y del CSS pasa a JavaScript. A mí hay... Mucha gente me pregunta
muchas veces, oye, ¿qué debería aprender primero? ¿Debería aprender JavaScript o debería aprender HTML y CSS?
Y yo creo que hay dos caminos que son muy interesantes. Uno, si te quieres enfocar más en la parte
de programación, pues podrías empezar con JavaScript directamente. Empezarías con Node, eso sí.
Y entonces, pues te enfocarías a JavaScript puro y duro. Y luego, quizás, podrías pasar a HTML y CSS.
Podría ser un camino. Luego, si lo que quieres es un desarrollo web más clásico, sí que entonces lo mejor sería
HTML y CSS y luego JavaScript. Aquí, de nuevo, tienes una flechita aquí que dice,
bueno, si quieres te miran las Regex y si no, sigue pa'lante. Las Regex, al final, yo creo que nunca terminamos
de... Nunca terminamos de aprenderlas. Sí, también me conozco esta de Roadmap, ¿eh? La de Roadmap SH, o sea, esta es mítica.
Es mítica. Lo que pasa es que lo interesante es que la de Roadmap está muy bien, pero también es verdad que tiene mucho
menos contenido. O sea, por ejemplo, vale, pone HTML, pone
accesibilidad a SEO Basics. Esta de Roadmap, yo creo que la han utilizado un poco
de... Como de guía para esta. Y la de Roadmap hay gente que la ha tomado
como referencia y ha dicho, mira, esto es lo que tienes que hacer y ya está. Pero lo que me gusta
mucho es que, mira, cuando tú estás aquí, por ejemplo,
HTML e-mails, y le das un click, pues
están trabajando en ello todavía. Pero tienes aquí un montón de contenido donde te irán
diciendo, mira, para aprender esto, pues HTML e-mail development. Y, ¿ves? Vas a tener
enlaces para poder explorar esto que quieres aprender. Pues mira, herramientas
MJML, que este es un framework para hacer maquetación de e-mails súper interesante,
muy chulo, que es como... Parecen como Web Components o Custom Elements.
Y está muy bien. Eso es una cosa que yo le he hecho en falta a la de Roadmap SH, ¿no?
Está guay, está genial. A mí me gusta mucho el dibujito, está muy bien.
Y aquí hay resources. Es verdad que tienes esto, pero, hombre, es mucho
menos completo. Este, aunque están trabajando en ello, me da la sensación
que a la larga, no sé, por ejemplo, si vamos a... Bueno, hemos visto este
HTML e-mails. Vamos, por ejemplo, a... He visto antes uno que me parecía...
Ah, accesibilidad. Pues esto. ¿Ves? Pues definición. ¿Qué es la accesibilidad?
Me gusta mucho cómo está estructurado. O sea, tenéis razón. Yo también veo
que el dibujo parece mejor estructurado este, pero a la hora de la verdad, este me resulta
bastante más interesante, ¿eh? Porque el que puedas entrar y que ya tengas los recursos
justo de esa temática y que te da... Fíjate, si solo accesibilidad tiene casi tantos enlaces
como recursos de toda esta parte de Roadmap.sh, que está muy bien, ¿eh? Yo creo que se pueden
complementar totalmente. Pero esta de Frontend Masters y está en beta, ¿eh? Están trabajando
en ello todavía. ¿Ves? Que pone aquí beta, beta. No sé, me gusta eso. Es verdad que es
muy amplia, muy grande, que te puedes liar un poco, pero si te interesa algo en concreto,
pues eso, le puedes dar un clic y ver ahí qué es lo que explican.
Al entrar en el detalle, es verdad que es eso, que puede ser un poco lioso, pero me gusta
porque también ves con más claridad hacia dónde te puedes dirigir un poco más adelante, ¿no?
Por ejemplo, aquí ya, primero programación orientada a objetos, luego asincronía,
functional programming, programación funcional. La verdad es que está muy bien. O sea, me gusta,
me gusta. Me gusta que aquí ya, cuando ya vienes al tooling de JavaScript, empiezan las flechas.
Está empaño, empaño por todos los lados. Pues aquí tienes esto, aquí esto. Aquí empieza ya el
locurón, ¿eh? Os habéis fijado que toda esta parte de aquí es flechitas que parece que van
todo para adelante, pero ya cuando empieza el tooling de JavaScript, locurón. Mira, performance,
ya hemos visto una de performance, justamente. Bueno, de benchmarks, no hemos visto. Aquí a ver
si está esta. Perflink. Muchas gracias, jromano96, por suscribirte con Prime. Muchísimas gracias.
Mira, perflink, esta es la que... Sí, esta está genial.
Esta herramienta, si no la conocéis, esta herramienta sirve mucho para pelear.
Esta está muy bien para pelear con la gente. De decirle, yo creo que esto es más rápido
que lo otro, no sé qué. ¿Sabes? Cuando las típicas micro optimizaciones que yo recomiendo
que no hagáis. Pues esto típico decirle, ¿qué es más rápido? Esto o esto, ¿no?
Y típica pelea que hay de JavaScript que son tonterías. Pero bueno, que está bien,
que dice, bueno, pues tú tienes esto, ¿no? Tú tienes este código y a partir de este código
pues tú puedes hacer aquí diferentes como, pues nada, casos de uso o, bueno, aquí pone
test cases. Pues claro, casos que quieres testear y a ver cuántas operaciones puede hacer
por segundo de cada una de ellas. Y aquí, pues te puedes picar con la gente. Además,
te pone aquí un gráfico. Y esto lo puedes compartir totalmente. Lo compartes y ya lo tendríamos.
Vamos a hacer un run test porque al final es esto. Mira, 113.000 operaciones por segundo
de la primera. Claro, esto es obvio, ¿eh? Porque esto es buscar la primera. Pero está bien
porque aquí te das cuenta. Mira, es que esto parece una chorrada, ¿eh? Pero este ejemplo
te das cuenta de cómo realmente recorrer las keys, cómo sí que evita recorrer todos los elementos
del array y sí que te devuelve el primero que encuentra. Porque claro, el 100 está mucho antes
que el 200 y tal, ¿no? Y sí que se puede ver que si es un elemento que está más lejos
del array, pues impacta negativamente. Así que, bueno, cosas curiosas, cosas curiosas.
Por ejemplo, aquí, a ver, voy a hacer una cosa. ¿Qué pasaría si hago esto? A ver cómo sería
esto de... Si le doy la vuelta al array... Esto es totalmente...
Si le doy la vuelta al array, intento buscarlo. Y fíjate, fíjate, a ver, sin darle... Uno dándole la vuelta
y otro sin darle la vuelta. Estos son chorradas. Es que yo me lo paso pipa con estas tonterías.
Fíjate, mira, mira, mira. Ay, qué interesante. Mira, es más... Es peor. Si tú sabes que un elemento
está al final del array, es más rápido darle la vuelta al array y buscarlo, es más rápido
que directamente no darle la vuelta y buscarlo. Ah, curioso, ¿eh? Bueno, no sé. Es curioso.
Me parece curioso. Bueno, que Perflink yo lo he utilizado muchas veces. También tened en cuenta
la cosa que esto que os he estado comentando de Perflink, que está muy bien, pero que, a ver,
hay que pillarlo con un poquito de... Hay que pillarlo con un poquito de cuidado, ¿eh?
¿Por qué? Porque depende del motor donde estés ejecutando ese código, puede ser más
rápido o menos rápido, ¿ok? Claro, a veces es posible que el código en el motor de Chrome
vaya de una forma y en el motor de Edge vaya de otra. Así que hay que tener cuidado.
O en Node, por ejemplo, puede ir diferente también, aunque sea el motor de Chrome, por mil millones
de historias. Vale, pues quería ver más cosas. Bueno, quería terminar de ver un momento
esto. A ver, tenía curiosidad, ¿qué era lo del final? ¿Vale? ¿Qué era lo que...
Computer Science, animación, página... Mira, lo último, la seguridad. Hay que ver. Si te hackean
luego locurón, ¿eh? Data APIs, también para el final. Un poco raro. Es que es difícil
al final, ¿no? Hacer una guía para aprender frontend es difícil. Mira, performance, aquí otra vez.
Cuando arriba estaba preocupándose de performance de JavaScript. Es difícil hacer una guía
conforme lo quieras hacer con mucho detalle, es más complicado. Por ejemplo, esto de compilar a JavaScript
y aquí hablar de Reason, Elm, Closure Script y Pure Script, o sea, esto no tiene sentido.
TypeScript aún te lo concedo, pero el resto... Yo, a ver, creo que es más importante aprender Babel
antes que ponerse a Reason, Elm, o sea, que son paradigmas de programación totalmente distintos.
No sé. Y esto de dejar aquí la performance para el final, también un poco raro.
No sé. Es complicado. No se lo vamos a tener en cuenta.
También es que está en beta. Bueno, está bien porque, mira, pone aquí
es fundamental y especializar. O sea, ¿especializar? ¿Performance especializar?
No, ¿eh? Sí, hombre.
No, no, no, no. Nada de especializar, ¿eh?
La performance es experiencia del usuario, súper importante.
Así que nada de especializar. Eso es fundamental. Especializar.
Bueno, vamos a seguir con que tengo más cosas. Tengo más cosas, pero voy a beber agüita
y os voy a leer mientras y ahora miraremos otra cosa que tengo por ahí.
Alguien me preguntaba que qué me parecían las arquitecturas en el frontend.
Pues me parecen súper necesarias y más hoy en día, ¿vale?
Porque hoy en día el frontend es tan grande. De hecho, el código suele ser isomórfico.
Eso significa que se ejecuta tanto en servidor como cliente.
Por lo tanto, el tener un buen patrón y buena arquitectura en el frontend, o sea, es súper básico.
Y la arquitectura va más allá de poner componentes de RIA que ya está.
Sino, por ejemplo, utilizar Domain Driven Design, arquitectura hexagonal y cosas así.
Obviamente, en proyectos con cara y ojos.
Si es para vuestro portfolio, no hagáis Domain Driven Design.
Todo tiene su utilidad, ¿vale?
¡Gracias!
¡Gracias!
¡Gracias!