This sums up many of the front-end candidates nowadays. Reminds me of "why do I have to know what XMLHttpRequest or a browser event is, I just use jQuery .ajax() and .on() anyway" from a few years ago.
This sums up many of the front-end candidates nowadays. Reminds me of "why do I have to know what XMLHttpRequest or a browser event is, I just use jQuery .ajax() and .on() anyway" from a few years ago.
I bet there are many people who know everything about "XMLHttpRequest", but know nothing about congestion control. Or how a network stack comes together...
You do realize "XMLHttpRequest" wasn't even a thing until several years ago, and it's safe to assume further down the road it may well be phased out (in favor of better/more secure APIs).
Instead of asking about "XMLHttpRequest", wouldn't it be better to talk about the general need for "websites" to communicate with a backend on demand, at runtime, after everything has been loaded and rendered? Or, put "XMLHttpRequest" on the table, and talk about how one would implement such an API within the context of a browser?
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
In fact you'll probably encounter it in code your coworker wrote 15 minutes ago.
:[