¡Estamos en 2016!

[roman]

O como programar en Javascript y sí morir en el intento


El texto es un poco largo, pero creo que no tiene desperdicio. Está en el foro de Humor pero creo que refleja cómo nos sentimos muchas veces ante el desarrollo acelerado de la tecnología del software.

Traducción libre del original en inglés.

* * *

- Oye Mario, tengo en mis manos un nuevo proyecto web, pero la verdad es que hace tiempo que no desarrollo nada para la web y parece que las cosas han cambiado mucho. Tú eres el progamador web más actualizado por aquí ¿no?.

- El término correcto es Ingeniero en frontend pero sí, soy la persona indicada. Desarrollo para la web de 2016. Visualizaciones, reproductores de música, drones que juegan futbol, lo que sea que quieras. Acabo de regresar de la JsConf y la ReactConf así que conozco las últimas tecnologías para crear aplicaciones web.

- Perfecto. Necesito crear una página que muestre la actividad reciente de los usuarios en una especie de tabla filtrable que se actualice si hay cambios en el servidor. Pensaba en jQuery para obtener y presentar los datos.

- ¡Ay no, por dios! Ya nadie usa jQuery hoy en día. Deberías intentar React; ¡estamos en 2016!

- Ok, ok, ¿qué es React?

- Es una biblioteca fantástica que hicieron unos chicos de Facebook. Mejora enormemente el control y desempeño de tu aplicación ya que te permite manejar fácilmente cualquier cambio en tus vistas.

- Suena bien. ¿Puedo entonces usar React para mostrar datos desde el servidor?

- Claro, sólo necesitas agregar las bibliotecas React y ReactDOM a tu página.

- ¿Por qué dos bibliotecas?

- Una es el React en sí y la otra es para manipular el DOM, que ahora puedes describir con JSX.

- ¿JSX? ¿Qué es JSX?

- Es una extensión a la sintaxis de Javascript, muy parecida a XML. Es como una mejor forma de describir el DOM, algo así como un HTML mejorado.

- ¿Qué hay de malo con HTML?

- ¡Estamos en 2016! Ya nadie escribe HTML directamente.

- Entiendo. Entonces, si añado estas bibliotecas ¿puedo usar React?

- Más o menos. Necesitas Babel, y ya con eso podrás usarlo.

- ¿Otra biblioteca? Y ésa ¿para qué es?

- Babel es un transpilador que te permite transformar código de una versión de Javascript a otra. No necesitas incluir Babel para usar ReactJS, pero si no lo haces te quedas estancado con ES5, y hay que ser realistas, ¡estamos en 2016! Ahora lo suyo es usar ES2016.

- ¿ES5? ¿ES2016? Estoy perdido, ¿Qué son ES5 y ES2016?

- ES5 son las siglas de ECMAScript 5. Es la edición que usa la mayoría porque casi todos los navegadores ya la implementan.

- ¿ECMAScript?

- Sí, tú sabes, el estándar en que se basó Javascript en el ‘99 luego de la versión incial de 1995 cuando Javascript se llamaba Livescript y sólo funcionaba en Netscape. Era un relajo pero ahora todo es mucho más claro y existen ya como siete ediciones de la implementación.

- ¡Siete! ¿De verdad? Y ¿ES5 y ES2016 son…?

- La quinta y séptima, respectivamente.

- ¿Qué le pasó a la sexta?

- ¿Te refieres a ES6?Bueno, es que cada edición es una ampliación de la anterior, así que la ES2016 abarca todas las versiones anteriores. Claro que aún no se hace el lanzamiento final.

- Y entonces, ¿por qué usar ES2016 en lugar de ES6?

- Bueno, podrías usar ES6, pero para poder usar características de vanguardia como async y await necesitas ES2016, de otra forma no te queda más que usar generadores y corutinas de ES6 para poder bloquear las llamadas asíncronas y tener un buen control del flujo.

- No tengo ni idea de qué estás hablando, y todos esos nombres me confunden. Mira, yo sólo quiero cargar datos del servidor, y para eso pensaba incluir jQuery y obtener los datos con AJAX, ¿Por qué no puedo hacer eso?

