EDICIóN GENERAL
336 meneos
11436 clics
Este manual quiere que aprendas el 80% de todo JavaScript en 20% del tiempo

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.

| etiquetas: javascript , educarte , manual
Comentarios destacados:                        
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.
#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á)
#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.
#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.
#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.
#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.
#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.
#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.
#72 A eso iba yo, no me supe explicar bien. Cierto, es PyQt, no GTK... hace muchos años que no toco nada de escritorio, se nota, ¿no? jejeje
#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.
#80 Pues es otro punto de vista interesante...

Yo lo decía porque estoy harto de ver ofertas para "full stack developer", que lo que significa es que tú solito te tienes que currar el front dinámico con Angular o React, el back, la app móvil para dos o tres plataformas y si te descuidas, la app para smartTVs.

En los últimos años como freelance lo que he hecho ha sido colaborar con otros pequeños desarrolladores autónomos: en un proyecto yo me encargo del back, otro del front, y un…   » ver todo el comentario
#38 para eso existe Xamarin.Forms (con su bridge Ooui para navegador), pero nadie parece estar usandolo...
#38 La gente que no sabe programar se te va a quejar, e incluyo los que scriptean en javascript.
"No hay que reinventar la rueda" dirán los que no saben ni que forma tiene una rueda.
#34 ¿No os sirve Qt? Yo lo he usado mucho, y estoy encantado.
#73 Lo use hace mucho tiempo, QT 4 + C# una gozada aunque aún estaba algo verde.
#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.
#34 No son opciones similares. Adobe Air utiliza una máquina virtual.

Es cierto que requieres más recursos. Puedes usar kotlin para transcompilar a js y dentro de nada a nativo multiplataforma. Perfecto el proyecto es más grande...

Pero con un ordenador de 16gb y un i7 me importa un pepino el tamaño de las librerías. La tecnología está para hacerle la vida fácil a la gente, en este caso los desarrolladores.
#21 es que el interprete de javascript que usa tu app, con electron, es un browser completo. Creo que es chromium.
#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.
#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
#21 Cambiate a Vue.js
React es pasado! es tan poco ... cool :-D
#78 Joder macho, si me quedo dormido ya estoy desactualizado.
#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
#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
#89 Agarraros los machos que REST también prehistoria.
#13 ¿Desde cuando en C se direcciona "a mano" la memoria?
#79 Un puntero sería una dirección de memoria puesta "a mano", no? Si pones un número al azar y sigues ese puntero te casca el programa casi con toda probabilidad.
También para recorrer un array de "objetos" (más bien structs) puedes guardar el puntero a la cabeza y vas sumándole el valor de lo ocupa el "struct" que contiene y así accedes a los diferentes campos que contiene.
#79 desde que aprendes a "jugar" con los punteros.... Aunque no tienes perquè hacerlo, claro.
#79 se dice que en un lenguaje la memoria se direcciona a mano, cuando el programador puede controlar a que dirección de memoria apunta una variable de forma arbitraria, e incluso usando aritmética en las direcciones de memoria.

Eso no solo es posible en C, sino que muy habitual y necesario para ciertos casos.
#14 Caray, mi primer vez. Buenísimo :-)
#14 20 veces te votaba esto xD
#1 las bondades de js,y lo que te deja guarrear,seguro que eres un puritano de python, ensuciate en el barro con js!
#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.
#46 PHP da sida,sobretodo cuando es algo muy complejo....Js tiene sus cosas,pero bueno,no es tan malo.
#53 Yo los lenguajes dinámicos los veo todos igual de cancerígenos. Espero que WebAssembly prospere y podamos dejar atrás JavaScript.
#53 Discrepo, normalmente el problema no es el lenguaje sino el programador. Evidentemente PHP tiene sus limitaciones y sus usos concretos, no vale para todo, pero sida...

Por otro lado JS, hay que decirlo, hace unos pocos años estaba bastante jodido, pero ahora con el Ecmascript 6 y el Typescript consigue que el proceso de desarrollo no sea tan doloroso.
#134 #53


PHP esta muy extendido debido en parte a la facilidad y bajo coste de deploy.

