Well you see first you hit a Javascript click listener. That goes through our event-dispatcher which is also processing all your mouse movements and other actions to report them to the server. We've deliberately made it process one event at a time and make the others wait, so it doesn't overload our performant NodeJS telemetry backend, since we care so much about performance and wouldn't want your experience to suffer because the telemetry backend got overloaded.
Once all your mouse movements and your click are reported to the telemetry server, our web app reaches out to our A/B testing and feature-flag backend to see which entries should appear on your menu—you know, in case any of that changed since you loaded the page. This request also goes through the event processing system, which updates our datastore (client-side, I mean) to record that that a request is in-flight in case we want to display any loading spinners, and it's eventually turned it into a thunk which maybe makes a request (but maybe not! Hence the thunk!) which (maybe!) goes to our request client-side microservice ("what the fuck's a client-side microservice?" LOL OK boomer, are you a time traveller from 2005?) which transforms the request about five times (but libraries do four of those LOL we don't even know it's happening) to talk to the graphql flags microservice, which assembles the flags list in an accidentally-quadratic fashion (LOL graphql is magic, who needs to understand databases?), taking a full 500ms to process the request.
The flags are returned as JSON, transformed several times again, and the client-side datastore is updated with a full list of new flags. Since new flags can affect anything, everything re-renders. First, we need to update the shadow DOM, but to do that....
[... five paragraphs later ...]
And then your hamburger menu is on the screen!
Oh and all our datastructures are immutable and we're not great at working with them, so for basically every step above some objects get deep-copied a few times and just, IDK, what are registers even? Client- and server-side both. For safety! Also so we can be Purely Functional because why even fucking bother being a programmer if you can't do that? Like literally just die if you're not writing eighty HOFs a day. You have no idea how elegant all this code is. So elegant.
This is hilarious and sarcastic, but there's a hint of reality here. Overly Complex Engineering is a fashionable (and evidently lucrative) technical discipline now, and is almost expected as the default. If you get an interview question "design a web frontend and backend to do X" and you say "Easy, a single LAMP server can do this," it's likely you're not getting the job.
Sarcastic, but I didn't put anything in I thought entirely implausible (and some of it's straight-up normal; I cut off because there was too much normal remaining, actually, and I didn't feel like writing it all out—we still had to take a trip down into the frontend framework's state machine, and back out again!). Looks like others dug into the page and posted their findings, and my made-up bit about telemetry isn't even that far off, LOL—god, Web is a shit-show. But wasting everyone's time with this crap pays the bills....
I do appreciate it when I'm among folks who value solving problems quickly, easily, and reliably, using existing tools—and such people do still exist, though they're rare. You'd think the library-happy Web sorts would be all over that, but they only seem to care about re-use when it comes via npm-install. Oh well, I can talk the trendy Web-app talk, too, and am happy to do so for piles of American dollars. It's not my money getting tossed in a bonfire.
Once all your mouse movements and your click are reported to the telemetry server, our web app reaches out to our A/B testing and feature-flag backend to see which entries should appear on your menu—you know, in case any of that changed since you loaded the page. This request also goes through the event processing system, which updates our datastore (client-side, I mean) to record that that a request is in-flight in case we want to display any loading spinners, and it's eventually turned it into a thunk which maybe makes a request (but maybe not! Hence the thunk!) which (maybe!) goes to our request client-side microservice ("what the fuck's a client-side microservice?" LOL OK boomer, are you a time traveller from 2005?) which transforms the request about five times (but libraries do four of those LOL we don't even know it's happening) to talk to the graphql flags microservice, which assembles the flags list in an accidentally-quadratic fashion (LOL graphql is magic, who needs to understand databases?), taking a full 500ms to process the request.
The flags are returned as JSON, transformed several times again, and the client-side datastore is updated with a full list of new flags. Since new flags can affect anything, everything re-renders. First, we need to update the shadow DOM, but to do that....
[... five paragraphs later ...]
And then your hamburger menu is on the screen!
Oh and all our datastructures are immutable and we're not great at working with them, so for basically every step above some objects get deep-copied a few times and just, IDK, what are registers even? Client- and server-side both. For safety! Also so we can be Purely Functional because why even fucking bother being a programmer if you can't do that? Like literally just die if you're not writing eighty HOFs a day. You have no idea how elegant all this code is. So elegant.