Home Blog CV Projects Patterns Notes Book Colophon Search

The Disappearing Web

8 Aug, 2016

Back in the day the web used to be very simple. Your browser sent a GET request to a URL, the server returned an HTML page and the browser displayed it.

Since then, user experiences can be improved using AJAX so that partial page updates are possible, and with JS and CSS3 to make certain things animated, but the basics are still the same until relatively recently.

Disappearing URLs

Today, one of the most fundamental parts of the web is disappearing - the URL.

Back in 2009 I repeated the advice in my book that URLs are an element of navigation and that cool URLs don't change.

Well, in 2016 I don't think that advice applies any longer. If you look at the Safari browser on recent Mac OS X browsers, the only thing that is shown is the domain name! There is no path at all, so no point in having a neat URL structure for your users - they won't see it unless they click.

Jimmyg.org

If the site has an expensive security certificate, even the domain isn't shown, and instead the name on the certificate is shown:

GitHub

If URLs aren't so important today then what does that tell you about the importance of the web's architecture?

It tells me that:

The resource model isn't as important as it used to be to humans - maybe REST isn't the be-all and end-all (although it is still incredibly useful for APIs)
The different devices on the web today mean that authoring data should be handled differently from retrieving it

Inputting Data

I think the old model of browsing URLs with GET requests in a browser still works really well for consuming data. But I no longer believe it is the best way of inputting it. The reason is that we now have a huge array of devices for inputting data on. Each device has native UI components specifically tailored to its different affordances - for example if you want to enter a date, a pocket smartphone begs to be swiped, whereas for a mouse and keyboard you'd want to use clicks or typing. Expecting to be able to give a single great inputting experience with every type of hardware (or voice even!) is asking a lot.

Let's take a look at the main way of inputting data on the web - HTML forms.

It is fair to say I've never really been 100% happy with HTML forms. I think there are three main reasons:

For one thing, anything other than very simple forms are hard to do well (as you can see from the length of the Solving the repeating fields problem section in the forms chapter in my book).
I want to take advantage of the hardware I'm using to enter my data, not be forced to use a model designed for mouse. (Yes I know that forms are supposed to be navigable by keyboard but when was the last time you actually did that?). I want to be able to swipe and tap to enter data on mobile.
Thirdly, why should I have to be online to create data? It makes sense that I have to be online to get it from the web, but if the data is in my brain, the server shouldn't need to be involved until I'm ready to send it.

I think these are three of the reasons why apps have been overtaking the web in lots of areas in recent years. Of course you can fix all three of the above using web technologies alone (Service Worker, Web Components etc), but doing so requires large teams and modern browsers.

Although I think the web as it used to be is becoming less relevant as a consumer-facing thing, it isn't going to lose its importance because in most cases the it is still there behind the scenes - powering everything - you just don't see it as much any more because you don't tend to access it via a browser unless you are retrieving content. In effect, the web is disappearing, even though there are more and more devices on it all the time.

The role of React

React has changed the way people build applications - both on the web where it started and on native platforms including Mac OS X, Ubuntu, Android and iOS.

I've implemented lots of different architectures with React myself and watched as the community moved first to Flux and then to Redux.

All that time, I've insisted for my own applications, that the original principles of the web aren't broken in my code:

I've ensured that state transitions are within major states that are reflected in properly designed URL paths
That state transitions, can show progress bars, can be cancelled and that back and forward buttons work
That minor state change results in changes to the URL fragment

I've also insisted that every URL that the app can generate can be used to load the app back into that state.

In fact I've gone even further and ensured that any URL can also be viewed and navigated from a legacy browser by means of server-side generation of those pages into HTML, that pages get re-hydrated from JSON sent with them and that animations don't break.

Of course, this style of isomorphic or universal app is considered a sort of holy grail in web development and I was initially pleased to have achieved it.

But then when would I actually use it? Well, needless to say that all this work to protect the URL is a lot of work. Given that the the web is disappearing and even when it is not, the URL is disappearing, it seems pretty clear to me that I should just not have bothered making my apps behave like the web.

The reality is that there is normally a clear architecture divide between things that still need to be web-like (e.g. your main marketing website, help pages etc) and things that can be app-like (i.e. everything you see after you have signed in).

This leads to a clear conclusion for me that I think would work for lots of use cases:

Build tools that let users input data as native apps using native interfaces, making the best of whatever constraints that device has (or using a browser if that still fits your use case)
Send data to a backend server running on the web (perhaps Django, or hexagonal microservices)
Still let customers consume data via a browser using good old fashioned HTTPS with HTML and Etags etc. You get the benefits of search engines finding the content, and people being able to share easily.

The only thing I'd say is that building microservices can be costly, and requires a very solid test-driven-development basis, so I'm usually happy to build a monolith out of something like Django first, but bearing in mind the constraints.

The truth of it is that whatever you build will be judged by how well it suits your users, and how much revenue you generate as a result, not by how perfect its implementation is. The work of the product team is at least as important as appropriate architecture and engineering anyway.