- ¡Estamos en 2016 amigo! Ya nadie usa jQuery, además de que terminas teniendo un montón de código espagueti. Todo mundo lo sabe.

- Ok. Entonces, mi opción es cargar esas tres bibliotecas para obtener los datos y mostrarlos en una tabla HTML.

- Bueno, incluyes las tres bibliotecas pero las empaquetas con un administrador de módulos y así cargas un solo archivo.

- Ya veo. Y, ¿qué es un administrador de módulos?

- Depende del contexto, pero en la web, normalmente se refiere a cualquier cosa que soporte AMD o CommonJS.

- Ok. Y AMD y CommonJS ¿son…?

- Especificaciones. Describen cómo deben interactuar múltiples clases y bibliotecas de Javascript. Ya sabes ¿no? exports y requires. Puedes escribir múltiples archivos Javascript que definan el AMD o el CommonJS y usar algo como Browserify para empacarlos en un solo archivo.

- Ok. Tiene sentido..., creo. Y ¿qué es Browserify?

- Es una herramienta que te permite empaquetar las dependencias descritas en CommonJS en archivos que pueden ejecutarse en un navegador. Se creó porque la mayoría de la gente publica esas dependencias en un registro nmp.

- ¿Registro npm?

- Es un repositorio muy grande donde la gente sube código y dependencias como módulos.

- ¿Cómo un CDN?

- No exactamente. Es más como una base de datos centralizada donde todos pueden publicar y descargas bibliotecas de manera que puedas usarlas localmente para desarrollo y luego subirlas a un CDN si quieres.

- ¡Oh! ¡Como Bower!

- Sí, pero, ¡estamos en 2016!, ¡ya nadie usa Bower!

- Mmm. Ya veo. Entonces debo descargar las bibliotecas con npm?

- Así es. Por ejemplo, si quieres usar React, descargas el módulo React y lo importas en tu código. Puedes hacerlo para casi cualquier biblioteca Javascript moderna.

- ¡Ah! Como Angular.

- Eeer, Angular es muuuy de 2015. Pero sí, está Angular, junto con VueJS o RxJS y otras buenas bibliotecas de 2016. ¿Quieres que te platique de ellas?

- Mmm. Mejor sigamos con React, ya son muchas los conceptos que tengo que aprehender por ahora. Entonces, si quiero usar React, ¿lo descargo con nmp y uso ese Browserfy?

- Así es.

- Parece demasiada complicación para juntar varias dependencias y enlazarlas.

- Lo es, de hecho. Y es por eso que usamos un administrador de tareas como Grunt o Gulp o Broccoli; para automatizar la ejecución de Browserify. ¡Vaya! Incluso puedes usar Mimosa.

- ¿Grunt? ¿Gulp? ¿Broccoli? ¿Mimosa? ¿Qué diablos es eso?

- Administradores de tareas. Pero ya no son cool. Los usábamos en 2015, creo. Luego usamos Makefiles, pero ahora envolvemos todo con Webpack.

- ¿Makefiles? Pensé que eso era más de proyectos de C o C++.

- Sí. Pero parece que en la web nos encanta complicar las cosas para entonces volver a lo básico. Lo hacemos cada año, más o menos. Espérate y verás que en un año o dos usaremos ensamblador en la web.

- ¡Uf! ¿Mencionaste algo llamado Webpack?

- Es otro administrador de módulos para el navegador y algo así como un administrador de tareas al mismo tiempo. Es como una versión mejorada de Browserify.

- Ok. Y, ¿por qué es mejor?

- Bueno, no es tanto que sea mejor, pero sí más dogmático en cómo deben enlazarse tus dependencias. Webpack te permite usar distintos administradores de módulos y no sólo de CommonJS. Puedes, por ejemplo, usar módulos nativos de ES6 que estén soportados.

- Estoy muy confundido con todo esto de CommonJS/ES6.

- Todo el mundo lo está. Pero con SystemJS ya no importa.

