It’s a well-known fact that the less code one has to maintain independent of other projects, the better the project, all things being equal. In some fields, it’s even considered a liability to use your own code, such as cryptography. But on the web there is a major tendency for every site to have its own front-end, back-end, CSS, and so on.

Some of that goes away with new versions of the HTML specification, such as where new widgets like <input type="number"/> supplant the need for different platforms and libraries to create their own version. But a lot of it doesn’t, as the bigger picture isn’t tackled.

This creates problems, such as the well-documented use of CSS vendor prefixes breaking the mobile web. In this famous case, a ton of mobile sites use WebKit-specific CSS rules, and non-WebKit mobile browsers don’t render those sites as nicely.

There are varied proposals for how to fix that situation. My favorite is for Vendor Prefixes to have a built-in timestamp after which they do not function for any browser. But even the best proposals are working around the larger problem of websites having too much of their own code.

The more code, the more problems. The harder it is to create the web, the harder it is to maintain it, and the harder to evolve it.

The more code, the more duplication of effort by countless developers the world over to do the same things.

According to studies, the average page weighs in at about a Mibibyte (2^23 bits), with an average of nearly 100 objects (mostly graphics), and the growth continues.

It’s clear that this entire paradigm for creating programs and sites will have to change at some point. We’re still in an era where humans and raw data touch way too much, rather than having managed data objects that humans can handle more effectively.

Take, for example, writing a style sheet. Oops, you made a typographical error. Your page doesn’t work right, but is that because of a failure of understanding, a bug in the browser, or some unseen error in: your style sheet, your JavaScript, your markup? Maybe it’s a caching problem.

There are some IDE-type editors, that might give you suggestions as you type a selector, but they don’t know exactly what your intention is, so they invariably defer to your mistakes.

A similar problem occurs when you want to recreate one piece of a page in another project. You are digging out the markup, the JavaScript, and the styles separately. But you have to update them all to fit with your other project, and that requires an omniscience of the namespace and behavior of the other project.

This is ignoring the cargo-cult programming phenomena, which is another by-product of too much code. Too much code in that case means that a novice who might otherwise understand the code will stare at the screen, give up, search for code, copy, paste. It fails, so maybe they paste a bunch of other things. Finally it works, and they move on, leaving a horrible mess just waiting to fail in some new and interesting way.

The question is how to fix it. Syntactic sugar goes a long way. Python tends to be much better than other languages simply because of its focus on readability. But it can still be turned into a garbled mess with enough ignorance and/or effort and/or haste.

So, I say again, the real solution lies in making data into managed objects. Look at the filesystem abstraction. It’s very rare that someone corrupts their filesystem through normal interaction. Open a file. Copy a file. The user isn’t touching the data. They’re touching an interface that touches the data, just like nobody manipulates the voltages running into an arcade game directly. They touch the controls of the game, which handles the electrical signals to the game.

One good example of a tool that works toward this is Inkscape, the vector editor. You can manipulate the SVG (Scalable Vector Graphics) file directly as XML (eXtensible Markup Language), but you can also let a tool like Inkscape manage the data objects for you.

But in the long term we need to be more willing to say that certain behaviors aren’t available from the default interface. To create more lite versions of things that can predominate where the complexity isn’t needed and certainly isn’t adding anything.

My favorite example of that is for online banking. I really do not believe that online banking should happen in a browser or on the web. It makes much more sense to have a dedicated protocol with a dedicated client for that. Something that doesn’t expect to be loading all sorts of complex data in a complex manner.

That isn’t to say a bank shouldn’t have a website. Banks should have websites, but they shouldn’t be the means of account access. They can be used for informational and advertising/brand purposes, sure.