[Javascript] Hilo General

Zoko

Hilo General de Javascript (Typescript welcome too)

Bueno, sé que en este subforo es un meme recurrente decir que JS es una mierda y que no debería ni ser considerado lenguaje de programación, etc, etc... Pero dejando a un lado las bromas de vez en cuando se ve que hay bastantes usuarios del foro que lo usan en su día a día (yo incluido), y creo que puede tener algo de valor tener discusiones o comentar sobre cosas relacionadas con el lenguaje en un hilo propio, como por ejemplo ya tiene Python.

JS in the Frontend

Enlaces útiles

Repo de Front-end Developer Interview Questions, interesante para prepararse entrevistas y repasar conceptos

JS in the Backend

JS General

Posts de MV Users

#13 - EnderFX propone un "temario" para gente que quiere ahondar en Javascript, muy completo.

@EnderFX aporta un hilo en el que explica como funciona JS por detrás, hablando de Call Stack, Event Loop y Stack Heap.

Enlaces útiles

TC39 - Los encargados de especificar JS e incorporar nuevas features
You Don't Know JS - Libro muy interesante que te hace replantearte como de bien sabes JS
Typescript - Web Oficial
Just Javascript - Side project de Dan Abramov (alabado sea el señor) como lista de correo para repasar conceptillos

Cualquier aportación o "critica constructiva" es totalmente bienvenida, pero preferiría que los trolls a los que no les gusta JS inviertan su tiempo en otras cosas, veremos si es mucho pedir.

3
VonRundstedt

Perfect timing para este thread, justo hoy he empezado el Curso de Javascript de Colt Steele en Udemy, estaré por aquí lurkeandoos :ninjaedit:

Edit con el link por si a alguien le interesa, de momento muy recomendado:
https://www.udemy.com/course/javascript-beginners-complete-tutorial

Wasd

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...

1 2 respuestas
MrBigel

#3 ¿Por qué TypeScript? No creo que sea para tanto.

1 respuesta
Zoko

#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.

1 respuesta
Wasd

#4 Yo pienso que sí es para tanto. Poder traer algunas de las bondades de los lenguajes tipados a Javascript me parece genial, además a nivel de sintaxis se asemeja a Java o C# (este ultimo para mi de lo mejor en cuanto a sintaxis).

El repo de TypeScript tiene +60k stars y por ejemplo el creador de node (ahora desarrollando deno) ya lo hace pensando en TypeScript, o en Angular directamente está pensado para ser usado mediante TypeScript. Somos unos cuantos a los que nos gusta xD

#5 Precisamente a nivel profesional es donde mas noto las bondades de TypeScript, por ejemplo si he creado un component de React que requiere una estructura de datos relativamente compleja, un compañero que lo use no tiene que entrar a mirar qué se espera, sino que lo tiene definido todo de forma "nativa", o en un ORM en backend, definirles a las entidades los tipos de datos que se esperan. Por no hablar del type hinting de cualquier librería, que te dice qué te devolverá, qué tipos de parámetros se espera, y muchos mas casos donde nos ha ido muy bien.

A día de hoy no volvería atrás...

2 3 respuestas
kidandcat

#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.

1 respuesta
Zoko

#6

Justo el caso que me comentas de un componente de React está "solucionado", y recalco el entrecomillado, con las propTypes. Pero obviamente saliendo de ese caso específico aporta muchísimo más, y creo que es probablemente hacia dónde JS evolucionará.

Dicho eso tampoco me gusta en exceso la gente que usa TS y tira por tierra JS, jajaja

Creo que como todo en la programación, depende del contexto.

1
SupermaN_CK

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.

1 1 respuesta
Zoko

#9

No creo que haga falta saber del lenguaje muchísimo para empezar un hilo eh, realmente lo que estás haciendo es abriendo un punto de encuentro para que la gente hable sobre ello, no para dar clase jaja

2
EnderFX

#6 Perspectiva ante todo, por favor. Y saber dónde meterlo y dónde no. Y objetividad. Tienes decenas de posts también hablando de las carencias o puntos débiles de TypeScript, y en mi experiencia los primeros días es un dolor de orto horrible, aunque por supuesto tiene sus cosas buenas.