- ¡Jesús! ¡Otra palabra con JS! Ok. Y ¿qué es SystemJS?

- Bueno, a diferencia de Browserify y Webpack, SystemJS es un cargador dinámico de módulos que te permite enlazar múltiples módulos en múltiples bibliotecas en lugar de juntarlas en un solo archivo grandote.

- ¡Ey! Pensé que queríamos juntar nuestras bibliotecas en un solo archivo y cargar ése.

- Pues sí, pero ya va a salir HTTP/2 y es mucho mejor hacer múltiples peticiones HTTP.

- Pero entonces, ¿no podemos simplemente agregar las tres bibliotecas originales de React?

- Pues no exactamente. Es decir, podrías agregarlas como scripts externos desde un CDN pero de todas formas tendrías que incluir Babel.

- ¡Uf! Y eso es malo ¿verdad?

- Así es, ya que estarías incluyendo todo el núcleo de Babel y eso no sería eficiente en producción. Verás, en producción, para tener a punto tu proyecto debes realizar toda una serie de tareas previas que hacen que el ritual para convocar a satán parezca cosa de niños. Tienes que compactar el código, ofuscarlo, incrustar el CSS crítico al principio, diferir la carga de scripts, y también-

- OK, OK. Entonces, si no se incluyen las bibliotecas directamente desde un CDN, ¿qué conviene hacer?

- Yo usaría un transpilador para pasarlas de Typescript a un combo Webpack + SystemJS + Babel.

- ¿Typescript? ¿Qué no estábamos hablando de Javascript?

- Typescript es Javascript, o, mejor dicho, es un superconjunto de Javascript, más específicamente, de la versión ES6 de Javascript, ésa de la que hablamos antes.

- Pensé que ES2016 ya era un superconjunto de ES6. ¿Por qué necesitamos esa cosa de Typescript?

- ¡Oh! Pues porque nos permite usar Javascript como un lenguaje tipado y minimizar los errores en tiempo de ejecución. ¡Estamos en 2016! Ya deberías agregar tipos de datos a tu código Javascript.

- Y, obviamente, eso es lo que hace Typescript.

- Al igual que Flow pero éste sólo verifica tipos mientras que Typescript debe compilarse.

- ¡Uh! Y ¿Flow es…?

- Es un verificador estático de tipos que desarrollaron unas personas en Facebook. Lo hicieron en Ocaml porque la programación funcional es la neta.

- ¿Ocaml? ¿Programación funcional?

- Es lo que se usa hoy en día hombre, ¿sabes, en 2016?¿Funciones de orden superior, currificación, funciones puras?

- No entiendo nada de lo que acabas de decir.

- Nadie lo entiende, al principio. Mira, lo único que tienes que saber es que la programación funcional es mejor que OOP y es lo que deberíamos usar en 2016.

- Pero en la universidad me enseñaron OOP. Pensé que era bueno.

- Y también Java era bueno, antes de que lo comprara Oracle. O sea, OOP estaba bien en aquellos días y aún tiene sus usos pero ahora nos dimos cuenta que modificar estados es como patear bebés y por ello todo mundo está cambiando a objetos inmutables y programación funcional. La gente de Haskell lo ha dicho por años –y no me hagas hablar de Elm. Pero afortunadamente en la web tenemos ahora bibliotecas como Ramda que nos permite usar programación funcional en Javascript.

- ¿Estás diciendo términos por el sólo placer de hacerlo? ¿Qué coños es Ramnda?

- No. Ramda. Como Lambda, la biblioteca de David Chambers, ¿la conoces?

- ¿David qué?

- David Chambers. Hace un trabajo estupendo. Es uno de los colaboradores de Ramda. También deberías echar un ojo a Erik Meijer, si de verdad quieres entrarle a la programación funcional.

- Y ¿Erik Meijer es…?

- Otro adepto de la programación funcional. Fantástico. Ha hecho varias presentaciones en las que destroza la metodología Agile con todo y su camiseta psicodélica. También deberías ver el trabajo de Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmanty-

