I’ve found that there are about three levels of web development (a fourth if you're willing to bet on VR as a viable option on the web in the future). The first is the the very standard full-page-reload HTTP request lifecycle. The second level is what I like to refer to as the delegated web, or the prioritized web. And the third is the real-time web. I guess there's room for a step between levels 1 and 2 where you introduce asynchronous processing using Ajax, but you're still not delegating tasks.
A One-Track Mind
We're all pretty familiar with level one. It's where we all started as web developers, and it's the most common interaction we see on the web. Let's say a new user signs up for an account on your website. They fill out the form, hit submit, and wait for the page to refresh and redirect them to their new account dashboard. During this process you're sending a welcome email to them, a new-user-notification email to a manager, and storing their information in the database.
In other words, someone just walked into your store and said "I want to know when you have a sale!". You respond by putting your head down to take down their information onto a little card, writing up a letter saying "Thanks for joining!", taking that letter, affixing a stamp, running it outside to the outgoing mailbox, coming back inside, grabbing the manager and telling her about the new signup, then coming back to the customer and saying "Welcome!".
A Delegated Approach
But what if you were able to give certain people jobs so that you could focus on welcoming that new signup? This is where defining Events & Listeners, delegating Jobs, and taking advantage of the Queue can help. Let's take that same new user signup scenario.
A new user fills out the form and hits submit. The page reloads rather quickly and a couple moments later they receive a welcome email. Here's what happened. When a user registers for an account, you store their information in the database (duh) and dispatch two Jobs: one to send a welcome email to the new user, and one to send a notification email to your manager. By dispatching a Job to the Queue, you're telling your application this doesn't have to be done right now, but it needs to be done soon.
In the storefront example, once you've taken down someone's information for your newsletter, you specifically task Janet (the gal in charge of sending mail) with writing, stamping, and sending the welcome letter. You're also telling Steven, "Hey, tell Claire we have a new signup". This frees you up to just saying "Welcome!". The whole interaction is smoother and quicker.
But what if you didn't want to swivel your chair and tell both Janet and Steven what to do? What if you could just press a button called "New User" and those tasks would be taken care of in the background? That's where Events and Listeners come in. Let's rearrange this storefront a little bit. You've got a welcome desk where people can sign up for your promotional newsletter. You've also got a back office with a couple employees. On your welcome desk, you have a "New User" button that simply flashes the "New User" light in the back office. So you get a new signup, take their information down, press a button (probably under the desk like a silent alarm in a bank) and say "Welcome!". Meanwhile, you've got Lisa watching the "New User" light like a hawk in the back room. Once that thing flashes she bolts up and says "Janet! Steven! Do your thing!". Then they go off and do their job.
To accomplish this in your web app, you would define an Event (
UserRegistered) and a couple Listeners (
SendNotificationEmailToEmployee). During the registration process you would fire the
UserRegistered event and let your Listeners take care of the rest.
A Real Time (or Mind Reading) Approach
Now imagine this whole storefront signup process except that everybody can read each other's minds and you're all neurally linked.
Now, somebody comes in, wants to signup and immediately without blinking an eye, Claire knows there's a new customer, and Janet knows to send the welcome email. You barely even have to look down before you're saying "Welcome!".
Admittedly, I know the least about real-time web development and its interactions. It's something I'm going to focus on in the near future (after we launch our app).
When To Use What Where
There is absolutely room for full-page refresh and Ajax (and Pjax) approaches to rendering your site. Let's say you're moving from your main landing page to your blog. Full page refresh. Updating a single line-item? Ajax. Similar content structure on different pages? Pjax. Image processing or sending email? Queue Jobs. Doing things in response to certain interactions? Events and Listeners. Mixing and matching and using these things in combination to chain complex procedures together? Absolutely.
I'm still learning the best approach to this "delegated web". It's a different way of thinking because it pits your knowledge of what is required right now versus what is eventually necessary. It stretches out your timescale and divides up your responsibilities into more sizable chunks. It's a more calculated design decision requiring the ability to see the bigger picture. To me, it's what encapsulates the best of software design, engineering, and development.