[Javascript] Hilo General

Yo hace años que cambié JavaScript por TypeScript, y es una maravilla.

Supongo que quienes lo odian es porque lo usaron en su día para guarrear en jQuery...

#3

Sobra decir que aqui tambien se puede hablar de TS.

Yo personalmente no he tenido la suerte de trabajar con ello a nivel profesional (sólo trastear un poco en mis side projects), y la verdad que a veces lo echo bastante en falta. Por otro lado no sé si me costaría mucho adaptarme a tener que tipar absolutamente todo, creo que se tiende a pensar que carecer de tipos implica que tu codigo es una mierda, pero eso viene heredado de mucho novato usando JS sin pararse a pensar que está escribiendo.

#6 Por mi experiencia solemos desechar typescript porque literalmente escribes el doble de código, no es el mejor lenguaje tipado que podría haber sido, mira Go por ejemplo, escribes muchísimo menos código que con typescript (en relación a al tipado) y es fuertemente tipado.

También decir que somos una consultora y la velocidad de desarrollo es muy importante (y normalmente muy rápida), si fuera un producto propio que fuese a durar mucho tiempo, lo consideraría.

A favoritos.

Me gustaría crear el hilo general de C#, ya que es el primer lenguaje con el que he empezado por mi cuenta pero estoy empezando en esto y no sé si sería el más indicado xd. Si se anima alguien con más conocimientos genial y si no pues lo haré yo como buenamente pueda.

#12 Depende:

¿Quieres algo enfocado a productividad?
Aprende React, Angular+TS o Vue.JS.
Spoiler: tarde o temprano, vas a tener algunas carencias.

¿Quieres solidificar tu base un poco más?
Hazte algunas cosillas en JS, pero pequeñitas y con objetivos concretos, y si quieres también en NodeJS.
Apúntate a https://justjavascript.com/ y te llegarán pequeños mails con lecciones breves y bien explicadas de los fundamentos de JS.

Mi consejo: haz ambas. Aprende un poco más o enreda un poco más con VanillaJS, y luego ponte a hacer algo con React, por ejemplo. Y cuando en React te vayas encontrando con elementos nuevos que no conocías del lenguaje o del estándar de turno (EcmaScript X), te abres un JSFiddle y te pones a hacer experimentos.

Cosas que deberías saber usar medianamente bien antes de meterte con un framework a tirar lógica de negocio:

• Valor vs referencia. Saber cuándo está petando algo porque pensabas que habías hecho una copia de un array pero los elementos siguen siendo las mismas referencias.
• Diferencia entre comparar con ==/!= y ===/!==. Usar, si puedes, siempre la segunda opción (===/!==).
• Scopes y lexical this: saber qué es el this en una función. Saber qué hacen .bind, .apply y .call, qué hacen las funciones flecha.
• Closures y captura de variables: saber qué es una closure sobre una o varias variables.
• Event bubbling/delegation: saber cómo se propagan los eventos del DOM, evitar que se propaguen, cómo hacer un listener en lugar de N y utilizar event delegation.
• Bases de HTML, CSS, selectores e interactuar con el DOM vía JS vanilla (navegar por el árbol del DOM con childNodes, parentNode, conocer setAttribute, getAttribute, append, por qué no usar document.write, por qué no usar eval, etc.
• Asincronía: qué es un callback, saber hacer y lanzar una promise, saber cómo async/await nos abstrae del callback hell y cuándo aplica.

Cosas que deberías saber bien para considerarte con buena base:

• Cómo funciona la cadena de prototipos en JS. Cómo funciona la instanciación, o el invocar a un método de un objeto. Si quieres, una vez sepas esto puedes combinarlo con patrones de diseño como factory, singleton, decorator, facade, etc.
• IIFEs, + closures y patrón de diseño module, muy útil. Típica preguntilla de entrevista: haz una función que la primera vez que sea invocada reciba un número, y lo devuelva incrementado en 1, y las siguientes invocaciones no reciba nada, y devuelva el último número que devolvió, incrementado de nuevo en 1. Sin variables globales.
• Entender cómo se ejecuta JS. Saber que hay un hilo por pestaña, que los serviceworkers y webworkers tienen su propio hilo, qué pasa cuando haces un setTimeout o un setInterval y cómo el tiempo que le pasas es un mínimo, pero no está garantizado. Saber cómo funciona la pila (stack) y el heap y cómo la pila de llamadas se libera completamente, a continuación se comprueba que no haya eventos/efectos pendientes de procesar (como un interval, o una llamada al servidor que termina) y cómo JS está orientado a estos eventos, ya sean del DOM/usuario o asincronía.
• Saber qué es variable hoisting. Cómo el intérprete/"compilador" de JS mueve todas las declaraciones de variables al inicio de una función o bloque, de forma que algo que defines 15 líneas más abajo puedes referenciarlo y en lugar de petar te dará undefined.
• Poder perfilar y analizar un poco el rendimiento de una web utilizando las devTools del chrome (o ff si quieres). Poder ver dónde tienes cuellos de botella en el renderizado por alguna función mal escrita o excesivamente lenta.
• Saber utilizar perfectamente promesas, Promise.all. Saber hacer llamadas con fetch, y hacer alguna con XmlHTTPRequest aunque sea por curiosidad.
• Entender cómo funciona HTTP, y qué hace HTTP2. Entender las requests y responses: headers, temas de autenticación / jwts, cookies, request bodies, subidas con form/multipart, etc.
• Haber tenido algo de práctica con websockets y tiempo real o pseudo-real. Implementar comunicación bi-direccional o iniciada por el servidor usando WS (algo que en lugar de responder sólo a interacción del usuario, también pueda ser iniciado por el servidor, como un chat, o notificaciones, sin polling).
• Saber usar generadores de ECMAScript.
• Manejar arrays y objetos con los ojos cerrados. Saber usar array.filter/map/reduce/flat/flatMap/find/slice/pop/push/indexOf/includes...
• Manejar strings con los ojos cerrados. Algoritmia en general. Expresiones regulares.
• Obviamente, y esto es genérico, soltura con estructuras de datos como árboles (saber hacer una búsqueda en o un aplanado de un árbol), manejar bien y sin miedo la recursividad, entender la complejidad espacial y temporal(cuándo un map con otro map puede ser una burrada que puedes solucionar de otra forma, o cuándo el utilizar el [...arrayOriginal] de las funciones puras en un forEach puede ser un desperdicio de memoria).
• Obviamente, estar familiarizado con la mayoría de las nuevas features y/o equivalentes en VanillaJS como object spread / rest parameters, que en VanillaJS podrías implementar como un Object.keys(obj)... y usar arguments en una función respectivamente.
• Entender cómo funcionan los eventos, listeners, cómo implementar un sistema básico de eventos.
• Seguridad. CORS. Qué es Cross Site Scripting. Qué es SQL Injection. Qué es CSRF. Políticas de seguridad: a qué puedes acceder de/desde un iframe. A qué dominios puedes llamar. Cómo funciona la petición pre-flight (HTTP OPTIONS) de CORS y sus cabeceras. A qué puede acceder un ServiceWorker o un WebWorker.
• ServiceWorkers.
• API postMessage.
• Manejar bien fechas, números, entender los errores de redondeos, diferencias entre undefined, null, type casting, lo típico y normal. Que no te pille por sorpresa que un !!miVariable sea false porque miVariable valga 0, "" o true porque sea []. Saber qué es !!miVariable.
• Y por supuesto, somos los de los node_modules de 500 megas. Saber usar librerías típicas. Aquí como los kanjis, con 2000-3000 vas bien. Conocer: fs/fs-extra, http, express, typescript, webpack, babel, jest/mocha/selenium/etc. - testing, eslint/prettier, d3, axios, jquery (esto para ñapillas y ya, proyectos grandes ni loco). Si vas con React/preact/react native seguramente redux(+redux-saga/redux-thunk)/mobx, prop-types, react-router. Si vas con Angular, no te sé decir pero TypeScript fijo.
• Entender un poco cómo funciona JS under-the-hood en el navegador. Qué operaciones sobre arrays o strings pueden ser un O(n) en lugar de O(1) porque requieren iterar sobre todo el array/string. Cuándo estás reasignando una variable, creando una nueva, creando una copia, y qué sucede con las referencias de éstas. Entender que hay un garbage collector, pensar en términos de ciclo de vida de los objetos y cuándo se pueden quedar referencias a objetos que no vas a utilizar, evitando que el gc pueda limpiarlas (pérdidas de memoria), etc.

Seguro que me dejo unas cuantas cosas más, pero creo que con esto tienes chapa para semanas o meses.

#22 La ha puesto #20 en #1 que está actualizando el hilo con links interesantes

#24

Yo estuve haciendo entrevistas hace poco para JS dev, y las preguntas que me encontré eran todas muy similares a las del enlace que #13 aportó.
Tienes que pensar que muchos de estos entrevistadores no tienen claro qué preguntar, sobre todo si es una empresa grande, entonces buscan en google que preguntar y al final acabas en ese tipo de preguntas.

#26

Pensé que te habías comido una R en entrevistado jajaja, sorry.

Yo diría que una indispensable, aunque no tiene que ser JS específica es:

Puedes decirme cómo es un día de trabajo para alguien en esta posición actualmente en la empresa?

#7 El doble de codigo donde? Yo trabajo en Typescript y si es verdad que debes de repetirle que tipo es cada puto pasito porque si no el imbecil del IDE se olvida, pero fuera de eso lo veo bastante parecido a C# por ejemplo