- Ok. Para un poco. Éso está muy bien y todo pero pienso que es demasiado complicado e innecesario para simplemente cargar datos y presentarlos. Estoy seguro de que no necesito conocer toda esta gente o aprender todas esas cosas para crear una tabla dinámica. Volvamos a lo de React. ¿Cómo puedo obtener datos desde el servidor con React?

- Bueno, de hecho, para obtener datos no usas React. React es sólo para mostrarlos.

- ¡Joder! Entonces ¿qué usas para obtener los datos?

- Para eso usas Fetch.

- ¿Disculpa? ¿Usas Fetch para obtener los datos? (You use Fetch to fetch) Quienquiera que ponga esos nombres necesita uregentemente un thesaurus.

- ¿Verdad que sí? Fetch es el nombre de la implementación nativa para realizar peticiones XMLHttp a un servidor.

- ¡Ah! O sea, AJAX.

- AJAX sólo es el uso de XMLHttp. Pero sí, Fetch te permite usar AJAX basado en promesas que puedes resolver y así evitar el infierno de los callback.

- ¿Infierno de los callback?

- Así es. Cada vez que haces una petición asíncrona al servidor, debes esperar la respuesta, y eso te obliga a agregar una función dentro de la función, y así vas formando una pirámide infernal de callbacks.

- Ok, ok. Y ¿las promesas resuelven esto?

- En efecto, pero sólo si usas un navegador evergreen, de lo contrario deberás incluir un empaste (pollyfill) de Javascript o usar Request, Bluebird o Axios.

- ¡Por dios! ¿Cuántas bibliotecas debo conocer? ¿Cuántas hay?

- ¡Es Javascript! Debe haber miles de bibliotecas que hacen lo mismo. Conocemos muchas bibliotecas, de hecho, nosotros tenemos las mejores bibliotecas. Nuestras bibliotecas son inmensas, hasta incluimos fotos de Guy Fieri a veces.

- ¿Guy Fieri? Pasemos eso por alto. ¿Para qué son estas bibliotecas Bluebird, Request, Axios?

- Son bibliotecas para realizar peticiones XMLHttp que devuelven promesas.

- ¿Que jQuery no usa ya promesas con AJAX?

- Ya no usamos esa “J” en 2016. Sólo usa Fetch y empástalo cuando el navegador no lo soporte o si no usa Bluebird, Request o Axios. Maneja las promesas con await dentro de una función async y ¡tan tan! Ya tienes control adecuado del flujo.

- Es la tercera vez que mencionas await pero no tengo idea de qué es eso.

- Await te permite bloquear una llamada asíncrona para tener un mejor control del momento en que recibes los datos y en general mejora la legibilidad del código. Es genial, tan sólo debes asegurarte de agregar la preconfiguración etapa-3 de Babel o bien usar los plugins syntax-async-functions y transform-async-to-generator.

- ¡Es una locura!

- No. Lo que está de locos es que debes precompilar el código Typescript y luego transpilarlo con Babel para usar await.

- ¿¡Qué!? ¿No está incluido en Typescript?

- Lo estará en la próxima versión, pero la 1.7 sólo compila para ES6 así que si quieres usar await en el navegador, primero debes compilar tu código Typescript a ES6 y luego usar Babel para traducirlo a ES5.

- Ya no sé que decir…

- Mira, es fácil. Codifica todo en Typescript. Compila todos los módulos que usen Fetch para ES6, transpílalos con Babel etapa 3 y cárgalos con SystemJS. Si no tienes Fetch, empástalo o usa Bluebird, Request o Axios y maneja todas las promesas con await.

- Creo que no tenemos el mismo concepto de fácil. Entonces, con toda esa parafernalia finalmente obtengo los datos y puedo mostrarlos con React, ¿cierto?

- ¿Tu aplicación va a manejar cambios de estado?

- No lo creo, sólo debo mostrar los datos.

- ¡Uf! ¡Qué bueno! Si no tendría que explicarte Flux e implementaciones como Flummox, Alt, Fluxible. Aunque, para ser honestos, deberías usar Redux.

- ...Haré como que no escuché eso. Como dije, sólo debo mostrar los datos.