Los beneficios son muy buenos, es una gozada, te da mucha seguridad, pero yo también pienso que además de tener a mano TS conviene aprender a usar el lenguaje, saber por qué usamos o qué evita TS, manejar tipos de datos con soltura y tener claro como el padre nuestro las comparaciones por referencia y por valor.

Y, por último, nunca olvidemos que por mucho TypeScript, Webpack y Babel que usemos, el navegador sólo entiende JS, y al final lo que se genera es JS, con más o menos transpilado dependiendo de la versión del estándar objetivo, pero solo JS (y un poquito de WASM, puede).

1
smarquezp

Después de estudiar JavaScript y JQuery durante todo un año en DAW, quiero ampliar conocimientos con algún curso en estos días. Relacionado con éste, ¿qué me recomendáis estudiar? Tal vez seguiríais con algo tipo de librería como React o tiraríais por otras cosas?
La verdad es que estoy un poco perdido ahora que he terminado todo y quiero verme cosas por mi cuenta.

Muchas gracias!!

2 respuestas
EnderFX

#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.

:thumbsup:
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.

:ok_hand:
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.

17 5 respuestas
Zoko

#12

Cuando estuve buscando en Noviembre mi nuevo empleo, venía de haber hecho React y muchas otras cosas durante el ultimo año y medio. Desde siempre he sido full-stack pero creo que quería dar el paso solo a frontend, así que me puse a ello.
Me puse a "estudiar" por mi cuenta y a hacer proyectos personales. Pienso que estudiar la teoría está muy bien, pero como más aprendes es cacharreando.

El caso es que el "temario" que me preparé tenía una pinta similar al 98% a lo que te ha puesto #13 , hay conceptos MUY interesantes ahí y que deberías saber si o si, como los closures, la asincronía, el saber hacer "herencia" usando prototypes (o sin ellos)...

Encontrarás la mayoría de cosas en el enlace que puse en #1 , You Don't Know JS., y tambien echale un vistazo a los posts de Eric Elliott como este, tienes varios:

https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-closure-b2f0d2152b36

Para mi fueron realmente claves para empezar a saber lo que estaba haciendo y no sólo ver que las cosas funcionaban.

Btw, #13, se te puede preguntar donde curras?

2 2 respuestas
EnderFX

#14 ahora mismo en el BBVA, pero el 1 de Agosto empiezo en AWS en Berlín

1
Lord_Khronus

#13 Trabajo de frontend y la mitad me suena a chino y la otra mitad porqué me compré un curso de js de Wes Bos. El problema es que en mi día a día apenas uso nada de eso y no aprendo nada.

1 respuesta
EnderFX

#16 Yo llevo 6 años picando RIAs, primero con ExtJS, ahora con React, y la mayoría de esas cosas las he usado y/o necesitado estos últimos años. Bien es cierto que algunas de ellas no las usas a diario, pero creo que son más o menos generales. Otra cosa es que se pueda tirar sin ello. Hay gente en mi equipo que aún no entiende bien valor vs referencia o cómo funcionan las referencias a los objetos en JS, y tiran vistas en proyectos. Otras, como el patrón modulo o IIFEs, puedes usarlas o no, pero son bastante ubicuas hoy en día. El CORS lo necesitarás cuando tengas que llamar a otra API externa y no tengas JSONP, el hoisting la gente no sabe que existe hasta que no le empieza a j*der en alguna función, la cadena de prototipos hasta que necesitas implementar una herencia un poco compleja o ver de dónde sale una función existente en un objeto, etc.

Técnicamente, manejando el DOM y sabiendo hacer 5 funciones puedes empezar a hacer cosillas, pero como las haría yo en Python, que funcionan pero no tengo NPI si se puede hacer de manera mejor o si el código está siquiera bien estructurado.

3
smarquezp

#13 Lo primero de todo, muchas gracias por dedicar una parte de tu tiempo en escribir y detallar cada uno de los puntos escritos.