Si trabajas para una empresa, mediana+ no tendras problemas con los costos de infraestructura que supone tener servidores propios como Tomcat, WildFly, deploys en pyhton con o hasta ISS, pero si desarrrollas para pequeñas empresas o particulares, muchas veces no suelen tener infraestructura y pueden no querer pagar un VPS que ademas les va a requerir mas administracion.

Ahi es cuando PHP &qu…   » ver todo el comentario
#53

PHP da sida,sobretodo cuando es algo muy complejo

Puedes argumentar esta respuesta, o es solo un comentario sin fundamento?
#1 #43 JS vs Python... Pelea de inválidos!
#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
#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. :-D
#55 Puedes seguir usando el VSCode para JavaScript.
La verdad es que hay que quitarse el sombrero. VSCode es una delicia (Aunque sea de Microsoft)
#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.
#74 Lo de los tipos es una diferencia muy gorda, sobre todo en aplicaciones empresariales donde necesitas que todo esté bien armado para evitar sorpresas a medio plazo. A parte, el tipado ayuda al IDE con el autocompletado.
#74 Si obvias los decorators, la existencia de interfaces (lo cual hace que puedas hacer SOLID), el dependency injection, que tiene scope de clase y no solamente el global y local, los modificadores para public private protected y readonly, ... sí, efectivamente son prácticamente lo mismo, si consideras que C# y ES6 son prácticamente lo mismo, porque typescript está más cerca a nivel de lenguaje formal de C# que de ES6.
#1 ¿? Javascript siempre ha tenido variables globales y locales...
#58 no, siempre han sido accesibles en el DOM ergo no son locales.
#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").
#76 Coincido.
#76 Depende de si expones o no esas variables como miembros del objeto, o privilegiadas a través de funciones que te permitan obtener o cambiar el valor de las mismas.
También puede en un closure el hoisting te juegue una mala pasada (si no las declaras con var - o let en los casos que sean de aplicación).
#1 Es increíble que te voten positivo. Esto no hace más que demostrarme que la gente no sabe programar en JavaScript y después viene a Menéame a quejarse de cosas que simplemente no deberían hacerse en ese lenguaje.

Veo mucha ignorancia en los comentarios. Joder que triste.
#1 Javascript tiene variables locales desde siempre, ej. librosweb.es/libro/javascript/capitulo-4/ambito-de-las-variables.html
#1

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.

¿Quien te ha dicho tal mentira?

If the variable statement occurs inside a FunctionDeclaration, the variables are defined with function-local scope in
that function, as described in section 10.1.3. Otherwise, they are defined with global scope, that is, they are created
as members of the global object, as

…   » ver todo el comentario
JavaScript más allá del navegador es una abominación.
Y dentro del navegador, es porque no hay mejores opciones.
#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.
#15 Amazon y Netflix usan muchas cosas que van de C incluso ensamblador a JavaScript.
Digamos que usan todo.
#17 seguro que no usan lotus notes.
#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.
#52 si que usan ensamblador, poco pero hay. Los códecs de video en el lado del server no van en JavaScript :-)
#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).
#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.
#64 Netflix no ha desarrollado ningún codec y mucho menos en ensamblador. Usa VP9 y H264
#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.
#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.
#65 aquí tienes el código fuente ensamblador de codecs H264 y VP9 entre otros, de FFMPEG

git.videolan.org/?p=ffmpeg.git;a=tree;f=libavcodec/x86;hb=e64e079ece7d

Son todos los *.asm .
#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.
#62 Netflix utiliza AWS sólo para la parte del portal, todo lo que es el catálogo y demás, pero una vez que empiezas a reproducir pasas a usar su arquitectura propia. Y la infraestructura de Netflix es enorme, llegan a acuerdos con los ISP para montar sus servidores directamente en los datacenters de estos últimos. Sí, los vídeos maestros se almacenan en S3, pero de ahí se distribuyen a todos sus servidores por el mundo, y lo que a ti te llega a tu casa no viene de S3. Sobre los codecs, han…   » ver todo el comentario
#17 #15 Dejando de lado las plataformas de dispositivos (Alexa/Echo, Kindle, FireTV), Amazon es mayormente Java, diría que en un 90%. Luego hay una cantidad considerable de JavaScript y TypeScript, y scripting en Python y Ruby. En resumidas cuentas, hay de todo menos PHP.
#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.
#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.
#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…   » ver todo el comentario
#33 pero esa es precisamente una de las cosas que lo hace abominable, que cambia constantemente.
¿Te imaginas tener una base de código de pongamos 1 millón de líneas de JavaScript? ¿Cómo estará dentro de 10 años? ¿Y de 30? ¿Cómo mantienes eso, con qué garantías?
El Kernel de Linux tiene 25 millones de líneas de código C que tienen casi 30 años, porque C es extremadamente estable y bien estandarizado.
#19 *cof cof cof cof cof cof cof cof * perdón, me atragantaba con la caspa de tu comentario.
#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)
#47 mi trabajo diario es normalmente en C.
#61 anda que no se nota los que desarrollamos a diario C/C++... te lo noto en los comentarios a la legua. Deja a los niños con su JS y el framework de moda de la semana ;)

