Hola, que es mejor aprender Javascript, Ajax o Jquery

[XD2XD2]

Hola, que es mejor aprender ¿Javascript, Ajax o Jquery? y ¿Porque?

[IsaBelM]

jquery es una librería de javascript y ajax es un técnica. el acronimo ajax significa asynchronous javaScript and xml. por lo tanto javascript engloba jquery y ajax

[emprear]

Ajax es javascript
jQuery es Javascript
conclusión, aprendé javascript que vas a terminar aprendiendo Ajax y jQuery.
Pero cuando digo "aprender javascript", no me refiero a tan solo hacer un alert() ó imprimir un "hola mundo", hablo de aprenderlo en serio, te va a llevar unos cuantos meses/años, pero ese es el camino

SAludos

[XD2XD2]

Y que se podria hacer con javascript que no se pudiera hacer con html css o php?

[enlinea777]

Iniciado por XD2XD2

Hola, que es mejor aprender ¿Javascript, Ajax o Jquery? y ¿Porque?

las 3 que basicamente son 1.

[enlinea777]

Iniciado por XD2XD2

Y que se podria hacer con javascript que no se pudiera hacer con html css o php?

muchas cosas, animaciones, cambios o manipulacion de todo el contenido de la pagina en tiempo real.
basicamente php es para el lado del servidor y javascript es para el lado cliente donde la limitante es el navegador y el pc del usuario.

[emprear]

Iniciado por XD2XD2

Y que se podria hacer con javascript que no se pudiera hacer con html css o php?

Si aprendés javascript y aprendés php la respuesta a tu interrogante será respondida con creces.

Que te parece cambiar los estilos de cualquier elemento de la página sin necesidad de recargar la misma?

Por solo citar una de muchisimas tantas

SAludos

[dontexplain]

Tienes un pequeño lío mental.

En un principio imagina que en JS existe un método que devuelve los objetos html mediante su id

document.getElementById(id);

pues se implementa un equivalente que lo simplifica

jQuery("#"+id);

Ese equivalente no es más que una construcción sobre la construcción básica, pero a base de JS.

Ajax es una tecnología que a través de JS permite realizar peticiones HTTP tal cual las realizaría un navegador o cualquier otra aplicación. Puedes realizar peticiones HTTP usando C/C++, Python, Ruby, PHP o cualquier otro lenguaje. En este caso, el navegador provee de un mecanismo de simplificación, para ello el navegador provee de un objeto XMLHttpRequest que posee métodos para realizar esta petición. No obsatnte, tú mismo puedes crear tu propio objeto JS simplemente añadiendo un método JS en el motor JS del navegador (que no es más que C/C++) y compilándolo, de este modo podrías crear un objeto ficticio que realice peticiones HTTP al que podrías llamar

lechugaHTTP(url)

que devuelve un objeto de tipo lechuga que tiene varios métodos (enviarhttplechuga, appendfrutas), varias propiedades (tipofruta, cabecerafruticola), blablablá que modifican el objeto, y lo que se te ocurra pero para finalmente hacer petición HTTP normal que es de lo que se trata.

Un saludo.

[rodrigo791]

Iniciado por dontexplain

Tienes un pequeño lío mental.

En un principio imagina que en JS existe un método que devuelve los objetos html mediante su id

Seguro que no va a entender mucho de que hablas, si le hablas de métodos, objetos,id y ni siquiera programo comenzó con js

Como dicen antes ajax es en definitiva javascript, jquery también, por lo tanto javascript es la base de estas 2 herramientas y por lo tanto tenes que aprender 1ero javascript para luego ir por jquery y demás.
Asi que muchacho no pierdas tiempo y ve: http://www.librosweb.es/javascript/

te dejo este manual porque se que es bueno como para arrancar, pero hay otros manuales muy buenos como este http://www.desarrolloweb.com/manuales/26/ y luego este http://www.desarrolloweb.com/manuales/20/

[dontexplain]

Iniciado por rodrigo791

Seguro que no va a entender mucho de que hablas, si le hablas de métodos, objetos,id y ni siquiera programo comenzó con js

Como dicen antes ajax es en definitiva javascript, jquery también, por lo tanto javascript es la base de estas 2 herramientas y por lo tanto tenes que aprender 1ero javascript para luego ir por jquery y demás.
Asi que muchacho no pierdas tiempo y ve: http://www.librosweb.es/javascript/

te dejo este manual porque se que es bueno como para arrancar, pero hay otros manuales muy buenos como este http://www.desarrolloweb.com/manuales/26/ y luego este http://www.desarrolloweb.com/manuales/20/