- ¡Ah bueno! Si sólo vas a mostrar datos, de entrada no necesitas React. Te bastaría con un motor de plantillas.

- ¡No me jodas! ¿Piensas que es divertido torturarme así?

- Sólo te mencionaba lo que podrías usar.

- Para, para.

- O sea, si fuera tú, aunque sólo use un motor de plantillas, de todas maneras usaría el combo Typescript + SystemJS + Babel.

- Debo mostrar datos en una página, no realizar una fatality de Mortal Kombat. Tan sólo dime qué motor de plantillas usar y de ahí parto.

- Hay un montón, ¿con cuál estás familiarizado?

- ¡Uy! No recuerdo el nombre; fue hace tanto tiempo.

- ¿jTemplates? ¿jQuote? ¿PURE?

- No, no me suenan. ¿Otra?

- ¿Transparency? ¿JSRender? ¿MarkupJS? ¿KnockoutJS? Hace un binding en ambos sentidos.

- ¿Otra?

- ¿PlatesJS? ¿jQuery-tmpl? ¿Handlebars? Algunos todavía la usan.

- Quizá. ¿Hay algo similar a la última?

- ¿Mustache, underscore? Creo que ahora hasta lodash tiene uno, pero son muuuy de 2014.

- Mmm. Quizá era más nuevo.

- ¿Jade? ¿DustJS?

- No.

- ¿DotJS? ¿EJS?

- No.

- ¿Nunjucks? ¿ECT?

- No.

- ¡Uh! No creo que sea Coffescript, ya a nadie le gusta hoy en día. ¿Jade?

- No, ya habías mencionado Jade.

- Quise decir Pug, es decir Jade. O sea, Jade ahora es Pug.

- No. No puedo recordar. ¿Cuál usarías tú?

- Probablemente las plantillas nativas de <strong>ES6</strong>.

- Déjame adivinar: y eso requiere ES6.

- Correcto.

- Lo cual, dependiendo del navegador, necesita Babel.

- Correcto.

- La cual, para no incluir la biblioteca completa, debo cargarla como módulo con npm.

- Correcto.

- Lo cual requiere Browserify o Webpack o, lo más probable, esa cosa llamada SystemJS.

- Correcto.

- Lo cual, salvo Webpack, debe manejarse idealmente con un administrador de tareas.

- Correcto.

- Pero, como debería usar programación funcional y lenguajes tipados, primero debo precompilar Typescript o agregar esa cosa de Flow.

- Correcto.

- Y mandar eso a Babel si es que quiero usar await.

- Correcto.

- Y así puedo usar Fetch, promesas, control de flujo y toda esa maravilla.

- Sólo no olvides empastar Fetch si el navegador no lo soporta. Safari aún no lo hace.

- ¿Sabes qué? Creo que ya estuvo bueno. De hecho, creo que ya no quiero saber nada de la web ni de Javascript.

- Haces bien, en unos años todos codificaremos en Elm o WebAssembly.

- Mejor me regreso al backend. Simplemente no puedo con todos estos cambios y versiones y ediciones y compiladores y transpiladores. La comunidad Javascript está demente si piensa que alguien puede mantenerse al día con todo esto.

- ¿Tú crees? Prueba entonces con la comunidad de Pyhton.

- ¿Por qué lo dices?

- ¿Has escuchado de Python 3?

[dec]

Hola,

Es entretenido y muy real el artículo. Sin embargo, ¿qué demuestra todo este movimiento en Javascript? ¡Que muchísima gente trabaja con Javascript y busca mejorarlo de mil maneras diferentes! Yo, sin embargo, soy muy reacio a TypeScript (por cierto, cuyo arquitecto es el mismo que el de Delphi: Anders Hejlsberg) pero le reconozco todo el mérito: hacer de Javascript un lenguaje "tipado" puede ayudar no poco en ciertos escenarios. Pero como TypeScript tiene que terminar siendo Javascript (luego de compilarse/traducirse) uno (tal vez estúpidamente) tiene a pensar en seguir con Javascript... para qué más.