He estado leyendo detenidamente y he pensado: "No tengo ni idea!". Hay muchos de los conceptos y procesos que me indicas que me suenan de haberlos visto nombrar por ahí pero que no se ni lo que hacen, y veo que lo que yo tengo como tal es una base de todo lo que se puede abarcar en un lenguaje.

Ya se lo que tengo que hacer y me pondré a leer e intentar aprender cada uno de esos conceptos que ya me servirán también para la programación en general.

#14 Sobre lo de los proyectos, he estado desde que terminé de presentar mi proyecto final trasteando un poco y haciéndome mis pequeños trabajillos mientras intentaba aprender un poco, aunque de todas formas, no he mirado nada nuevo.

Tengo que darle caña y empezar a estudiar de nuevo, a ver si pronto me puedo pasar por aquí y decir que ya tengo claro todo eso!

Muchas gracias por las respuestas!

1 respuesta
EnderFX

#18 No hay de qué :). Como he tenido que prepararme unas cuantas entrevistas hace poco, el mes pasado hice bastante recap de estos últimos años y lo tenía bastante fresco.

Para tenerlo a mano, y para el resto de frontenders, este Github tiene una lista extensa de preguntas que te pueden hacer en una entrevista de front algo complicada. Puedes volver a ella cada X meses, por ejemplo a la parte de JS Questions, y ver cuántas eres capaz de ir respondiendo.

Vamos, es lo que usaba yo como referencia para preparar la parte técnica, sobre todo poder responder más o menos a todas las de JS, Network, HTML y algo de CSS.

PD: sobra decirlo, pero si tienes dudas de algo no dudes en preguntar ya sea por aquí o por privado.

2
Zoko

Actualizado #1 con enlaces y posts interesantes.

Más adelante si el hilo tiene tracción podemos hacer una pequeña encuesta de en que curramos cada uno (front/back) y tal, al menos a mi me parece interesante ver en qué andan los demás users de MV que hacen JS.

2 respuestas
Lord_Khronus

#20 https://wesbos.com/courses

Wes Bos tiene varios cursos (de pago) que están bastante bien.

RedSpirit

#13 Esta lista me parece oro puro, sobretodo para preparar entrevistas. Molaría que la linkasen en el OP para que no se pierda con el tiempo.

Rollo preguntillas quiz de Javascript, me gustó mucho este repo porque son pequeños ejercicios de diferentes niveles de dificultad. No podría decir hasta que punto las respuestas que dan son rigurosas, pero sabiendo que siempre hay que referenciarse en otro tipo de recursos, me gustó mucho:

https://github.com/lydiahallie/javascript-questions

1 respuesta
EnderFX

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

1 1 respuesta
isvidal

#23 ¿Qué preguntas técnicas harías como entrevistado en una una entrevista técnica para una posición de JS dev?

2 respuestas
Zoko

#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.

1 respuesta
isvidal

#25 No me has entendido, las preguntas que harías TÚ como entrevistado.

1 respuesta
Zoko

#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?

1 respuesta
Wei-Yu

Yo tengo curiosidad por saber las preguntas específicas sobre tecnología que se podrían hacer desde la parte del candidato. Todas las que se me ocurren son, como mucho, relativas a las actualizaciones de las libs/frameworks/herrramientas o por qué herramientas específicas usan más que algo particular del lenguaje.

JohnVoiden

#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

1 1 respuesta
kidandcat

#29 C# te infiere tipos en todas partes, con omnisharp el autocompletado es de verdad (no tienes que darle a ctrl+espacio y esperar 10 segundos), y lo de siempre, el tipado fuerte no es opcional (lo que no quiere decir que tengas que tipar manualmente todo, sino que todo tiene su tipo inferido.)

Tambien creo que es un poco por cómo funciona el ecosistema JS, en JS las funciones se pasan por todas partes, se anidan en propiedades, y se hacen estructuras bastante complejas (que sean necesarias o no ya es otro tema de discusión). Al hacer eso, cuando te pones a tipar una funcion con 3 niveles de currifying . . . lloras

1 2 respuestas