Laboratoria / curriculum

El bootcamp de @Laboratoria es un programa de aprendizaje inmersivo de 6 meses enfocado en los perfiles de Web Developer y UX Designer.
https://curriculum.laboratoria.la
Creative Commons Attribution Share Alike 4.0 International
491 stars 462 forks source link

Abrir el espectro de herramientas de JS #861

Closed ivandevp closed 2 years ago

ivandevp commented 5 years ago

Luego de unos meses de experiencia profesional fuera de Laboratoria en el mundo del front-end, siento que hay algunas herramientas o conceptos interesantes que se podrían agregar a la currícula con miras sobretodo a la colocación laboral debido al uso que le dan las empresas, acá la lista seguida de mis opiniones:

GraphQL

Este tema desde que salió se puso de moda, y por lo que he podido ver sobretodo en el mundo de startups ha sido una tecnología muy bien adoptada. Muchas posiciones de trabajo buscan el kit de React + Apollo + GraphQL, incluso me atrevería a decir que un poco más que React + Redux. En este caso, creo que existe un issue detallando cómo podrían ser el next step. Mi opinión aquí es que si bien el contenido de esto puede tomar tiempo, creo que se podrían incluir proyectos interesantes donde se provea un back-end usando GraphQL (al final es muy poco probable que ellas terminen armando su propia API con GraphQL desde una posición de Front-end Jr.) y que ellas puedan consumirlas en el front-end usando alguna librería como Apollo o Relay, sumado a otras herramientas libres como Yoga y/o Hasura :thinking:.

Typescript

A pesar que un artículo describe muy bien mi opinión sobre Typescript, he podido notar la gran adopción que ha tenido en las empresas. Esto creo que es demostrable en los reportes como State of JS 2018, donde tienen el 46.7% de developers usándolo y 33.7% interesados en usarlo, y en el Survey de Stack Overflow con 22% de preguntas superando a lenguajes de móviles que existen mucho antes que Typescript, y si mal no recuerdo el reporte de Hackerrank developer skills tiene data interesante al respecto.

Desde mi perspectiva, esto ha sido por 2 grandes motivos que abren paso a los 2 puntos que siguen en la lista:

  1. Muchos han adoptado Typescript porque es una manera en la que muchos programadores entienden mejor a JavaScript. Un porcentaje muy grande de developers han pasado por algún lenguaje como C, C++, Java o C# que son estáticamente tipados y para ellos la parte del front-end en su mayoría se les hace un mundo inentendible, debido a esto, que el código de JavaScript, se vea como algo más parecido a un lenguaje tipado, permite una facilidad de lectura de su parte.

  2. Angular es aun muy usado, sobretodo en corporativos y algunas startups aun. En la actualidad, no sé si hay datos de cuántos hagan Angular sin usar Typescript.

Estos 2 últimos puntos son mi opinión personal, aun sin data por comprobar. Sin embargo, creo que sería bueno que muchas lo conozcan y no solo las que vean Angular. Al final, en React muchas librerías usan TSX y en el caso de Vue 3, fue rescrito de Flow a Typescript.

Programación orientada a objetos

Una de las cosas que hace Typescript intrínsicamente y frameworks como Angular es la adopción del paradigma de programación orientada a objetos y si bien esto no existe como tal en JavaScript debido al prototipo y que las clases son solo syntax sugar de ES6; la justificación de dicha sintaxis per sé es una mayor adopción, sobretodo de programadores de otros lenguajes de programación. Esto a su vez, siento que ha provocado que muchas empresas usan este paradigma tanto en el front-end y el back-end. Incluso aun, cuando se trata de React que intenta fomentar lo declarativo y funcional. Esto sumado que en corporaciones y consultoras incluso más grandes (creo que puede ser demostrable por Job Placement) muchos filtros van arraigados a este paradigma, los patrones de diseño y principios como SOLID.

Mi propuesta aquí sería que al menos haya unos cuantos ejercicios que lo tengan que hacer implementando conceptos de programación orientada a objetos (tal vez Typescript puede facilitar esto).

Angular, Vue

