Vamos por parte ...
Cita: Dentro de poco pasará que conoceremos $() pero no sabremos lo que es document.getElementById(), y peor aún, ya ni nos sonará document.
Y cuál es el problema ?. Decime el punto negativo de esto ... si yo se que haciendo
var miNodo = $('idDiv');.
Cita: pero sirven para desarrollarse en javascript como un cursillo de 1000 palabras sirve para aprender inglés. Al final siempre sale la duda de: ¿Y si quiero esto pero en color azul, qué tengo que cambiar?
Otra vez en desacuerdo. Trabajar con un FW no sifnifica que no puedas indagar con JS en los mismos scripts. Coexisten ... y son lo mismo. Ahora ... considero que los FW contrariamente a
acotar al lenguaje hacen justamente lo contrario !!!.
Cita: Y no me gustaría que la evolución de js la marquen las framework, la tendrían que marcar las necesidades del programador
Y que te pensas que hace un FW ?. Hace más fácil las necesidades e un programador; justamente los FW evolucionan al ritmo real de lo que los programadores piden ... cosa que JS también lo hace, pero a su ritmo.
Cita: Adaptar un navegador a las framework que rondan por ahí distanciaría más uno de otros y habría una batalla campal por los estándares. ¿ $() estándar ?
Sabes como fue la historia de JavaScript ?. Como fue evolucionando versión tras versión; el tironeo de los browsers ya que la compatibilidad nunca fue total. El Entandar se hace a los porrazos, siempre fue así. En su tiempo IE a voluntad propia manejaba el estandar; tenía cerca del 95% de la humanidad comprada. Hoy no puede; el entandar lo rige la W3C y la presión de los browsers.
Si FF3 implementa en forma nativa getElementByClassName ... veremos que dice W3C; seguro que lo acepta.
Cita: Pero... ¿sabrá javascript? ¿Hace él la web o como ve un efecto acordeón en el FW lo coloca en su página?
El albañil que pega ladrillos ... hace la mezcla con cemento, cal, arena y agua. Sabe el proceso de construcción del cemento o de la Cal ?. Sabe que el agua es el elemento que desatará la tercer guerra mundial ?. No, el pega ladrillos.
Vos sabes como los punteros y acumuladores trabajan con JS ?, como mapea la memoria RAM; sabes la corriente que consume asignar una direccion por el bus de direcciones ?. No. No te importa. Vos programas en JS.
Sabe el que usa un FW que es lo mismo que getElementById ?. NO. YYYYY ???
Si esa persona puede desarrollar mejor que vos, mas eficientemente ... entonces, donde el problema ?.
Estamos hablando de tareas distintas. Gente que piensa como vos hace los FW para que los utilicen los usuarios. Eso va a evolucionar JS. Porque los FW son mas pretenciosos ... y los browsers van a ejecutar en forma nativa lo que hoy por hoy son funciones armadas ... y ahí vas a dejar de tener esa disyuntiva; $() y $$() va a ser tus funciónes perfectas porque formarán parte del conjunto de funciones propias de JS.
Cita: verás, en estos foros estamos viendo que se hacen muchas preguntas y prácticamente todas las respuestas se dan con javascript puro... ¿Qué te hace pensar que usando una librería vas a conseguir mejores resultados?
No es algo que piense yo
Caricatos ... es algo que está ocurriendo alrededor nuestro.
Hace un recuento de los post del foro de JS. EL 95% de los post son 'drag de div, no se mueve !!!', 'menu con li anda en IE pero no en FF !!!', etc, etc, etc ... Cual es la solución a eso ?. Un buen FramWork.
Finalizando mi idea general:
JS no se va a perder, va a evolucionar. Los FramWorks van a tener mucho que ver. Toda evolución levanta polvareda. Aguante JS para los puristas, aguanten los FW para gente como yo ... que le hacen la vida más fácil.