No , ya en serio. Me preocupa quién va a programar cosas serias en el futuro, las nuevas generaciones cada vez están más lejos del hardware y todo lo que hay por ahí abajo, qué pena... Las empresas cada vez pagarán más por los que quedemos, eso sí {0x1f602} {0x1f602}
#61 #121 lo único que tengo que añadir,es que no hay curro de C para empezar como junior, todos los "nuevos" acaban haciendo programación de alto nivel,que es lo que tiene mas salida.
#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.
#19 lenguaje pensado para comprobar formularios xD xD
in yor feis
#19 Eso de que la maquina virtual tiene mal rendimiento suena muy a principios del 2000. Creo que deberias actualizarte.
#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.
#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 xD
#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.
#90 no hablo de usar una librería para dotar de asíncronía a la implementación si no que la implementación de JavaScript(ECMAScript6 ) es por defecto asíncrona y no controlas la ejecución de eventos a no ser que implementes el event.preventDefault() y personalmente creo que debería ser al revés, por defecto sincronía y si lo necesitas asíncrono.

Otro ejemplo y quizás patino es que por defecto la carga de scripts no es en paralelo y como pete uno se lleva a toda la página por delante.
#16 Por curiosidad, ¿con qué tecnologías tienes experiencia y cuánto en backend en un entorno profesional?
#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.
#42 si no pones foto de perfil no te van a llamar para la oferta.
#56 :troll: A lo mejor se postula para una oferta de trabajo de fuera de España.
#70 esperemos, porque sin "proactivo" y palabras molonas no tiene ningún futuro.
#56 Estoy demasiado bueno para hacer eso, me contratarían sin siquiera leer el resto y luego serían acusados de discriminación :-P

#70 de hecho actualmente estoy "en el mercado" fuera de España ;)
#16 El rendimiento de la JVM está a años luz de cualquier lenguaje dinámico como JavaScript, Python o PHP. Para aplicaciones de escritorio si que es un cagarro y aún no he visto ninguna escrita en Java que sea medianamente aceptable, pero en servidores es precisamente donde Java brilla.
#16 O el monstruo que era (es) .Net antes de Core, parcheando un lenguaje/framework orientado a escritorio para usarse en web.
Te refieres al famoso WebForms ... Si, Microsoft aprendió duramente de esa aberración, que es la que le ha dado mala fama y con razón.
Pero antes de Core ya se puso las pilas con MVC5, DataAnotation, Razor, Entity Framework... podías hacer una buena web de gestión en pocas semanas.
#2 te has dejado algún argumento por el camino. Bueno, mas bien todos los argumentos.
#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.
#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.
#30 Me ha gustado tu comentario, el único fallo que le veo es que me chirría mucho de lo de compilar en javascript. ¿No querrás decir traducir o convertir?
#2 webasembly
#2 Perdón, ¿y NodeJS?
#2 ¿Sabes cómo sé que las películas de 50 sombras de grey son una chusta? Porque me las he visto todas. Lo mismo para Lars Von Trier, aguanté como un campeón anticristo, dancer in the dark, melancolía, ...
Soy de la opinión de que no se puede criticar algo sin conocerlo lo suficiente.
12 años, 12 años enteros de mi vida estuve con Java certificándome como arquitecto, 8 con .NET con MSCD pero sin certificarme como arquitecto. He programado en COBOL, C++, ensamblador, Delphi, Ruby, ... y de…   » ver todo el comentario
Donde este el cobol :troll:
#3 Mejor el Basic de toda la vida...{troll} :troll:
#4 eres un viejuno 8-D
#6 xD xD xD xD xD 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....{cool} 8-D
#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 :tinfoil:
#10 Yo empecé bastante antes, hice algunas cositas con el Spectrum, era bastante divertido....
#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.
#26 El ordenador tenía 48kb de ram y diskettes de 136 kb
#26 No dice que no hubiese, si no que los PCs venían sin ellos instalados. De hecho antiguamente era muy normal que la gente editase 4 tonterías de los sistemas antes de instalarlos para tener su "custom OS".
#3 pues déjate...que los que quedan cobran fortunas por mantener legacy de la banca
#8 lo se, lo se
#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.
#51 Y sin posibilidad de escapatoria,más que a otra cárnica similar
#8 no me jodas! Y yo, sabiendo cobol, haciendo webs cual adolescente acabado de salir del horno.... :palm:
#8 ejem, ejem.... aquí un picador de Cobol que no gana una fortuna...
#3