Si nos basamos de reportes de trabajo, Angular sigue siendo extremadamente usado, sería bueno tal vez si no lo tenemos, limitar el scope a las egresadas de Laboratoria, pero estoy seguro que hay mucha demanda fuera. Vue es usado en muchas startups y sobretodo back-ends en PHP por la fácil integración de Laravel. A pesar de que mi :heart: es de React, y que desde hace un mes tuve que cambiar el switch a Angular (just because it's Google tool), creo que he podido notar la gran demanda que hay además de React.


Estas son mis observaciones, en este tiempo que he estado expuesto al mercado laboral. Entiendo completamente la complejidad que esto trae desde el diseño de contenido hasta la ejecución pero como siempre se ha predicado, creo que debemos de abrir el espectro para mejorar nuestro impacto y no limitarnos a lo que a nosotros nos gusta o nos mueve o por último, que nos sentimos cómodos.

Por último, 2 temas más que le pondría un ojo como punto de mejora son, computer science skills y asincronía. Computer science es un tema demasiado amplio, y por ello son 6 meses de universidad como mínimo, pero a lo que me refiero es que un ojo en analizar sus soluciones no estaría para nada mal, a pesar de que la expectativa es que sean Jr. Developers, las empresas siempre buscan unicornios. Asincronía creo que es un MUST pues no creo que haya front-end developer que no tenga que hacer algo que sea asíncrono más aun dado cómo funciona JavaScript, mi sugerencia es que no solo vean cómo hacer un fetch, creo que es hasta cierto punto necesario, que usen librerías, patrones de asincronía (reactive programming es un mundo demasiado interesante) y sobre todo, entender el EVENT LOOP. La pregunta de entrevista del setTimeout(() => console.log('1'), 0) no debería ser solo un concepto de memoria, creo yo que debe ser algo que se pueda explicar correctamente y así no habrán más preguntas de

let variable; 
fetch(url)
  .then(resp => resp.json())
 .then((data) => {
     variable = data.prop;
  });
console.log(promise); // undefined??

¿por qué undefined? Si no les ha pasado que le hacen esas pregunta, óbvienla, pero al menos yo si he visto preguntas de ese tipo. Esto es muy opinionated, basado en mi experiencia, pero con gusto me gustaría leer/escuchar/ver sus puntos de vista. Está de más decir, que puedo apoyar con lo que sea necesario :smile:.

giancorzo commented 5 years ago

@ivandevp Sobre Typescript no sólo aporta con el tipado sino que agrega cosas que tendrías que hacer con babel o webpack como por ejemplo usar esm (import / export) aunque node 12 ya lo va a traer de manera nativa.

Por otro lado agrega la capacidad de hacer alias en los imports que me parece interesante pero si es cierto que muchos usan typescript para escribir todo con clases (Don't like it) pero es lo que hay.

En proyectos con React te quita la dependencia de ProTypes para escribir mejores componentes.

Sobre Angular tienes toda la razón, muchos "corporates" les encanta angular por el hecho que viene con controllers, services, etc (muy parecido a spring) pero definitivamente hay un shift hacia Vue (React mejor...kinda)

No sé que opinas?

tzkmx commented 4 years ago

Quisiera retomar está conversación, todos son temas relevantes en el mercado laboral actual y más allá de preferencias personales.

TypeScript parece engorroso a veces pero sirve mucho para definir intercambios claros de información, incluso hasta introduce a la idea de contratos tan importante para entender interfaces en la orientación a objetos, o la arquitectura orientada a servicios. Y podría decirse que las pruebas hacen esto aún con más fuerza, pero la declaración de nuestras interfaces ahí en la misma función, ya sea con TS o flow o desde JSDoc, ayudan hasta con el autocompletado y venden clarito que documentar ayuda a la propia developer y su equipo.

En este sentido Angular no creo que se deba tanto a Google sino a una arquitectura bien planteada y que deja mucho menos dudas de por donde empezar, las conversaciones de equipo son más interesantes si hay un área de consenso mucho mayor aunque venga de entrada de la documentación del proyecto que introduce tantas ideas de patrones de diseño.

Por otra parte GraphQL hoy en día es mucho menos el hype que cuando lo propuse hace un par de años en #509 , hoy es más bien algo que se aprovecha en nuevos productos y en otros equipos ni se conoce. Sin embargo reitero que implementar y no solo consumir es algo que les dará más confianza y que de hecho ya no está tan alejado de extraer datos de otras API con fetch, por ejemplo: https://github.com/tzkmx/azure-wp-feeds que consume de la API REST de WordPress contenidos con fetch y entrega un subconjunto de datos más manejable para widgets en el frontend.

Y un tallercito como este puede reforzar objetivos tanto de serverless como de data fetching, tipado, optimización, etc.

mfdebian commented 2 years ago

¡Agradecemos mucho su participación! :blush:

Durante el tiempo que se abrió este issue, y hasta el día de hoy, se han ido agregando estos tópicos a la currícula.

Muchas gracias por abrir la conversación, nos ha servido para ir revisando qué tecnologías/paradigmas son valiosos para nuestras estudiantes.

Por ahora cerraremos este issue ya que cada tema en particular que toque revisar será incluido en su issue pertinente, de manera de mantener actualizada nuestra lista de issues.

¡Muchas gracias! :rocket: