Forem: Kz

The journal of the frontend developer

Kz — Thu, 04 Apr 2024 23:02:43 +0000

Hola todos, todas, (ó todes). Hace 4 años soy front-end developer. Una de mis pasiones es escribir, y lo he hecho la mayor parte de mi vida. Obviamente, es algo que quise traer a mi nueva carrera como developer, pero siempre concluyo que o no tengo suficiente experiencia como para dar una opinión profunda sobre alguna herramienta, ó ya hay mucho contenido sobre esa herramienta.

Sin embargo, las vivencias que tenemos en nuestras respectivas empresas sí es algo único. Los dramas, los desafíos, y sobre todo el contraste que hay en lo que nos venden los creadores de contenido sobre cómo debería ser el entorno de desarrollo, y como realmente es.

En fin, creo que podemos hacer de este un espacio para que compartamos y comentemos sobre lo que creamos relevante a nuestro performance como web/app dev.

Deja un comentario con tu experiencia o lo que quieras decir.

Hi everyone, I've been a front-end developer for 4 years. One of my passions has always been writing. For obvious reasons, I wanted to bring this passion along when I became a developer and wanted to share content based on my experience. However, I've always come to the same two conclusions... I don't have enough experience to share a deep insight on a web-dev tool, or there is already too much content out there about it.

However, our own experiences as front-end developers are unique. Drama, challenges, and the contrast between what's expected and the reality as developers.

Anyway, I think we could make this a space to share and comment on anything we want that's relevant to our performance as web/app dev.

Leave a comment with your experience or whatever you wanna say.

¡Así es cómo Solid Js lo hace!

Kz — Mon, 24 Apr 2023 18:46:55 +0000

Los que nos gusta y venimos de experiencias con React nos va a encantar Solid js.
En síntesis, podemos decir que la mayor ventaja de Solid sobre React radica en dos puntos principales:

Tamaño del Bundler: En Solid es más ligero porque ya contiene módulos que en React se manejan como lib de terceros.
Signal por States: Lo que es completamente diferente al comportamiento del state en React de re-renderizar el componente cada que el estado cambie. Eso pasa por el algoritmo Diffing & Reconciliation. Si no estás familiarizado, te dejo el link para que entiendas el concepto detrás del algoritmo.

Solid, por su parte, crea señales (signals) directamente en elementos del DOM que inteligentemente percibe que podrían cambiar, previniendo así, re-renderizar el componente al actualizar el elemento.

Ya que hemos sacado del camino lo que todos sabemos de Solid Js, quiero enfocarme en algunas diferencias en la API de Solid con respecto a React para comparar como lo hace React y mostrarte cómo lo hace Solid js.

useState - createSignal.

Mientras que state crea un valor, signal crea una señal que es un método a cuyo valor se accede al ser invocado, por eso los paréntesis. La Función setCounter cumple la misma función para ambas herramientas.
La sintaxis puede variar un poco, sin embargo:

Eventos Si bien vimos en las imágenes anteriores que el evento onClick no cambia de React a Solid, sí el método para los inputs. En React lo llamamos onChange, y en Solid será onInput:

useEffect - createResource Si bien el useEffect es una de las herramientas más populares de React, también es requiere mucha atención para no terminar ejecutando código (típicamente asíncrono) más veces del que debería. Con frecuencia vemos algo así en nuestra consola con un solo fetch, contra lo que tenemos que juntar cabezas para crear una solución performante:

Entonces, Comparemos:

Usando el hook createResource que viene directamente de solid-js sin la ayuda de effectos para ejecutar la función en montaje.

Ternarios y múltiples elementos. Una de las prácticas más comunes en React es la del método .map() para renderizar varios elementos y dinamizar los valores del mismo. Esta práctica usualmente involucra un ternario (hay muchas otras opciones, es verdad) pero quedémonos con la más común, que es la crear un ternario para evaluar si el estado ya se ha populado y puede ser mappeado. Algo así:

Este es un escenario bastante común en React. Estas mismas lineas de código pueden existir en Solid y funcionaría sin problemas, pero Solid tiene una solución más sofisticada:

