A quick history of data fetching in JavaScript | Hacker News Reader

A quick history of data fetching in JavaScript

codeamigo.dev

38 pointsplondon51419 comments

It's definitely worth mentioning JSONP - which worked by setting up a function in the global scope and using JavaScript inserting a new script tag that would hopefully call that function with the data. It was the ultimate trust exercise, as your target data vendor could execute any JavaScript it desired. Despite the name, JSONP could of course contain non-json data, like functions or class definitions.

TLDR of JSONP for those who are fortunate enough not to have dealt with it: you’d make an API call with

  var script = document.createElement('script')
  script.src = 'http://api.example.com/foo?bar=baz&callback=myFunction'
  document.head.appendChild(script)

and then the server would (hopefully) return a JavaScript response, wrapping the JSON in the (global!) function of your choosing:

  myFunction({...JSON here...})

In addition to the risk of a malicious API server being able to execute whatever code it wanted on your page, this also caused architectural headaches: the callback function had to be on `window` so that the JSONP response would have access to it when it loaded. In addition to the immediately obvious problems with globals, you also had to think very carefully about how to structure things so that the callback knew what it was supposed to do when called. (Woe betide you if some important state could change and the response didn’t have enough context to tell whether it was still relevant.)

Thanks! I’ll investigate JSONP more and add it to the lesson

I had assumed the whole point of this was to make a joke about how after so much effort they were finally able to make fetch happen (a reference to Mean Girls, a 2004 movie which means by now probably many HN readers have never heard of it). But not so.

HN readers need to stop trying to make “stop trying to make fetch happen” happen.

The irony about fetch() finally being a thing and this guide describing it as the modern thing we all have access to now is that going to /r/reactjs and saying "I wrote some code with fetch()" is a bit like coming to HN and saying "I wrote my own crypto and put it in production". You'll be told you need to use a library and regress back to one of the earlier steps in this history.

I think that’s a bit of an overstatement. fetch() is pretty easy to use as-is and commonplace in React code. Sure, some prefer isomorphic libraries like axios, but it’s far from a requirement these days.

Honestly this is a very brief history, given it doesn't touch on the tons of other ways of sending data. My favourite of which was to just never closing the initial index.html connection and just continuing to send data.

Yeah, while the idea of outlining the history is good, this only covers what I would consider very modern methods.

"Click next to continue" ...I don't see a next button. But I do see the hamburger icon in lower left corner-- so, that works.

This is cool. I remember telling someone I was introducing to web app development how they should follow a similar path: Learn XHR, then jQuery Ajax, then fetch/axios for example.

Just so they can see why the newer methodologies exist.

> This is cool. I remember telling someone I was introducing to web app development how they should follow a similar path: Learn XHR, then jQuery Ajax, then fetch/axios for example.

I'm convinced this is one of the best ways of learning (whether you're going for breadth or depth). Knowing the path an ecosystem took and the stops along the way is critical to understanding why things are as they are, and contrasting new entrants.

This comes up a lot in frontend framework fatigue. Most frontend frameworks and tools exist in a path-dependent context and knowing the path often answers many questions.

This is also the reason why a mark of high quality projects is the comparison section ("Why use X over Y?"). It indicates that the creator is a student of the history and intentionally struck out to create something different (and possibly better).

Only barely relevant, but this seems like as good a place to ask as any: is anyone here in a position to explain why it not possible to reload an imported ES2016 module at runtime?

In the old 'require' days this was easy: delete it from the cache and then re-require. But AFAICT there is no equivalent[0] for ES2016 modules, and weirder still, no one seems to miss it or request it as a feature. This is surprising - I'd think people would want to, say, add something to a module and then have a running node application that imports that module pick up the change without restarting the node app.

0: It is possible, but only by doing hacky things to fool the cache in to thinking it's a new file - e.g. make a symlink to the module file and dynamically import the symlink, or for an http import, add an unnecessary parameter to the url.

Because you were never really reloading it, you were loading a second copy of it (and praying the old one gets garbage collected). "Delete it from the cache" doesn't stop timers, clean up event listeners, remove references held in memory, etc. It just removes the reference to the module that the require method holds. You were never reloading in the first place, just swapping out a reference. Arguably, this was hackier than the hacks you suggest now, since it's less explicit that you might not be accomplishing what you hope to.

You could load data in version 4 browsers with a hidden frame in IE4 and a hidden layer in netscape 4.

This was… disappointing. I expected xmlhttprequest to show up about midway through instead of being the very first thing. It’s like the web didn’t even exist before xmlhttprequest.

I work on a number of websites at work. None of them use fetch. They all still use xmlhttprequest whether natively, through jquery, or using a library.

This is really cool, it would be nice to know how long it is though. I went through 3-4 and then I wondered, "Am I going to finish this thing?"

That aside, great UX and story-telling experience for learning!

No mention of XDomainRequest? It was the only way to get data from other origins in IE8/9.

Cool! I'll check this out and add it to the lesson :)

Before XHR there was the IFrame!

Reply on news.ycombinator.com