En uno de mis proyectos uso AngularJS, tengo que reconocerlo, incluso antes de saber que había varias alternativas, mejor dicho, no conociéndolas todas ellas. Ahora me veo en la circunstancia de que Angular2 no es compatible con AngularJS (la versión 1.x), aunque, aparte de que Google va a seguir soportando el AngularJS, en realidad en mi proyecto AngularJS cumple en mi proyecto la función de "router" y "binder", si se puede decir así, y lo hace bastante bien. Pero claro, lo cierto es que Angular2 parece "mejor" (y seguramente ganará en algo, tal vez algo que yo no use en mi proyecto) y este no es compatible con la primera versión de AngularJS, como digo. De modo que aprendiste un "framework"... y ahora tienes que aprender otro.

Yo estoy dejando lo de Angular2 por dos motivos: la documentación para Javascript no esta disponible (como lo está para TypeScript y "Dash") y aquí se ve claramente la apuesta de Google por TypeScript o Dash en detrimento de Javascript... o bien es que cuesta demasiado preparar la documentación para Javascript. Pero es que además, como se menciona en el artículo de arriba, existen otros frameworks... y, puesto que al final tendría que empezar de cero, tal vez no sería Angular2 el elegido en esta ocasión.

En fin, lo que quería decir, después de este rollo personal, es que, en efecto, los cambios en Javascript son alucinantes... así como también en CSS (con lenguajes como SASS o LESS...) pero esto es algo bueno, en mi opinión, siempre mirando por mejorar algo ya existente muy complicado de hacer, por otro lado, pues, por ejemplo, trabajar con variables en las hojas de estilo (CSS) es algo que no está contemplado, de modo que SASS o LESS entran antes de la propia hoja de estilo, proporcionándonos una forma de usar variables en las mismas, aunque después todo termine en código CSS "normal y corriente".

Pero sí, es complicado mantenerse al tanto... de hecho yo mismo no creo que lo haga... mejor o peor va uno siguiendo el ritmo a su paso, pero, ¡tantas cosas se me escapan!

[mamcx]

Ese es el precio de lenguajes mal diseñados, y peor aun, de intentar clavar clavos con serruchos. JS & CSS son muy pobres, pero JS en especial es un lenguaje terrible. Hay que entender que fue hecho a las carreras y no le dieron tiempo al programador original de pulirlo (y eso que era competente, que es lo mas triste!).

Es increible el esfuerzo que le mete nuestra industria a maquillar cerdos como JS, PHP , C++ en vez de acpetarlos como son y usar herramientas mas adecuadas... que podrian tener la sintaxis C de ser el caso...


-----

Ahora de esas herramientas, Rust tiene buena pinta. El problema es que es el browser el lio: Todo depende de JS.

[jhonny]

!Caramba!, hubieran comenzado por Python desde el principio , a todas estas... Roman, ¿Ahora estás trabajando con Python?

[mamcx]

O con Lua, que se presta mas a ser embeido.

[ecfisa]

Mi admiración al "ingeniero" en interfaces, si yo tuviera que retener todos esos términos en mi memoria, no me quedaría ram libre para operar !!!

Saludos

[mamcx]

Y casi-gracioso (algo que paso hace unos meses):

Alguien borro de NPM (el package manager de JS, que ademas es un asco), el codigo para quitar espacios a la izq de una cadena (left-pad), causando masivos problemas por la increible cantidad de proyectos que lo tenian por dependencia.

Este codigo:

http://www.theregister.co.uk/2016/03...eft_pad_chaos/

Código PHP:

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
} 


Porque JS no tiene una libreria estandard....

Y si quieren ver la trifulca que se armo (divertida, eso si.)

https://news.ycombinator.com/item?id=11340510

[[Al González]]

¿Qué es DOM?

[Casimiro Notevi]

Aborrezco todo eso.

[[RONPABLO]]

Empezado por Al González

¿Qué es DOM?

Un juego en tercera persona donde uno tiene que matar un montón de bichos raros...

