Este manual quiere que aprendas el 80% de todo JavaScript en 20% del tiempo

Si eres desarrollador o estás aprendiendo a programar y te interesa educarte en las bondades de JavaScript, uno de los lenguajes de programación más ampliamente utilizados más allá incluso del navegador, este manual te va a interesar.

[#1 alexwing]

Las bondades de JavaScript.... un lenguaje que hasta hace nada no tenía variables locales. Por lo demás interesante en los tiempos que corren no queda otra que usarlo.

[#2 pip]

JavaScript más allá del navegador es una abominación.
Y dentro del navegador, es porque no hay mejores opciones.

[#3 camvalf]

Donde este el cobol

[#4 Desactivado]

#3 Mejor el Basic de toda la vida...

[#5 Desactivado]

Joder menudo spam, no? Anda que no hay manuales en Internet no me jodas. Negativo al canto

[#6 camvalf]

#4 eres un viejuno

[#7 Desactivado]

#6 Imagínate que trabajé con diskettes de 8 pulgadas .... y que los primeros ordenadores con los que trabajé no tenían sistema operativo... Pero aquí estoy dando guerra....

[#8 pip]

#3 pues déjate...que los que quedan cobran fortunas por mantener legacy de la banca

[#9 Desactivado]

Hay muchos otros manuales que quieren inculcar Javascript de forma relativamente rapida. Todo depende en la capacidad de estructurar y resumir del autor.

Cuando he tenido que usar esta abominacion y actualizarme he recurrido a https://javascript.info/ .

Luego http://es6katas.org/ esta tambien bastante potable.

Es lo que tiene JS, mucha gente quiere ganarse la medallita por poner orden a "eso", y salen tutoriales chulos, a la par que nuevas revisiones del estandar donde maquillan al muerto mejor y mejor.

[#10 camvalf]

#7 no jodas y yo pensando que por haber extrenado un Spectrum 16 kb, que lo conservo con su caja y "to" ya estaba cerca del jurásico

[#11 camvalf]

#8 lo se, lo se

[#12 enrii.bc]

El principio de pareto

[#13 txeke]

#1 Cada lenguaje para lo que es. Hay por ahí lenguajes en los que tienes que direccionar la memoria a mano, y no por ello se denostan (pero a día de hoy yo no usaría C para una web)

De todas formas, por eso el tiempo pasa: para que las cosas mejoren. Que algo fuese malo hace tiempo no implica que lo siga siendo ahora (excepción hecha de Windows, claro está)

[#14 menjaprunes]

#1 un clásico: https://www.destroyallsoftware.com/talks/wat

[#15 nogates]

#2 claro! Por eso empresas como Amazon o Netflix usan NodeJS, que solo tienen unas pocas visitas y casi cero recursos para implementar otras soluciones.

[#16 txeke]

#2 Please, elaborate.

Lo que es una abominación es usar cosas como Java, con su VM, para ejecutarse en un servidor. O el monstruo que era (es) .Net antes de Core, parcheando un lenguaje/framework orientado a escritorio para usarse en web.

Edito: ojo, que yo no soy desarrollador JS (soy de backend, y por ahora no me tocó lidiar aún con Node más que para cosas sencillitas) pero lo que he usado de JS no me parece tan malo.

[#17 pip]

#15 Amazon y Netflix usan muchas cosas que van de C incluso ensamblador a JavaScript.
Digamos que usan todo.

[#18 Desactivado]

#10 Yo empecé bastante antes, hice algunas cositas con el Spectrum, era bastante divertido....

[#19 pip]

#16 no puedo elaborar tanto en un comentario de Menéame.
Java es abominable en rendimiento con máquina virtual, pero es mucho más decente como lenguaje que JavaScript.
Este es un lenguaje pensado para comprobar formularios que se ha forzado para hacer casi cualquier cosa con el.

[#20 BodyOfCrime]

#14 watman!

[#21 alexwing]

#13 no te digo que no, ahora mismo estoy haciendo una aplicación con react y electron, pero me parece un absurdo, cientos de megas de proyecto para una puta app de escritorio para 4 paginas de nada.

[#22 Mubux]

#12 Mal aplicado. No puedes aprender 80% de cantidad en 20% de tiempo, no tiene sentido, a no ser que aprendas solo las chorradas inutiles y dejes todo lo complejo y útil.

Querran decir que han seleccionado el 20% del lenguaje mas util y te permite hacer el 80% de las cosas.

[#23 Desactivado]

#3

El lenguaje del futuro. Todos los demás quedarán obsoletos y seguirán los mainframes de IBM.

[#24 txeke]

#21 Es que el tema de usar JS con todas esas librerías extra para una app de escritorio o móvil... pues tiene sentido cuando se quiere hacer un MVP con backend, pero una vez validado el MVP lo suyo es hacer la aplicación de verdad en escritorio y/o en móvil.

[#25 barni]

#2 te has dejado algún argumento por el camino. Bueno, mas bien todos los argumentos.

[#26 Desactivado]

#7

Los primeros OS son de los años 60 ... ¿no estarás exagerando un poco?

Otra cosa es que el OS fuera rústico de narices.

[#27 Desactivado]

#16 Referente a JS: tan solo su implementación asincrona ya es para darle de ostias a quien lo inventara.
Y por el leve tipado dos ostias más.

Por la cantidad de mierdas y problemas de JS salió TypeScript.

Es más, es tan a boleo lo que hacen que se han pasado años añadiendo la necesitad de punto y coma a final de sentencia y luego quitándola, en 2014 debías finalizar con punto y coma, pero no en 2016, luego si, pero a día de hoy no. Es una casa de putas.

Referente a Java si, mi problema con Java es su JVM pero también es su principal virtud. Y parece que con la incursión de .Net-Core Oracle ha decidido darle vida al lenguaje y liberar su desarrollo mejorarlo, el principal problema de Java se llamaba Oracle.

[#28 Desactivado]

No es mejor interesarse directamente por TypeScript?

[#29 barni]

#28 para entender TypeScript tienes que entender JS si o si.

[#30 Avengis]

#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/2">#2 La gente que criticais tan duramente a javascript seguramente no habéis probado las últimas versiones del lenguaje, especialmente a partir de la especificación ECMAScript6 el lenguaje dió un salto cuántico y a estas alturas compararlo con antiguas versiones es basicamente como comparar lenguajes distintos.

Sin contar además que a día de hoy han aparecido lenguajes de mas alto orden como Typescript, fuertemente tipado que recuerda a java o C#, que compilan en javascript, por lo que poco tiene que ver el panorama con lo que era hace tan solo unos pocos años.

Además lo que hace fuerte a javascript ahora mismo es la enorme comunidad y ecosistema que tiene detrás, la mayor seguramente de todos los lenguajes de programación.

[#31 FooDev]

Lo terrible de JavaScript (en el lado cliente) no está en su sintaxis o en las inconsistencias del lenguaje sino en su ecosistema.

El mundo front-end se ha convertido en una puta locura donde cada mes sale un nuevo framework/herramienta de despliegue/gestor de paquetería que lo va a revolucionar todo dejando obsoletos los anteriores.

Eso, y la manía de reinventar la rueda una y otra vez y volver a una mala praxis (como lo es por ejemplo entremezclar js con html, entre otros errores que ya habíamos superado).

[#32 abnog]

Yo desde que me he familiarizado con la programación funcional veo JavaScript de forma muy diferente, y me ha empezado a gustar.

[#33 txeke]

#19 Piensa en otros lenguajes que se pensaron para otras cosas y han ido evolucionando y mejorando... PHP era básicamente un apaño para hacer loops y manejar querystrings sin usar cgi-bin. O Delphi era un lenguaje pensado para enseñar a programar y hoy día hay bancos funcionando con eso. Si no recuerdo mal Python se creó con la idea de la docencia también, pero hoy día es el rey del big data junto con R...

Por otro lado, y esto es a la vez una ventaja y una jodienda, JS hoy día tiene varias implementaciones, y no es lo mismo usar Coffeescript que Ecmascript. Te doy la razón en que todo esto es un forzado del lenguaje para llegar a lo que se quiere hacer hoy día con él, pero yo no lo veo algo malo, al contrario, considero que es síntoma de que está vivo y puede crecer y mejorar hasta ser robusto y decente.

[#34 alexwing]

#24 es para algo visual, la otra opción es Unity o Adobe Air con ActionScript pero están empeñados en matarlo, cuando es el mismo puto lenguaje, o al menos la sintaxis Emacs es la misma.

[#35 Desactivado]

#30 A mi modo de ver lo que más fuerte hace a JavaScript es la comunidad de Node.JS, además de ser un lenguaje con una curvatura de aprendizaje fácil y un entorno de ejecución muy plug & play. No necesitas un servidor para empezar a programar ya que es lado cliente (excepto librerías de lado servidor). Esa rapidez hacen de Javascript un lenguaje muy versátil y como bien dices el salto desde ECMAScript6 ha sido muy bueno. Mi crítica en otro comentario viene dado pro la falta de estandarización y consenso de los desarrolladores y como bien dices, el leve tipado trae mucho de cabeza ya que es a mi modo de ver un sinsentido.

[#36 Drazul]

#21 es que el interprete de javascript que usa tu app, con electron, es un browser completo. Creo que es chromium.

[#37 blid]

#16 Por curiosidad, ¿con qué tecnologías tienes experiencia y cuánto en backend en un entorno profesional?

[#38 txeke]

#34 Yo creo que todos esos inventos vienen forzados por una industria que quiere curritos que haga a todo. Las empresas no quieren contratar a un experto en C++ Builder (o PyGTK para ser multiplataforma), otro en Android, otro en iOS y otro en web; quieren a un solo tipo que sea capaz de hacer la web, el backend, la app móvil y la de escritorio. Así que han aparecido inventos para que un desarrollador web pueda desarrollar una "web" ejecutable en escritorio.

[#39 anv]

Alguien me podría explicar a quién le puede parecer mejor o más intuitivo cambiar:

const foo = function foo()

por esto?

const foo = () => doSomething()

O peor aún, por esto?

const foo = param => doSomething(param)


O por ejemplo, esto:


setTimeout(function() , 1000)
}, 1000)

Que es cierto.. un timeout dentro de otro timeout puede parecer un poco enrevesado pero se entiende, pero... ¿habrán inventado una forma mejor de hacerlo?

const wait = () => new Promise((resolve, reject) => )
wait().then(() => )
.then(() => console.log('I promised to run after 2s'))


Pues no, no sólo es más largo sino que es ilegible a no ser que lo conozcas bien.

[#40 alexwing]

#36 si si, pero aparte de chromium, tienes un nodeJs completo, más las librerías de react, más otras mierdas varias, lo increíble es que la aplicaciones van sorprendentemente bien, de hecho Unity lo tuvimos que descartar por rendimiento.

[#41 Frezno]

#19 *cof cof cof cof cof cof cof cof * perdón, me atragantaba con la caspa de tu comentario.

[#42 txeke]

#37 He trabajado con .Net, .Net Core, PHP (Laravel y CodeIgniter), Java (Hibernate, Struts... hace ya bastante de eso), Perl (para web, ¡nunca más!) y C++. También, en el principio de mis tiempos laborales, con ASP-a-secas (VBScript). Actualmente trabajo con PHP-Laravel.

En total unos 15 años en la industria, los tres últimos como freelance.

Siempre hice backend. Puedo tocar HTML, CSS (y sus cositas asociadas tipo SASS, Bootstrap, etc) y JS (y las típicas librerías, y algo de React y de Meteor) pero mi creatividad es nula así que siempre me centré en el back.

[#43 Desactivado]

#1 las bondades de js,y lo que te deja guarrear,seguro que eres un puritano de python, ensuciate en el barro con js!

[#44 Desactivado]

#17 seguro que no usan lotus notes.

[#45 prejudice]

#1 Para eso está TypeScript (Que se transpila a JavaScript)
Y con Google (angular) y Microsoft detrás, posiblemente sea un lenguaje con mucho futuro

[#46 alexwing]

#c-43" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/43">#43 que va Python no lo he tocado en mi vida, mi lenguaje preferido es c#, pero la mayor parte de mi vida profesional se la ha llevado PHP, ActionScript, Java y JavaScript por ese orden.

[#47 Desactivado]

#19 Java es abobinable,pues nose ,ponte a programar en PHP algo con una complejidad elevada,o con C y olvídate de liberar memoria,Java rules,porque Java es fácil de aprender e implementar,y en eso no le gana nadie,luego ya no hablaremos de malas practicas de programadores,mala optimización del código,no usar el multithreading(o peor,usarlo mal)

[#48 RubiaDereBote]

#38 Esos inventos (como los llamas) están diseñados para hacerte la vida más fácil, para ahorrarte tiempo y para ayudarte a cometer menos errores. Si quieres ponte a picar con pico y pala pero si hay un martillo neumático y no lo usas es tu problema, no intentes ver fantasmas donde no los hay.

[#49 RubiaDereBote]

#2 webasembly

[#50 borteixo]

#19 lenguaje pensado para comprobar formularios
in yor feis

[#51 Desactivado]

#8 esos son los privilegiados,que han pillado un buen sitio,hay miles igual en cárnicas,cobrando igual que cualquier currito de otro lenguaje.

[#52 RubiaDereBote]

#17 ensamblador no usan y c tampoco (al barro no bajan porque hoy en día no es necesario, les sale más rentable escalar horizontalmente o verticalmente en infraestructura que meterse a programar algo que les durará meses, estará plagado de errores, se les complicará mantenerlo y el día que se vaya quienes lo hayan hecho... problemón). Netflix basa todo su rendimiento en la infraestructura de aws. Para la parte de negocio batallan como todo hijo de vecino con soluciones de alto nivel. Cada cierto tiempo sacan artículos de cómo han hecho un cambio en js que ha hecho mejorar la cosa y cosas del estilo. (hay varios publicados). Donde más tiempo gastan es en aws, incluso han liberado algun proyecto para automatizar procesos en aws.

[#53 Desactivado]

#46 PHP da sida,sobretodo cuando es algo muy complejo....Js tiene sus cosas,pero bueno,no es tan malo.

[#54 Rydra]

#39 para los que estamos acostumbrados y avezados a la programación funcional, foo = param => doSomething(param) nos parece claro y conciso (expresiones lambda de una sola línea.

El const por eso me sobra. De hecho algo guay que tiene python es que no puedes definir lambdas de más de una línea por diseño (y una vez entiendes el por qué... Lo ves como una bendición y buena praxis)

[#55 alexwing]

#45 lo probé con la librería JavaScript para juegos phaser, vi que tenía mejor tipado pero no le llegue a coger el punto. Eso sí solo por usar visual studio merece la pena.

[#56 borteixo]

#42 si no pones foto de perfil no te van a llamar para la oferta.

[#57 pip]

#52 si que usan ensamblador, poco pero hay. Los códecs de video en el lado del server no van en JavaScript

[#58 Desactivado]

#1 ¿? Javascript siempre ha tenido variables globales y locales...

[#59 Desactivado]

#2 Perdón, ¿y NodeJS?

[#60 mninm]

#51 Y sin posibilidad de escapatoria,más que a otra cárnica similar

[#61 pip]

#47 mi trabajo diario es normalmente en C.

[#62 RubiaDereBote]

#57 Los codecs van en binario, porque han sido compilados, pero no porque se hayan programado en ensamblador. Y los vídeos están almacenados en S3. Y por otro lado ni siquiera los han desarrollado ellos. Lee más sobre netflix porque te veo un poco perdido. Netflix solo ha tenido mucha suerte desde un punto de vista comercial, técnicamente es muy malo, desde un punto de vista de usabilidad también es muy malo, ... y consiguen el rendimiento gracias a la infraestructura y la ayuda de aws (donde tienen a varias personas asignadas para ellos).

[#63 alexwing]

#58 no, siempre han sido accesibles en el DOM ergo no son locales.

[#64 pip]

#62 mírate el código fuente de los códecs de video en Internet, por ejemplo los de FFMPEG (que usa Netflix) o GStreamer, busca tu mismo el ensamblador, y mira tu mismo los comits de parches y verás si son "un estándar" o se cambian constantemente.

[#65 RubiaDereBote]

#64 Netflix no ha desarrollado ningún codec y mucho menos en ensamblador. Usa VP9 y H264

[#66 Desactivado]

#29 no es inclusivo? vull dir, aprendiendo TypeScript no aprendes también las bases de JavaS?

[#67 solotexto]

Yo es que no uso lenguajes para fracasados.

[#68 anv]

#54 Yo lo que estoy viendo es que nos estamos alejando cada vez más de lo que se buscaba en un principio, que era que las cosas sonaran más o menos naturales.
Si me pones:
foo = param => doSomething(param)
yo intuitivamente pienso "foo = param" ? quiere decir que están asignando el valor de param a foo? Entonces foo es una variable? y después leo "implica o señala" doSomething(param), aja... pareciera llamar a la función do something con el parámetro param... pero entonces por qué lo asignaro a foo? A no ser que no lo estuvieran asignando. Tal vez estaban "afirmando" que foo equivalía a param. ¿o sería una comparación?

Por otro lado, cuando pones:

function foo(param)

queda clarísimo que estás creando una función llamada foo, que recibirá un parámetro y que ese parámetro se transferirá a la función doSomething().

A mi me gustó cuando aprendí hace muchos años Pascal. Un lenguaje que cualquiera que sepa programación, sin saber nada del lenguaje, puede leer y entender a demás de ser un lenguaje de nivel bastante alto pero con funciones de bajo nivel si hacen falta. Que no necesita punteros como el C pero los tiene si los quieres usar. Donde el compilador valida cada tipo de datos y no te deja cometer errores y a demás que compila en una sola pasada así que la compilación es increíblemente rápida. Pero sobre todo lo que mejor me parece de ese lenguaje era la legibilidad. Hay que teclear más pero a cambio el programa se puede entender y mantener fácilmente.

En ese sentido me sinpatiza bastante Python aunque tengo pendiente hacer algo en serio con él para aprender de verdad.

[#69 Desactivado]

#1 #43 JS vs Python... Pelea de inválidos!

[#70 solotexto]

#56 A lo mejor se postula para una oferta de trabajo de fuera de España.

[#71 borteixo]

#70 esperemos, porque sin "proactivo" y palabras molonas no tiene ningún futuro.

[#72 centelleante]

#48 Psé, algo de razón sí que tiene #38 (aunque ha errado en las tecnologías mencionadas, el estándar de facto en GUI multiplataforma es Qt, no GTK). Un desarrollo en C++ y Qt va a ser menos propenso a errores que un proyecto en React por muchas razones, como que Qt es un framework más maduro, o que el paso de compilación ya da cierta garantía de la validez del código, cosa que en lenguajes interpretados y/o débilmente tipados no ocurre.

[#73 Desactivado]

#34 ¿No os sirve Qt? Yo lo he usado mucho, y estoy encantado.

[#74 scalvo]

#45 Typescript es ES6 con anotaciones para tipos.... nada más.
De hecho, puedes pasar de escribir los tipos y son prácticamente lo mismo.

[#75 Desactivado]

#64 Que yo sepa ffmpeg ya existía décadas antes que Netflix... Que usen una API existente no tiene nada de especial. Todo lo contrario, demuestra que es una empresa "del montón" tecnológicamente hablando, que se aprovecha del open source a la chita callando para llevarse el mérito.

[#76 Desactivado]

#63 mmm... no que yo recuerde. Si defines una variable en un constructor no es accesible en el DOM, a menos que lo hagas usando "this.[etc]". (Y diría que dentro de una función tampoco, solo que debes declararlas con "var").

[#77 dospuntoswq]

#21 Ese no es un problema de JS, es un problema de electron. Y sí, cualquier chorrada en electron son cientos de megas, pero es que desgraciadamente hacer una aplicación multiplataforma con interfaz gráfica sigue siendo muy complicado en 2018

[#78 delsegura]

#21 Cambiate a Vue.js
React es pasado! es tan poco ... cool

[#79 Desactivado]

#13 ¿Desde cuando en C se direcciona "a mano" la memoria?

[#80 Desactivado]

#38 Yo creo que todos esos inventos vienen forzados por una industria que...
Y yo creo que vienen forzados por unos Illuminati que...

Ahora en serio, si por "Industria" entiendes grandes corporaciones, a ellos se la suda. De hecho cuanto más desarrolladores especializados y aplicaciones específicas para cada entorno se necesiten, más van a poder facturar.

Somos los pequeños desarrolladores autónomos los más beneficiados de estos sistemas unificados, ya que nos permite competir con la "Industria" al requerir menos recursos.

[#81 Martull]

#14 Caray, mi primer vez. Buenísimo

[#82 almeriensis2016]

#3 Hotia, otro de los míos.

[#83 pip]

#65 #75 las "APIs" hay que adaptarlas y mantenerlas para usos serios. Tú no tienes la infraestructura de Netflix con los códecs mainstream de ffmpeg. Os equivocáis mucho. Probablemente hasta adapten el Kernel también.

[#84 alexwing]

#78 Joder macho, si me quedo dormido ya estoy desactualizado.

[#85 theM]

#39 No es mejor o peor, es distinto
La función flecha (=>) no cambia el contexto, así que "this" sigue siendo lo mismo que fuera de la función, mientras que en la definición clásica cambia. Para muchas cosas es mejor.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions

[#86 dreierfahrer]

#27 Javascript es TAN MIERDERO que cuando mas aceptacion tiene es cuando se inventan lenguajes que se pueden 'compilar' a javascript para NO programar en javascript

[#87 Desactivado]

#83 Los "probablemente" no tienen cabida en programación, o lo hacen o no lo hacen. Y si no hay artículos x ahí o algo que lo demuestre, "probablemente " sea falso.

[#88 alexwing]

#c-73" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/73">#73 Lo use hace mucho tiempo, QT 4 + C# una gozada aunque aún estaba algo verde.

[#89 dreierfahrer]

#78 Otra de las cosas divertidas de JS:

La fiesta de los frameworks que son la ostia.

Tengo yogures en la nevera con fecha de caducidad mayor que el 90% de los frameworks de JS

[#90 dospuntoswq]

#27 que hay de malo en usar libuv? El tipado estricto es sólo una herramienta más; tiene sus ventajas y desventajas. Erlang tampoco lo tiene y no creo que nadie se atreva a calificarlo como lenguaje inferior.

[#91 delsegura]

#84 A mi casi me pasa el tren por encima. En pocos meses en la empresa:
de React a Vue, Docker, Kafka, menos mal que el backend sigue siendo Rails

[#92 manson2000]

#76 Coincido.

[#93 delsegura]

#89 Agarraros los machos que REST también prehistoria.

[#94 montaycabe]

Logo es el futuro, el concepto de la tortuga es revolucionario y no lo tiene ningun otro lenguaje

[#95 Desactivado]

#c-47" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/47">#47 Y no se te olvide, sobre todo java (y c#) es muy fácil de reutilizar. El sistema de paquetes, el de herencia, ahora también el de módulos y el hecho de que sea multiplataforma es una cuestión a tener en cuenta.

Para aplicaciones de gestión con montones de tablas, montones de formas de interactuar (escritorio, formularios web, APIs REST, etc), y necesidad de generación de código a partir de diseños formales no hay hoy en día nada mejor.

[#96 KaborlllLLLONE]

#63 No.

[#97 Desactivado]

#c-88" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/88">#88 Con C# no lo he probado, yo empecé directamente con Qt5 y C++ y me encanta. Una de las cosas que tengo pendiente es aprender QML, a ver si merece la pena.

[#98 Rydra]

El documento en general está bien para aprender rápidamente la sintaxis y constructs de javascript, aunque he echado de menos cosas que realmente te enseñan y son necesarias para el día a día (y que es lo realmente difícil): testing frameworks como Jasmine o Protractor (demasiados programadores sin conocer el concepto de unit testing...), arquitectura y buenas prácticas de código limpio.

En ese aspecto relacionado con Python, the Hitchhiker guide to python ha hecho mejor trabajo (para mí).

[#99 Desactivado]

#53 Yo los lenguajes dinámicos los veo todos igual de cancerígenos. Espero que WebAssembly prospere y podamos dejar atrás JavaScript.

[#100 KaborlllLLLONE]

#68 Te suena raro porque no estás acostumbrado a leer código de un lenguaje del paradigma funcional, que es totalmente diferente del imperativo. La forma de programar en un paradigma es muy diferente respecto al otro. En cualquier caso, JS no es funcional sino imperativo y aunque hay gente que intenta usarlo como tal se encuentra con situaciones que lo que hacen es complicarse la vida de mala manera. Esa sintaxis está pensada para solucionar otros problemas que la sintaxis anterior tenía con el "contexto actual" (this).

Sobre lo de las Promises, discrepo muchísimo. El callback hell de JS es desafortunadamente una realidad y un horror.

DISCLAIMER: Que esa sintaxis sea común en los lenguajes funcionales no hace a JavaScript funcional. Hay gente que confunde paradigma funcional con "usar funciones" y eso simplemente muestra un desconocimiento profundo de ambos mundos.