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 . . .
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.
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, Alan Kay, and Doug 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.
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.
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 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.
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.
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™.
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:
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.