A. Para el ternario, utiliza una etiqueta que se llama que se importa de "solid-js" y recibe dos atributos, when={// aquí se hace la evaluación de la condición} fallback={//aquí ponemos lo que queremos renderizar mientras el valor de la señal cambia} Quedando de esta manera:

B. A pesar de a estas alturas, aun estamos codeando muy "Reactive". Solid ofrece otra alternativa a los elementos que se quieren renderizar de forma dinámica. En esta ocasión es otra etiqueta que se llama que también se importa de "solid-js" y recibe un atributo each={//Aquí depositamos el arreglo de valores} de hecho, tuve que forzar un error sintáctico el la imagen anterior para evitar el error de eslint en el que Solid me recomienda usar esa etiqueta:

Routes. En React, el enrutamiento típicamente se trabaja con "react-router-dom". Durante este momento es bastante oportuno hacer code splitting usando lazy y Suspense... Estos dos elementos siguen presentes en Solid. Sin embargo, a lo que me refiero es a esto:

Esto es en React, que se importa de esta librería:

Ahora, "react-router-dom" también tiene otros elementos que son muy útiles, como:
a.
b. useParams

Ahora, Solid ya tiene en sí un módulo de enrutamiento al que podemos importar de "@solidjs/router"

Este módulo contiene:
a.
b.
c. /=> que es la versión de Solid
d. useParams

Con esto termino mi blog de comparación de ambas herramientas. Venir desde React hace que aprender Solid sea muy fácil, y nos ayuda a apreciar las mejoras que ofrece.

Espero que este contenido haya sido útil.

¡Crea tu PWA!

Kz — Sat, 18 Mar 2023 16:00:33 +0000

Concepto de PWA.

Las siglas PWA representan PROGRESSIVE WEB APP, el cual es un concepto en el que el desarrollo de páginas web se percibe bajo el modelo de aplicación. La página web será servida en una url como tradicionalmente ha sido, pero adicional a ello, tendrá la alternativa de ser descargada en el dispositivo local creando un ícono y posteriormente una UI bastante similar a la de una aplicación.

La opción es algo que nos ofrece el buscador de forma intuitiva cuando nuestra website cumple con una serie de requisitos... entonces, un ícono con un mensaje de instalación aparecerá en la barra de búsqueda.

Requisitos.

Necesitamos una serie de íconos conocidos como Favicons con los que se identifica nuestra web. Usualmente tenemos un archivo .jpg .jpeg .png En cualquier caso podemos ir a la siguiente página https://favicon.io/favicon-converter/ arrastramos nuestra imagen dentro del box y descargamos. Eso nos generará un .zip con varios archivos que incluyen:

favicon.ico
2 imágenes favicon.png de 16x16 y 32x32
apple-touch-icon.png
2 imagenes .png con dimensiones de 192x192 y 512x512 (estos serán los logos, así que bien podemos cambiar el nombre a logo192.png y logo512.png)
site.webmanifest que en realidad es un manifest.json (el cual es otro de los requisitos).

Necesitaremos otros archivos que van a acompañar los favicons que ya hemos generado.

Necesitamos dos logos más... uno de 256x256 y otro de 384x384
Para eso, podemos utilizar la siguiente website: https://imageresizer.com/
Por default, image resizer va preservar el aspect ratio de tu imagen pero presionando en la opción correcta, podemos definir las dimensiones como las queremos. Además, nos aseguramos de que el background sea el que queremos (ya sea sólido, o transparente) y descargamos.

Ya teniendo las imágenes, necesitamos una última a la que nos vamos a referir como maskable. Tomamos la imagen que hemos venido usando para generar nuestros favicons, y esta vez usaremos la website: https://maskable.app/editor
De las varias opciones de descarga que nos da, escogemos la dimensión que se ajuste a nuestro proyecto. (Yo lo descargué en 192x192).

Todas estás imágenes las vamos a guardar en la carpeta public.

Lo segundo que necesitaremos es crear un manifest.json Si estamos utilizando un proyecto creado con CRA, entonces ya tendremos uno. En todo caso, podemos crearlo manualmente o generarlo en esta web: https://app-manifest.firebaseapp.com/

Además de las propiedades que nos da el generator, necesitamos una que se llama icons el cual es un arreglo en donde declaramos los íconos de 192, 256, 384, 512 y el maskable, cada uno dentro de un objeto con las propiedades src, type, sizes:

Necesitamos incluir unas meta tag, algunas con propiedades específicas y otras para referenciar el manifest.json y el favicon:
Necesitamos dos documentos más, los cuales son quizá los más complejos de toda la configuración:
service-worker.js
serviceWorkerRegistration.js
La configuración necesaria la vamos obtener de CRA.
Lo que yo hice fue crear un proyecto nuevo con el siguiente comando:
npx create-react-app my-app --template cra-template-pwa
Este comando crea una versión con la configuración de los archivos mencionados antes, listos. Los tomamos y movemos a nuestro proyecto.

Adicional a eso, vamos a copiar estas lineas en nuestro index.js | main.jsx :
import * as serviceWorkerRegistration from './serviceWorkerRegistration';
serviceWorkerRegistration.register();

¡Eso es todo!

Desde el host local tradicional en el que estamos trabajando no vamos a poder ver los resultados en su totalidad. Eso se debe a que el serviceworker está configurado para production no para development.

Lo que podemos hacer es ejecutar el build, y ejecutar el build en un servidor local.P Para eso necesitaremos serve... instalamos npm i serve

luego ejecutamos:
npm run build serve -s build

Eso nos pondrá un host local disponible con una versión de production. Abrimos el inspector, lighthouse, PWA y hacemos el análisis y si todo ha salido bien tendremos dos confirmaciones visuales:

Esto es exactamente lo que hice, paso a paso y me funcionó.
Entiendo que puede ser frustrante cuando se sigue un paso a paso y no funciona como funcionó a quien lo escribió. Espero que no sea tu caso, y te haya funcionado.

Glosario:

* Aplicación (como se le conoce en Sur y Centro América) se refiere a Aplicativo (como se le conoce en la península Ibérica).

* Barra de búsqueda también se puede conocer como Barra de direcciones.

¿Dónde ponemos el useEffect?

Kz — Wed, 08 Mar 2023 08:01:36 +0000

Viendo el nuevo paradigma que el equipo de React Router propone en su más reciente versión en cuanto al inicio de flujo de datos desde ese render inicial, y al ponerlo de frente con el modelo de Remix (mismo equipo), y de TanStack Router... creo que finalmente, podemos decir, de forma segura, que debemos re-pensar la función de useEffect en nuestros proyectos.

No me atrevería a decir lo mismo que diría David Kourshid en aquel video que escandalizó a todo el mundo, y que lo puso en el ojo de un huracán de críticas, pero creo que entiendo lo que quiso decir en su video "Goodbye useEffect", y es que ya no necesitaremos el hook controlador de efectos para dar inicio al flujo de datos en ese primer render de nuestros componentes.

En otras palabras, y para que esté más claro... algo así:
useEffect(() => { fetchData() }, [])
será algo del pasado.

Entonces, sí esa ya no será la implementación, ¿cuál será?.
Esa pregunta es precisamente la que quiero responder. Sin embargo, hay una más evidente aún a la que me quiero dirigir y es: "¿Qué hay de malo en el useEffect?" eso asumiendo que haya algo malo.

Veamos un escenario típico, y tratemos de entender lo que está sucediendo.

Los console.logs nos ayudan a entender en qué momento se realizan nuestras funciones. Primero se muestra el log que está por fuera del effect. Luego, se muestra el log que está dentro del effect.
Teniendo en cuenta que este código es Client Side Rendering (CSR), el log por fuera del effect se muestra tan pronto se inyecta el JavaScript al html en nuestro browser, montando así nuestro componente; tan solo entonces es que la interactividad de nuestro componente empieza a realizarse loggeando el mensaje dentro del effect, llevando a cabo una función asíncrona, que a su vez actualiza un state: data (y ya sabemos lo que pasa con el componente cada vez que su state se actualiza)... re-renderiza el componente una vez más, esta vez con su estado actualizado.

En pocas palabras, y usando nuestros logs como ejemplo, para cuando el componente esté resuelto, hemos terminado con 4 logs en consola sin contar los del strictMode, cada par representa las veces que el mismo nodo se pintó en el DOM.

Creo que esto, hace muy evidente qué es lo que se está tratando de evitar, pero sigamos un poco más.

Aquí estamos ante un coyuntura de la esencia misma de React. El comportamiento básico de un componente es que si su estado se actualiza, este generará un nuevo render. No obstante, estamos de acuerdo en que hasta esta instancia, solo estamos montando el componente e iterando sus datos y no ha existido interacción de parte del usuario, por ende preferiríamos que el componente nos cueste únicamente ese render inicial con los datos que queremos resolver.
Esto no es "intrínsecamente" posible en React por dos causas que mencionamos anteriormente:

El código JS es CSR.
State Updates generan re-renders.

¿Cómo lo solucionamos?

La divergencia del pensamiento de desarrollo nos ha llevado a desear componentes stateful que desde su render inicial carguen los datos que le hayamos asignado, como si parte de la resolución de ese Javascript en el proceso de hydration ya contenga los datos con los que debe crear el Nodo.
Seguramente, están pensando en SSR, pero estamos hablando de REACT, y esa se lo dejamos a NEXT Js.

El primero en rodar la pelota fue TanStack con su librería de React Query, que reduce significativamente el Boilerplate para fetching de datos en componentes, y para el manejo de efectos secundarios asíncronos a partir de eventos de usuario.
Un ejemplo del código anterior con React Query:

Sin embargo, seguimos con el mismo resultado en consola.
¿Qué hemos logrado entonces por medio de React Query?

Bueno, voy a listar dos beneficios que considero cuenta por 100:

Provee manejo de datos desde un estado (STATE) del servidor. Eso significa que no tenemos que preocuparnos por englobarlo todo dentro de un estado global en nuestra app.
Elimina el boilerplate para manejar funciones asíncronas, requests a api's que tienen que ser almacenadas en estados globales y posteriormente consumidas en diferentes partes. Estoy hablando textualmente de Redux Thunk, Tooltip, Saga... y demás. Cuando hablo de reducir el boilerplate, no solo estoy hablando del store, de los reducers, de los actions, de los types, de los estados del requests en los que tenemos que especificar qué comportamiento queremos que nuestra app tenga... Hablo también de todas las funciones que con las habilitaremos la interacción y mutación de los datos que provienen del servidor.

Ahora bien, retomo la frase introductoria del primer punto: "Provee manejo de datos desde un estado (STATE) del servidor" puede que nos haga plantearnos la pregunta: ¿Si el estado ya está provisto desde el servidor con el manejo de datos, y asincronismo, sería posible que el componente contenga los datos resueltos en el momento exacto en el que se pinta en el DOM?

El approach de Next es el método getStaticProps y getServerSideProps con el que se habilitan datos estáticos que se cargan con el componente una vez este existe en el DOM. Éste posteriormente se hidrata para hacerse interactivo del lado del cliente.
Next, en su última versión, anunció el uso de React como librería para la creación de Server Side Components. Esto desde el punto de vista arquitectónico de componentes. Sin embargo, no olvidemos que el equipo de React desde el 2020 ya estaba hablando de React como Server Side Components. Lo que trato de decir es que aunque lo de Next es novedoso, no es la primera vez que se piensan componentes resueltos desde el servidor.

Por otra parte, Remix, un framework que extiende React pero es 100% Server Side, propone el término Full stack components nos permite focalizarnos en las interfaces de usuario, y seguir los estándares web para crear experiencias de usuario rápidas y resilientes. Con Remix podemos crear tanto el frontend como el backend de nuestras aplicaciones web, utilizando React como base. Entonces, podemos crear componentes React y reglas de renderizado de HTML para nuestro frontend, así como programar rutas manejables en nuestro backend para crear reglas y lógica de negocio.

A diferencia del comportamiento "común" de React, Remix utiliza server-side rendering para manipular los datos y renderizar el contenido y markup HTML en el servidor, enviando la menor cantidad posible de código JavaScript al cliente, y sin ninguna función fetchData o hook de efecto de lado del cliente que maneje sus solicitudes asíncronas.

La función que permite esto reciben el nombre de loaders, las cuales, aunque se enuncien a la misma altura de la UI, se resuelven del lado del servidor. Los datos son inyectado al componente (UI) por medio de un hook llamado useLoaderData.

TankStack Router plantea un paradigma similar. Desde su sistema de enrutamiento pone a disposición el método createBrowserRoute el cual es un arreglo de objetos en el que no solo se anidan los componentes que responde a paths, sino también la propiedad loader la cual se encarga de resolver todas las solicitudes asíncronas, y servir el componente junto con los datos resueltos desde el render inicial.

Finalmente, llegamos a React Router en su versión más reciente v6.8.1 - v6.8.2 en la que cambia por completo el paradigma, y se ajusta a esta tendencia de componentes robustos, resueltos con mínimo Js para resolver del lado del cliente.
Los Elementos BrowserRouter, Routes, Route, ahora son reemplazados por createBrowserRouter, el cual es un método con propiedades como error, path, loader, children. (Sí, un loader similar a los mencionados en anteriormente). En su propiedad children, recibe un arreglo de objetos en los que se declara el path, el elemento que corresponde al componente, y dos propiedades más: action, loader. Action se refiere a los eventos que detona el usuario cuando interactúa con nuestra app. Loader se refiere a los datos o solicitudes asíncronas necesarias en nuestro componente. Al igual que Remix, se pone a disposición el hook useLoaderData para extraer los datos de la solicitud sin ayuda de useEffect, ni ninguna otra librería o función asíncrona que suceda del lado del cliente.

Todas estas herramientas mencionadas tienen en común que abrazan comportamientos nativos del browser para habilitar estos métodos, y sus cálculos computacionales. Si eres un programador de más de 10 años de experiencia, seguramente dirías "like the good old days", un expresión romántica que hace alusión a un momento en el que el paradigma había alcanzado su máxima capacidad tanto en el lado del Servidor como del lado del Cliente. Sin embargo, sí propone reconciliar lo mejor de un paradigma antiguo, con el paradigma que ahora conocemos.

Recurso: https://codesandbox.io/s/serene-mountain-dwfsmk?file=/src/App.jsx

How to become a successful self-teach programming student.

Kz — Mon, 20 Feb 2023 06:52:22 +0000

This year React js hits its 10th anniversary.
It was React that made me believe that I could really be a Web and App developer. I have been working both as a Web developer and programming instructor, both scenarios with React, and to celebrate React's anniversary, I have decided to list my ideas on effective learning techniques for those who are taking their first steps on frontend development, or React.
On the way, I would also share how React (an abstract tool invented in the mid 2010-2013) has affected positively my life.

I'll go straight to the point.

At the starting point of learning something new, there are many things that we ignore that will determine our success or failure in achieving our goal.

We tend not to consider the pitfalls of the career we are setting upon. The difficulties of finding a job, the requirements, what the hiring process is like, and so on.
Most of us completely ignore our learning skills, style(s) and pace. What I'm trying to say is that not all of us learn from video tutorials, not everyone can read a paragraph and identify the main ideas on a single read, and certainly what seems easy for some people doesn't necessarily qualify it as "easy" in itself. We may find ourselves stuck in places where other people succeed effortlessly. That brings our next point...
Develop mechanisms to deal with frustration and protect motivation. The worst part of frustration is that it destroys motivation. We overcome sadness eventually (unless it's medical), but motivation is very difficult to re-build.
Give yourself the time to process the information. Not only will this ensure your learning the concept, but will also prevent frustration. Try not to compare your progress to anyone else's. However, do no think that you need to know 100% of a basic aspect before diving deeper into a more complicated one. That's not how it works!
Track down the source of your motivation.

Back in 2016, I started learning Javascript. I had already taken courses on HTML and CSS, and to this point I still have no idea what those courses were about. I completed them, but Javascript got really complicated for me. So, I concluded that I was a successful teacher at the time, and that I had no need for putting myself through that misery. It turns out that my motivation was only regarding salary expectations... no love for tech, or deeper meaning on how this could help humanity or anything, so I dropped out.
Now, I am not saying that money shouldn't be a motivation, nor am I saying that if that's case you should quit. NO! What I am saying is, identify and strengthen the source of your motivation. This will be very helpful by the time things get tough.

Do not get emotionally attached to any blogger or YouTuber.
Very commonly do I find people who follow streamers in a worshipping kind of way. As if the guy/girl was infallible.
Be open, contrast materials, debate ideas, weight everything that you learn in light of what's considered as good/bad practice in web development, come to conclusions, and expose your ideas in those communities.
Find a Bootcamp or an institution to learn.
People can learn by themselves, it's true... and I am sure there are a lot of cases where people learned by themselves. However, as someone who learned English, and play the guitar by himself, I know that it would have costed me double or triple the time to get to where I am if I hand't gotten enrolled in an institution.
Create groups of study. It's important that you consolidate whatever little or much you know about something. You need to understand the API of a programming language, but also the concepts of such language. Nothing better to digest them than trying to teach them to someone else. If you can't define it clearly, then you'd probably still don't get it right.
As you are getting much stronger a programmer, create scenarios where to confront your ideas about everything. Write essays, articles, make lists of things, share your questions with other developers, hopefully, more experienced than you on your same field.
Make your comfort zone uncomfortable. That means... practice something and stick to it till your feel comfy with it and can do it eyes-closed, but don't fool yourself thinking you got it all pinned down. Every time you feel comfortable, it's time to crank it up a notch.
Read a lot! Stick to your videos and streams, but make documentation your first option to understand any api. That requires practice, so as you're learning on this very beginning of things, start complementing your videos with documentation on Javascript or whatever it is that you're learning.

Finally...

I left a career with 10 years of experience. Had to send more than 200 resumes before getting my first IT job. Once I got my first job, I had to go through other 3 badly paid jobs to get to one with an attractive salary... and having a good salary on one hand, I had to decide to stay and get professionally stuck, or leave for a better job with a poor salary offer because it would get me closer to what I have on mind for me.

I struggled at the beginning and asked myself if it was even worth it many times. I had to ask for help when I was learning JavaScript, and deprive of other social events to spend more time studying. However, when I saw React for the first time, it was like love at first sight. It all clicked, and I was now in the position of helping those who helped me during the fundamentals of JS (Ironically).

Having learned React, and applied those very same tips herein written, got me my first job.

Learning programming is definitely one of the top five best decisions I've ever made; and React pushed me closer to it.

The inadvertent wall of Programming.

Kz — Mon, 20 Feb 2023 05:01:11 +0000

I was browsing on my computer, on my not-a-premium YouTube account, looking for videos about guitar techniques, when I ran into an ad promoting programming with the premise that it being a growing industry, would continue to grow with a brutal investment of 9 billion dollars.

However, such a premise was upset by the fact that there were not enough programmers/developers/software engineers to fill the void and keep up with such investment.
Of course, the ad aimed to promote a coding academy.

On such a premise, stand start-ups like Platzi, Henry, CoderHouse, and the place where I study, Academlo. They teach you programming languages and train you on some of the skillset required for the craft that can’t just be taught.
I talked to one of my friends about it. He has been a backend Engineer for over 10 years and has built a very solid lifestyle which many have to struggle for. (Needlessly to say that it wasn’t easy for him).

That day, he told me about his learning path, then how he gained experience and how experience is valued in this work field in such a way that the more experience you have, the better the salary gets.

I have been an English teacher for over 10 years, and my salary expectations or actual compensations have never been that rewarding. In fact, in order to make a decent salary, one has to be willing to take in multiple jobs and put in 10 to 12 hours a day, 7 days a week.

When you put that in perspective… What do you have to think about to make a switch and hope for a change that would be meaningful enough to re-direct your life onto a new trail?
I thought to myself, “I’ve found IT!!!”

Moving on…
There is one thing that I never asked myself or others who talked to me about this profession, and that was the hiring process.

The process, I thought, will be very simple… given that there is a shortage on the number of programmers (IN THE WORLD), I figured that newly graduate programmers would be a catch.
So, I’d put myself out there, with the following expectation:

I’ll find an opening and apply.
They’ll set up a meeting.
I’ll have my skills tested.
They’ll make an offer.
I’ll be rich!

Clearly, the last part was a joke, but as absurd as the other steps were in my expectation, I did think it was going to be like that. (I am a smart person, I swear).

The process, however, has not been quite like it. And the reality is pretty cruel, to be honest.
Just today, I applied to 31 jobs opening between 2 different countries to get as much as the chance for an interview.
YES! An interview!

Not an offer, but an interview. I often wake up in the mornings and I find e-mails from companies saying, and I quote:
“We understand the effort…”, “We have decided to not move forward with your application…”, “We see potential in your skills…”, “We would really like to keep you in our pool of applicants”

I know that my fellow juniors can relate.
Following our common sense, we’d probably conclude that I may not be as qualified as I think I am, and therefore the rejection takes place.
Let’s hold that thought for a moment and ask ourselves how we can define “qualified” in this field.
There are many programming languages for different purposes, and another bunch for the same purposes, so… is it qualified = larger number of languages known?
Well, we’ll all have a different definition of what being qualified really means. I am going to venture and say one myself:

Being qualified (in this field) depends on how you can structure your logical reasoning to tackle problems while maintaining clear communication with a group of people.
I think that languages and technologies that are relevant will come along with experience. We can’t spend the whole life catching up with the latest technologies to finally be ready for interviews and responsibilities.
The history of this craft validates my definition.
So, this is the wall they do not warn you about. There is a shortage of programmers, but there is no door to enter through… there is a window, and it’s small and rusty.
Just the other day, I was watching a job post that read like this:

Looking for Software Developers Jr.

3+ years of experience using (this and that) technologies.
Really good English level.
Experience in Database such as (this and that) Salary: USD$900 ________________________________________ How realistic these job posters are about the compensation between experience and salary? I have, at least, 3 more questions...
Is someone with "3+ years of experience" still considered a Jr.?

Could someone with such good experience and knowledge work for 900 dollars? My point here is not Money. My point here is that to get in this field as to be given a chance, you must already be, at least, a first-level expert. That makes no sense, especially because in this field, there are multiple variables, unlike other work fields.

But then, I found a video, here’s the link to it (https://www.youtube.com/watch?v=Dv7gLpW91DM)
And something that Mark said resonated in my head:
“…there aren’t enough people trained in half the skills today”
So, this resonated to the point that made me conclude:

It is important to define a learning path and stick to it. Define it based on the type of things that you would like to work on, and master those tools. (Mastering something is a pretty word that defines the refinery of doing something after having a wide experience with it.)
Most of these academies that educate you and train you are clueless about the requirements of these big companies. For instance… What skills is Mark talking about?
These academies teach you programming languages, they train you to ace a technical interview… but, perhaps it’s not being correctly oriented… perhaps the problem is not recruiters looking for high-experienced juniors. Perhaps, the problem is in multiple variables.

Anyways… and with this, I conclude.
However hard the search is. However long is taking.
Regardless of the many hours of self-training, taking courses on Udemy, gaining certificates on LinkedIn, badges, and going through JavaScript coding challenges on YouTube…
All the effort will be rewarded, a job offer will arrive, and you will be a good fit for a team. If not, you will have navigated this field long and deep enough to start your own idea.

This is not my soothing things for you. This actually is one of the many beautiful facts about this career.
IT ALWAYS PAYS OFF.