OE1-5.5 Ajax, Node.js, Bootstrap & Front-End Frameworks

What this is and why it exists

One technique changed what a web page could be. Fetch data in the background and update part of the page, without reloading it.

Before that, every interaction meant a full page load. Everything in modern front-end work descends from removing that constraint.

The vocabulary

• Ajax — fetching data in the background and updating part of a page.
• Asynchronous — started now and completed later, without blocking other work.
• Event loop — the mechanism that runs a program's pending work one piece at a time.
• Non-blocking input and output — starting a slow operation and continuing rather than waiting.
• Responsive layout — one that adapts to the width of the screen it is shown on.
• Grid system — a layout scheme dividing the width into a fixed number of columns.
• Component — a self-contained piece of interface with its own state and appearance.
• Composable — able to be built from smaller pieces of the same kind.

The mental model

The background fetch is the technique to understand properly, because everything after it assumes it.

A page asks the server for some data without navigating anywhere. The request is asynchronous: it is started, the code continues, and when the answer arrives a function you supplied runs with it. That function updates the part of the tree that needs to change, and the browser re-renders only that part.

The result is an interface that responds without flashing white and losing its place. That is what made a page feel like an application, and it is why the previous topic's event model and tree editing were worth learning.

Putting the same language on the server means one language across the whole stack. That is the practical argument: fewer contexts to switch between, and code shared between the two ends.

Its execution model is the interesting part, and it is the same shape as the browser's. Rather than one process or thread per connection waiting for slow work, there is a single sequence of execution that never waits. A slow operation is started and a function is registered to run when it finishes, so the sequence goes on to other work.

That suits a server handling many simultaneous connections that spend most of their time waiting, which is what a web server does. It suits heavy computation badly, because a long calculation occupies the one sequence and everything else stops.

The styling framework is the fastest route to a page that looks reasonable and adapts to screen width. Its layout system divides the page width into a fixed number of equal columns. Each element states how many it occupies, with different answers at different screen sizes. Building one layout by hand with it is worth doing once, because the twelve-column arrangement becomes obvious and then never needs thinking about again.

Comparing it with the layout system from the first topic is the useful exercise. The framework gives you decided answers, ready components and consistency for free. The standard system gives you full control and no conventions. A framework adds speed and hides the mechanism. Knowing what is underneath is what lets you leave it when it stops fitting.

Its ready-made components are the actual reason people reach for it. Navigation bars, dialogs, alerts, dropdowns and form controls that already work and already adapt. Knowing what exists prevents rebuilding one of them badly, which is a common way to lose a week.

The trade is honest and worth stating. Sites built this way tend to look alike, because everyone is using the same decided answers.

The component model is where current front-end practice is, and it is the item pointing furthest forward. An interface is built from self-contained pieces, each owning its own state and describing its own appearance, and larger pieces are composed from smaller ones.

The shift that makes it work is worth naming. You no longer describe the changes needed to move the page from one state to the next. You describe what the interface should look like for a given state, and the library works out the changes. Editing the tree by hand, from the second topic, is what that replaces. On any large interface it removes a considerable amount of error-prone work.

The older manipulation library closes the course, and it is here for historical literacy. It existed because browsers disagreed with each other and the standard facilities were awkward, and it smoothed both over. The standards then caught up and absorbed most of what it offered. You will meet it in existing code, frequently, and you will rarely start new work with it. Both halves of that sentence are worth carrying.

What you should now be able to explain or do

Explain the background fetch and why it changed what a page could be. Say what asynchronous means and how a result is delivered. Describe the single-sequence server model and say what it suits and what it does not. Compare a styling framework with the standard layout system on control, speed and conventions. Explain the component model and what it replaces.

Check yourself