I found out AJAX.. What else am i losing?

[vitinho444]

What else am i losing?

I just found out that AJAX is soooo easy to use and soooo useful in web development. I think jQuery was a bomb and now this... what else am i losing here?

I started by searching tutorials on using API's with PHP and ended up learning AJAX for calling scripts without refreshing a page. I feel so bad for not learning this before... I think I won't use any

Code: Select all

<form action="register.php"> 

or

Code: Select all

<form action="login.php">

starting now... Am i right? This is so good and useful and pretty i can't even imagine i never gave it 10 minutes of my life to learn it.

I know there's hate on W3Schools, but it was there i learned the basics of AJAX, I recommend it not because it is good tutorial, but its the only one i read so i will assume it is a good one. Here it is : http://www.w3schools.com/ajax/.

So for those who don't know, AJAX stands for Async.. (long word) - Javascript And XML, that basically says that you can _POST and _GET the crap out of your scripts without a single page refresh, thus this being used in most web IM's i believe (Now that i talk about this, it would be a cool project to create one :O, I'm gonna try). So if you're tired of having your index full of redirects to another scripts and those scripts getting executed and then redirect back to your index, fear no more! AJAX is here!! (It was here for 10 years but.. IT IS HERE!!).

I won't give a tutorial on it, since.. well I just learned it, but so you can know how easy it is, you have your javascript script, and then inside of a single function you create a HTTPRequestObject (ActiveX on IE5 and IE6), and with that object you call whatever script you want with either GET or POST method, like this:

Code: Select all

xmlhttp.open("GET","getSomething.php?keyword="+str,true);

and it throws "str" in the face of the getSomething.php and that getSomething.php chews off "str" and spits out whatever information you can get with str.

On the other side (getSomething.php):

Code: Select all

$key = $_REQUEST["keyword"];

if($key == "date")
echo date(); // Spit the date!!

And then AJAX grabs that spit and throws it away nicely to your webpage, without a single refresh and within nano-seconds!!

What are you still doing reading this? GO Learn it if you wanna be a web developer!! I think you will need it!

[Jackolantern]

Hehe nice! But to answer the question of "what else am I losing?", that would be my favorite feature to web development today: websockets. Where AJAX allows browser-to-server communication with no page refresh, websockets allow two-way communication with no page refresh (browser-to-server and server-to-browser). It is what powers all desktop-like HTML5 MMOs in the browser.

The only problem is that the architecture of PHP really makes websockets difficult. That is one of the reasons why Node.js became popular so fast, because of Socket.io. Node and Socket.io make realtime communication in the web dead simple.

[vitinho444]

Hehe nice! But to answer the question of "what else am I losing?", that would be my favorite feature to web development today: websockets. Where AJAX allows browser-to-server communication with no page refresh, websockets allow two-way communication with no page refresh (browser-to-server and server-to-browser). It is what powers all desktop-like HTML5 MMOs in the browser.

The only problem is that the architecture of PHP really makes websockets difficult. That is one of the reasons why Node.js became popular so fast, because of Socket.io. Node and Socket.io make realtime communication in the web dead simple.

Hum cool, so would you recommend node.js and socket.io for a chat app instead of plain AJAX, MySQL, PHP?
I need to check that one out, I've heard (here) lot about node and hallsnode and what not but i never digged up, maybe its that time!

[Jackolantern]

Yes. Chat is irritating with just AJAX because AJAX doesn't have server-push. So when you say something in the chat, it does go to the server, but then how do you immediately notify the other chatters of your message? The typical solution was to do polling, where each client has to repeatedly check the server to see if there is anything new to report. But the problem with polling is how wasteful and slow it is. You have to find a trade-off between how fast you want new messages to show up and how much you want to save bandwidth. If you want messages to appear fast, that means you basically have to restart a new AJAX request as soon as the last response comes back. This is incredibly wasteful, and your bandwidth will start to overflow after only a dozen users or so, since 99% of all the AJAX responses are just going to be "nothing new to report". It also isn't even that fast, with a potential max latency of upwards of 1 second. If you don't mind the latency, you can set up to poll every 4 or 5 seconds or longer, which does save some bandwidth, but still, probably over 80% of all responses will still be "nothing new to report".

What you want is to have some type of real server-push. There are some pre-websockets techniques known collectively as Comet that tried to solve the server-push problem, but they were all hacks making HTTP work in ways it was never intended to. The simplest of which, and the only one I know of that worked natively in PHP was long polling. That was where you poll the server for any new data, just like in regular polling. But instead of immediately returning it to say "no new data", the PHP script starts up a loop with a sleep() in it, and it keeps looping and sleeping, checking for new data, and the response is only sent when it finds some new data to send. This pushes the burden from bandwidth to server resources, since long polling locked up a lot of the server's threads and caused a pretty big CPU and RAM hit. The other Comet techniques all required custom software or special server software to run. Facebook and other web apps from the pre-websocket days that had server push all used some Comet technique in some way or another (typically with tons of custom software).

Websocket was created as a direct response to devs struggling with Comet hacks as they tried to make the web more realtime. Websocket starts as an HTTP "handshake" between the server and the browser to decide on the protocol that both support, and then HTTP is dropped in favor of a direct, two-way TCP socket connection. This allows two-way communication between server and browser that, by some estimates, is up to 20x faster than HTTP. And it drastically simplifies server-push, making communication from the server as easy as from the browser. However, socket servers have never been that simple, since they have traditionally required multithreading. Node.js makes this much more simple by being asynchronous. This drastically simplifies the programming model for working with websockets, but takes some time to wrap your head around. In PHP, each script can be treated as an isolated entity, and the server handles concurrency with other users. In node, you write the entire application, and may consider how users interact in your scripts.

TL/DR: websocketzBcool

[vitinho444]

Wow, i love your explanations man. You could be a teacher, because that sh*t ain't boring!

So i think AJAX is cool for form submissions, but something like a real time chat, its better to check out node.js and web sockets.

Thanks a lot Jacko

[Jackolantern]

Thank you

And basically like you said, AJAX and websockets both have their places. AJAX is much more accessible and easier to program, and it works in pretty much every browser (even the dreaded IE 6). In situations where you just need to send some data to the server without a page load, AJAX is your man. Also, if your application is going to have a lot of page changes, that can be rough for websockets since it needs to reconnect for every page load. But in situations where you need rapid back-and-forth communication, like for a realtime game, chat, or single-page app (SPA), AJAX isn't the right choice. Websockets are definitely better for that.

Websockets require much more modern browsers than AJAX, but Socket.io has "fall-backs" for the browsers that do not natively support it. It will try to use websockets, but if that isn't supported, it will then try to make the socket connection with an invisible Flash application, then it will try a couple of Comet techniques, ending with long polling. All of the fall-backs are almost completely invisible to you, and your node server runs the same either way.

[vitinho444]

Don't mention it

Yeah it was my first thought, like in a browser based game, only in the main page you have several redirects
index.php -> register.php (form) -> reg.php (actual database register) -> register.php (successful or not message)
index.php -> login.php (form) -> auth.php (check the information with the DB) -> login.php -> game.php (if successful) || login.php (if not)

So with AJAX you could basically have only the form page, and then side scripts for the register and login that were called once the information is validated by a CheckInfo.php that keeps adding those ? or X on the side of the text inputs to tell you if the email is valid or not.

Websockets require much more modern browsers than AJAX, but Socket.io has "fall-backs" for the browsers that do not natively support it. It will try to use websockets, but if that isn't supported, it will then try to make the socket connection with an invisible Flash application, then it will try a couple of Comet techniques, ending with long polling. All of the fall-backs are almost completely invisible to you, and your node server runs the same either way.

Hum, but websockets will work on IE6 at least? (Not that i care about IE6...)

[Jackolantern]

No, websockets I think will only work in IE >= 10. In IE6, you will have to hope that they have Flash installed, or else you are probably going to be using long polling on them.

[vitinho444]

No, websockets I think will only work in IE >= 10. In IE6, you will have to hope that they have Flash installed, or else you are probably going to be using long polling on them.

Hum but like you said web sockets will handle that alone without me saying them to right? If that's the case i guess it's not a problem

[Jackolantern]

No, websockets I think will only work in IE >= 10. In IE6, you will have to hope that they have Flash installed, or else you are probably going to be using long polling on them.

Hum but like you said web sockets will handle that alone without me saying them to right? If that's the case i guess it's not a problem

Not websockets. Socket.io will handle it. There are no websockets in IE <= 9. If you tried to natively code a websocket app in IE 8 without Socket.io, for example, you would just get a Javascript error and no connection. But Socket.io is both a client-side and server-side library that deals with non-websocket browsers and finds a way to make a realtime connection, completely transparently to you and your code.