![](https://hackernoon.com/hn-images/1*Hwpb_77Vur6yQaYveatMWw.jpeg)

The web is in an awkward phase right now. We’re transitioning from an era where a website was simply a collection of linked pages to one where even using the term “page” to describe a particular screen is a giant oversimplification.

When I first started web development, the job was mostly . . .

1.  Type up some HTML
2.  Add a little styling
3.  FTP that baby up to your server and . . .

Boom; you’ve published to the internet. Let’s just say it’s rarely that simple anymore.

While it’s tempting to bemoan the loss of that simple early web, it’s important to realize that _the early web was simple because the use cases were simple_. The web was primarily an online index of documents that could link to each other.

The modern web is a mixture of complex interactions, responsive content, and social layers that make a document-centric approach an awkward paradigm that isn’t scaling well to user expectations or needs.

### The web wasn’t meant to be this way

It’s a little known fact that the simple document-based approach to the web was not the desired outcome for the early-innovators who built the foundations for the web we know now.

Pioneers like [Ted Nelson](https://en.wikipedia.org/wiki/Ted_Nelson), [Alan Kay](https://en.wikipedia.org/wiki/Alan_Kay), and [Doug Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart) pushed for ideas that go far beyond what we have today. They presented fantastic visions of a future where computing embraced its true digital and collaborative nature to become something entirely new and more powerful.

What we got instead was a bunch of digital documents in digital folders; it does the job, it’s familiar and comfortable, but we’ve lost a lot by taking that path.

![](https://hackernoon.com/hn-images/0*BzhPdpBKbeL6h2s2.jpg)

The web we wanted / The web we got

**Documents and pages are the wrong construct for the modern web**. I would argue the web should be built in blocks (or components if you will), not documents.

Blocks provide a different way of thinking about web content as a self-contained unit. Perhaps it’s helpful to visualize at a lego brick which you can build documents (or apps) with.

In the developer world we call these “components” whereas content creators might call this “micro-content.” For the sake of this article I’m referring to both of these concerns, among others, simply as a block.

I’ll explain what I mean and why this is a better approach for publishers, end users, and developers alike.

### 1\. Blocks are structured

An open text document, which is where the web started, has no inherit meaning. Any added meaning has to be layered on through tags, meta information, or formatting. There have been many efforts to enrich textual content with more structured meaning over the years and most of these have fallen flat ([the semantic web](https://en.wikipedia.org/wiki/Semantic_Web) for example).

The problem is multi-faceted, but I think the root of the issue is that the meaning and structure is layered on _after the fact_ rather than being _core part of the creation process_.

Blocks flip that idea on its head: you don’t markup content as being a heading, you _create_ that content as a heading. That’s a subtle but profound difference.

### 2\. Blocks are composable

Blocks provide a way to take discrete units of both content and function and put them together in different ways without sacrificing the integrity of the system.

Much effort has been spent trying do this with “native” web technology via complex CSS schemes (BEM, SMACKS etc.), XML, web components, etc. While some solutions are more elegant than others, these techniques try to force a modular, block-centric workflow on document-centric medium and the results are awkward and cumbersome at best.

This problems is largely solved with component-centric frameworks like React or Vue that make the components _the_ first class citizen.

That said, these frameworks have to rely on complex tooling to get out of that document-centric paradigm and put components (blocks) at the top where they should have been all along.

### 3\. Blocks are resilient

Encapsulation is a principle used by programmers to make code more reusable and reliable for decades but it applies equally well to blocks.

Thinking of your content and UI as modular units and then _actually developing them that way_ removes the dissonance of trying to develop block-based content with document-based tech and makes it much easier to ensure quality.

Our team has components we haven’t touched in years that are completely self-contained and Just Work™.

### 4\. Blocks improve collaboration

Blocks are structured enough to allow for a richer form of collaboration than a document can. Historically editors have had to “get out the red pen” or highlight, underline, and leave notes in the margin to give feedback on documents.

Imagine how much better it could be if feedback and reference tools were actually _aware_ of the type of content referenced? For instance, leaving feedback on a video block might timestamp to exactly the spot the feedback was for. Checking the source of a quote could be done automatically in quote block.

Content editing tools are far more powerful when the structure and meaning of a piece of content is known from the beginning and not just layered on afterwards.

I could elaborate more on all of this but this post is getting quite long so I’ll leave you with this:

As awkward as web development can be these days, I think the tides are turning. We’re moving toward something much better that can embrace the digital medium’s true nature.

For now we have to circumvent the document-centric nature of web development through tooling and component based web frameworks, but I’m optimistic these patterns will become more native to the platform over time.

Meanwhile, some of the content creation tools of the future are being built right now using a blocks-centric approach so you can already experience the difference for yourself.

Here a few of my favorite examples:

*   [Notion](https://www.notion.so/): a block-based collaborative workspace for practically any type of content. Notion is probably the best example of the power of a block-based approach to collaborative content.
*   [Universe](https://www.onuniverse.com/): An iOS app for creating web pages from your phone using simple but powerful blocks.
*   [Qwilr](https://qwilr.com/): A block-based tool for creating sale pages, proposals and contracts. This one has been super helpful for creating quick proposals that look great and convert even better.
*   [Wordpress Gutenberg](https://wordpress.org/gutenberg/): The new Wordpress editor is betting heavily on a blocks-based approach to content publishing (a little awkwardly at this point IMO).

We’re only at the beginning of this shift. My hope is that we can all work together to build the web we’ve always wanted, one block at a time.

🤘Block on.

_Originally published at_ [_www.pathwright.com_](https://www.pathwright.com/blog/blocks-are-the-future-of-the-web/)_._

BUNCH

Super

Too Long; Didn't Read

Web Development & Ecommerce Writing Contest

Blocks, Not Pages, Are the Future Of the Web

Too Long; Didn't Read

Companies Mentioned

@wmdmark

RELATED STORIES