El lenguaje del futuro. Todos los demás quedarán obsoletos y seguirán los mainframes de IBM.
#3 Hotia, otro de los míos.
#3 ¿el COBOL es esa cosa moderna que quier desbancar a Fortran?
Joder menudo spam, no? Anda que no hay manuales en Internet no me jodas. Negativo al canto
#5 Vaya, te he votado positivo sin querer, en realidad no quería votar nada. Solo iba a decir que no me parece spam en absoluto... No te voy a compensar votando negativo en otro comentario porque estaría feo, pero vamos, no quiero que creas que esoy de acuerdo con tu comentario...
Por otra parte, he leído una parte del manual y me parece bien escrito, y "straight to the point".
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 javascript.info/ .

Luego 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.
El principio de pareto
#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.
#12 Yo prefiero la regla del 90-90. Aprender el 90% te llevará el 90% del tiempo. Aprender el 10% restante te llevará el otro 90% :troll:

es.wikipedia.org/wiki/Regla_del_noventa-noventa
No es mejor interesarse directamente por TypeScript?
#28 para entender TypeScript tienes que entender JS si o si.
#29 no es inclusivo? vull dir, aprendiendo TypeScript no aprendes también las bases de JavaS?
#66 Es parecido, pero no es lo mismo por lo tanto no. En mi opinión Typescript fue interesante hace unos años. Hoy en día ya no tiene tanta utilidad y es mejor directamente utilizar es6+lintern+transpiler.
#66 No todas las bases. Hay cosas de JS que TS "esconde" (para alegría de muchos... :-D )
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).
#31 Yo estoy hasta los huevos de que reinventen tantas veces la rueda y quieran venderme la moto cada semana, lo malo es que hay empresas que se lo tragan.
No creo que que haya trabajos tan poco consistentes y cambiantes como ser desarrollador web (Front end en mi caso) y todos tenemos un límite.
Yo desde que me he familiarizado con la programación funcional veo JavaScript de forma muy diferente, y me ha empezado a gustar.
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() {
console.log('I promised to run after 1s')
setTimeout(function() {
console.log('I promised to run after 2s')
}, 1000)
}, 1000)

Que es cierto.. un timeout dentro de otro…   » ver todo el comentario
#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)
#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...…   » ver todo el comentario
#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…   » ver todo el comentario
#85 Es una de las cosas buenas que tiene usar las "arrow functions" que te ahorra cosas del tipo "var me = this" o usar bind/call/apply para cambiar el contexto de la función. Lo que dice #68 de que si lees "foo = param => doSomething(param) " asumas que a foo le asignas el valor de param... lo veo bastante erróneo. Es como si ves "var a = 3 + 2" y piensas que a vale tres. No lo haces porque sabes que primero tienes que evaluar la parte derecha de la…   » ver todo el comentario
#54 Pues que quieres que te diga, Haskell es uno de mis lenguajes favoritos y foo = param => doSomething(param) me parece una mierda ilegible.
#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.
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Ar
Yo es que no uso lenguajes para fracasados.
Logo es el futuro, el concepto de la tortuga es revolucionario y no lo tiene ningun otro lenguaje
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í).
«123

menéame