Is sending data to a server via a script tag an outdated paradigm?

Question

I inherited some old javascript code for a website tracker that submits data to the server using a script url:

var src = "http://domain.zzz/log/method?value1=x&value2=x"
var e = document.createElement('script');                  
e.src = src;

I guess the idea was that cross domain requests didn't haven't to be enabled perhaps. Also it was written back in 2005. I'm not sure how well XmlHttpRequests were supported at the time. Anyone could stick this on their website and send data to our server for logging and it ideally would work in most any browser with javascript.

The main limitation is all the server can do is send back javascript code and each request has to wait for a response from the server (in the form of a generic acknowledgement javascript method call) to know it was received, then it sends the next.

I can't find anyone doing this online or any metrics as to whether this faster or more secure than XmlHttpRequests. I don't know if this is just an old way of doing things or it's still the best way to send data to the server when you are mostly trying to send data one way and you need the best performance possible.

So in summary is sending data via a script tag an outdated paradigm? Should I abandon in favor of using XmlHttpRequsts?

Answer 1

I don't think there is anything wrong with it, per se, but XmlHttpRequests does it better.

Before Ajax, javascript was extremely limited. There was no real way to query a database, so you either had to frontload all the data you might need (with the attendant performance hit), or you had to make all the same data available through an external page, with most of the same performance problems.

Sourcing an external "script" to pass a GET header to a web application allowed you to generate a page, on demand, that contained only the data you needed. Very very cool, solved a lot of problems...But at it's root it's a hack. XmlHttpRequests was released by Microsoft (as a part of OWA) to expand that functionality, which it did well enough to be picked up by everyone else, and rolled into the spec in 2006.

I suppose you could lower your overhead by using the older method, but I doubt it's any quicker, and you'll lose all of the extra functionality.