Some great thoughts here from Francis on how crafting solid HTML is information architecture.
A good overview of ideas and techniques for structuring CSS and naming classes.
A fascinating look at an attempt to redefine the taxonomy of online porn.
Porn is part of the ecosystem that tells us what sex and sexuality are. Porn terms are, to use Foucault’s language, part of a network of technologies creating truths about our sexuality.
Reminds of the heady days of 2005, when it was all about tagging and folksonomies.
The project, at its most ambitious, seeks to create a new feedback loop of porn watched and made, unmoored from the vagaries of old, bad, lazy categories.
Did you know that Abby Covert’s book is available online in its gloriously hyperlinked entirety?
Depending on how you’re currently structuring your CSS and class attributes, web components might not make all that much of a difference to your workflow.
I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.
The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.
A really good explanation of how a peer-to-peer model for the web would differ from the current location-centric approach.
What really interests me is the idea of having both models co-exist.
You just have to think about the ways in which our location-centrism is contributing to the problems we are hitting, from the rise of Facebook, to the lack of findability of OER, to the Wikipedia Edit Wars.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
A linkbaity title for a ranty post. But it’s justified.
My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.
And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.
URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
For almost a century and a half the West Pier has been Britain’s most iconic pier. Renowned for its wonderful architectural style, it has been visited and enjoyed by millions. Even today with its sculptural remains casting an eerie beauty over the seafront, the West Pier is still the most photographed building in Brighton.
A fantastic piece by David Weinberger on the changing uses of the internet—apparently in contradiction of the internet’s original architecture.
Some folks invented the Internet for some set of purposes. They gave it a name, pointed to some prototypical examples—sharing scientific papers and engaging in email about them—shaping the way the early adopters domesticated it.
But over time, the Internet escaped from its creators’ intentions. It became a way to communicate person-to-person via email and many-to-many via Usenet. The web came along and the prototypical example became home pages. Social networking came along and the prototype became Facebook.
Watch this space.
A look at the architectural history of the network hubs of New York: 32 Avenue of the Americas and 60 Hudson Street. Directed by Davina Pardo and written by her husband Andrew Blum, author of Tubes: A Journey to the Centre of the Internet.
These buildings were always used as network hubs. It’s just that the old networks were used to house the infrastructure of telephone networks (these were the long line buildings).
In a way, the big server hotel of New York—111 Eight Avenue—was also always used to route packets …it’s just that the packets used to be physical.
A new essay from Maciej on Idle Words is always a treat, and this latest dispatch from Yemen is as brilliantly-written as you’d expect.