Ahora si en serio (y teniendo en cuenta que el dom de arriba en realidad sería doom) DOM

[Julián]

Joder, eso que pone arriba de que "ya nadie usa jquery" ¿Es cierto?
Pensaba yo que era de los mas modelno, pero si es verdad ¿Con que puedo sustutiirlo?

[roman]

Empezado por Julián

Joder, eso que pone arriba de que "ya nadie usa jquery" ¿Es cierto?
Pensaba yo que era de los mas modelno, pero si es verdad ¿Con que puedo sustutiirlo?

Respuesta en el mensaje #1

LineComment Saludos

[roman]

Pero la pregunta, Julián, es: ¿para qué quieres sustituirlo? jQuery sigue estando activamente desarrollado y manenido, entonces, si te funciona en tu aplicación, ¿para qué cambiarlo? El problema con visiones exageradas como la del diálogo ficticio (y no tan ficticio) es que terminas matando pulgas con un cañón.

LineComment Saludos

[Julián]

Claro, yo voy muy bien con jquery. Hace todo lo que necesito.

Las preguntas mas bien serían si jquery corre el riesgo de quedar abandonado y sobre todo ¿Existe algo que haga lo mismo y mejor?

Jau!

[Ñuño Martínez]

- Debo mostrar datos en una página, no realizar una fatality de Mortal Kombat.

Buen resumen.

Yo seguiré usando AJAX y DHTML/HTML5, y me importa tres webos lo que digan los demás.

[roman]

Empezado por Ñuño Martínez

Buen resumen.

Yo seguiré usando AJAX y DHTML/HTML5, y me importa tres webos lo que digan los demás.

¡DHTML!

No escuchaba este término desde el siglo pasado

LineComment Saludos

[mamcx]

Empezado por Julián

Las preguntas mas bien serían si jquery corre el riesgo de quedar abandonado y sobre todo ¿Existe algo que haga lo mismo y mejor?

Quedar abandonado? Ni a palos.

El problema que esta sufriendo JS es derivado de 3 grandes fuentes:

1- JS es un mal lenguaje. Todos lo saben pero hasta hace poco no se habia hecho nada para solucionarlo. De repente, varios grandes intentaron sacar saco algo mejor, y parece que MS tiene la version mas popular (TypeScript). Eventualmente, los grandes se sentaron y dijeron: "Que tal si realmente mejoramos el lenguaje?" Y en eso andan desde hace un rato. Mientras, la comunidad no los espera

Y porque ahora les dio por esto? Porque:

2- Estan empeñados en usar JS/HTML/CSS para lo que no esta hecho. Como hacer sistemas operativos, juegos 3d, apps cientificas, etc. Es tal que ahora existe esta "ley":

https://blog.codinghorror.com/the-pr...f-least-power/

Atwood's Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Lo que implica en usar el browser como un OS.

Obviamente, como rayos haran eso si el lenguaje no da? Y los browser son cada vez mas complejos y ahora una de las apps que mas traga memoria y recursos? Pues pa' eso esta el punto 1

3- Esto lleva a redescubrir el agua tibia:

- Usar componentes?
- Usar MVC y otros patrones?
- Usar build system?
- Usar paquetes?
- Y todo lo demas que existe en entornos mas sanos?

Eso apenas lo estan descubriendo en el planeta JS. Pero como JS no tiene un libreria estandar ni concepto de nada diferente a "Yo soy el dueño del mundo dentro de un browser y todo es global y solo se como medio-manejar el DOM" entonces bueno ese es el lio.

Ademas, un colorario:

- La mayoria de los programadores de JS carecen de las habilidades y experiencia de otras comunidades, como dice el creador de JS:

JavaScript is the only language that I’m aware of that people feel they don’t need to learn before they start using it.

Y por lo tanto, eso se NOTA. Todo es muy chapuzero en general.

---

Hay si muchas librerias muy buenas. React es una de ellas. Pero todo la complejidad adicional que se auto-impone la comunidad es un asco. Si se usa React al estilo hipster (como lo de este post), se descargan MILES de archivos como dependencias.

NO ES UN CHISTE