Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am sorry you went through that. I can relate.

Today, we have “jargonauts.” These are folks that key on certain terms and acronyms.

I remember, back in the 1990s, hearing everyone gushing about “AJAX,” and wondering what the big deal was (after being laughed at, for not knowing the term). No one would explain what it was.

I looked it up, and go “Oh, they mean HTTPRequestObject!”

Turned out, that I actually already knew a lot more about “AJAX,” than most of the folks gushing about it, and the reason no one would explain it, was that they didn’t actually understand it.

Lot of that, going around…



Sounds like today's "dependency injection", and people writing 5 pages on it.

Except then it turns out what they mean isn't DI, but some other concept related to it and largely taken care of by their framework of choice.


It also sounds fancier than it really is. "Dependency injection" can literally mean just passing some arguments or setting properties on a hash. The target doesn't even need to be a singleton or long-lived. Honestly, I've never found the term particularly useful. The meaning is so amorphous that it could really just be described as a form of decoupling. But it sure was great to say it during interviews early in my career!


Indeed, it is simply passing some dependency as a parameter.

Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.

So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.

Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)


DI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.


Really depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with


I dunno how you can combine dependency injection (as I imagined it in the original comment) with FP in the first place.

Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.


I was thinking sideeffectful functions. Such as DB accesses.


> dependency rejection

That’s secretly the most powerful design strategy.


It objectively isn't, as there are certain things you can't do with it.

Altough, for usability it is IMO definitely the best.


> setting properties on a hash

Nowadays it's called a dict.


The term AJAX was coined in 2005 by https://web.archive.org/web/20150910072359/http://adaptivepa.... People had been talking about the idea for a few years at that point, but not with that name.


Might be right. I would be surprised, though. I do remember that it was a "brand new" buzzword.

Not worth fighting over. Time is flying, and even the early 2000s was a couple of decades ago.


Did you really hear anyone talk about AJAX in the '90s? Looks like there was some work done on XHR in '99, but it seemed to roll out across browsers in the early '00s and seemed peak hype when I started my career in the mid '00s, after the Web 2.0 conf in '04.


AJAX was a catch-all term meaning “the page does things without reloading the whole page” if I remember correctly - or that’s how people were using it.


It may have been the early 2000s, but it was very early on. It "came to a head," on a trip to San Francisco, on one particular project (I am not at liberty to discuss). It would not have been beyond about 2002. I think it was pre 9/11, but my memory of that time is a bit fuzzy. I did a lot of traveling.

I'm pretty sure that HTTPRequest debuted in IE 5 or 6.


The way I remember it is it became widely known once gmail and google maps shocked everyone with its effective use. So that's quite a bit later than 2002. But it's likely that it is just when I noticed, being pretty far removed from web development at the time.


AFAICR, it started in the mid-to-late 90s, although as with all things web in that period, was a non-standard cobbling together of feature and functionality using whatever technologies were available, while browsers themselves lurched in the dark and added features.

It's more akin to saying "We want to do this thing that's never been done on the web before, and no one ever thought to do. How do we assemble it out of this box of scraps that HTML and browsers currently give us?"

Consequently, there was probably proto-AJAX with ActiveX, the early js landscape, and iframes. But it would have certainly depended on where you worked.

Critically, internet connections were much slower (in latency and bandwidth), so partial page loads were more of an advantage.


Just to set the record straight, the skeptics were correct. I was off by 5 years.

I asked someone that was on that trip with me, and it was late 2007.

You know how it is, with us doddering old geezers; we forget stuff...




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: