3 ms·
> Making an HTTP request js pretty basic stuff for a scripting language, you shouldn’t need or want a library for it. Sometimes languages/runtimes move slowly
by diggan 2y ago
> Making an HTTP request js pretty basic stuff for a scripting language, you shouldn’t need or want a library for it.
Sometimes languages/runtimes move slowly :) Speaking as a JS developer, this is how we made requests for a long time (before .fetch), inside the browser which is basically made for making requests:
var xhr = new XMLHttpRequest();
xhr.open('POST', 'https://example.com', true);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.onload = function () {
console.log(this.responseText);
};
xhr.send('param=add_comment');
Of course, we quickly wanted a library for it, most of us ended up using jQuery.get() et al before it wasn't comfortable up until .fetch appeared (or various npm libraries, if you were an early nodejs adopter)
- ratorx 2y agoI don’t think it’s just slowness or stability. The original release of requests was in 2011 and the standard library module (urllib.request) was added in Python 3.3 in 2012.
- masklinn 2y agoIt’s way older than that. It used to live in urllib2, which dates back to at least Python 2.1, released in April 2001.
- d4mi3n 2y agoThis takes me back. I'm glad `fetch` has become the canonical way to do this. XHR was a new capability at the time, but back then we were just starting to learn about all the nasty things people could do by maliciously issuing XHR requests and/or loading random executables onto the page. Clickjacking was all the rage and nothing equivalent to Content Security Policy existed at the time.