Y por eso yo creo que antes de comenzar a aprender JS debería leerse un libro, al menos un manual, sobre principios de la programación y una pequeña introducción sobre redes y computadoras.

hasta donde sé los objetos, los métodos, las propiedades y esas cosas son comunes a la mayoría de lenguajes de programación.

[rodrigo791]

Si por supuesto que son comunes a la mayoría de los lenguajes, igual no creo que sea necesario leer sobre principios de programación, simplemente que tome 1 manual de js y listo, no tiene porque tomar 1 manual a parte sobre los principios de programación en el cual va a ver los elementos básico de la programación como variables, vectores, funciones etc.

Directamente que tome un manual de js y no pierda mas tiempo, y mucho menos que no pierda tiempo reitero ya que no estamos en el 2000 donde no había tanto sobre web para leer como ahora, mi consejo es que XD2XD2 trates de ponerte a leer LO ANTES POSIBLE y entender todo este mundo de js y demás, porque esto avanza, y si queres estar al tanto de todo, no podes dejar pasar el tiempo.

Suerte.

[pzin]

Por aclarar gráficamente el lío mental que ya han dicho que tienes y que es manifiesto, recuerdo que hace algunos años alguien dijo por aquí lo siguiente*:

HTML son los huesos, CSS la piel, PHP —u otro lenguaje de lado servidor— son los músculos y Javascript —lo que incluye AJAX/jQuery— son los anabolizantes.

En el mismo orden: estructura, diseño, motor y dinamismo en el navegador.

* o similar
Edito (por aquello de citar fuentes): buscando encontré que fue un tándem entre webosiris y K3NNY.

[enlinea777]

Iniciado por Bonez

Por aclarar gráficamente el lío mental que ya han dicho que tienes y que es manifiesto, recuerdo que hace algunos años alguien dijo por aquí lo siguiente*:

HTML son los huesos, CSS la piel, PHP —u otro lenguaje de lado servidor— son los músculos y Javascript —lo que incluye AJAX/jQuery— son los anabolizantes.

En el mismo orden: estructura, diseño, motor y dinamismo en el navegador.

* o similar
Edito (por aquello de citar fuentes): buscando encontré que fue un tándem entre webosiris y K3NNY.

Muy buena forma de decirlo

[dontexplain]

Iniciado por Bonez

Por aclarar gráficamente el lío mental que ya han dicho que tienes y que es manifiesto, recuerdo que hace algunos años alguien dijo por aquí lo siguiente*:

HTML son los huesos, CSS la piel, PHP —u otro lenguaje de lado servidor— son los músculos y Javascript —lo que incluye AJAX/jQuery— son los anabolizantes.

En el mismo orden: estructura, diseño, motor y dinamismo en el navegador.

* o similar
Edito (por aquello de citar fuentes): buscando encontré que fue un tándem entre webosiris y K3NNY.

Realmente, creo que el lío deriva principalmente en desconocer el orden en que se desarrollan cada uno de los pasos. El lío es por tanto algo de índole temporal por decirlo de alguna manera.

Cada cosa satisface una necesidad. La necesidad de dinamizar una salida de texto induce a tener que modificar esa misma salida y el hecho de modificarla induce en sí mismo a tener que buscar formas de procesamiento de la entrada (php/asp). Luego, la necesidad de dar estructura y forma a la salida induce a tener que buscar formatos de contenido que puedan simplificarla visualmente para la lectura, de ahí surge el maquetado HTML con CSS.

De la misma forma, cuando AJAX ya cumplía su cometido siendo una herramienta que complementa paralelamente al HTTP tradicional surgieron formas algo más eficaces que solventaban el problema de la eficiencia y la velocidad, como los Websockets. Supongo, y ya es mucho suponer, que probablemente la evolución del websocket actual, dado que es un sistema de espera-petición (listener-event) constante, sea algo similar a un websocket implícito en que todo el contenido sea en sí mismo un ente dinámico que está en una petición-respuesta continua, aunque no se me ocurre las formas de desarrollarlo dado que TCP implica una petición-respuesta tradicional (vamos, que sería técnicamente lo mismo), supongo que quizás, implementandolo bucleicamente, aunque la verdad, ni idea. Recuerdo que el websocket envía un heartbeat cada cierto tiempo para comprobar el estado de conexión, lo cual, sigue siendo TCP normal, hacer algo en tiempo real real y no simulado supondría enviar paquetes de petición con una respuesta cada cuanto de tiempo. Yo creo que es una paradoja irresoluble xD.