The problem with HTML

(originally from a longer essay)

Just to offer some perspective about where I’m coming from, I’ll start by saying that I think of these as tools that made it easy for beginners to be productive:

Hypercard

Visual Basic (obviously I mean the classic versions, before .NET. The stuff in the 1990s was genius)

Adobe Flash

Adobe Dreamweaver

(Of these links, I especially recommend the one about Hypercard.)

I spent 1995 learning HTML and putting together simple websites. I was thinking this is something I’d like to do professionally. In 1996 my father and I went to a demo in New York City, where Adobe was introducing PageMill, their Web page creation software. My father was impressed. My dad wasn’t in the tech industry, but he was pretty smart about technology trends. He said, “Anyone who knows HTML just lost their job. This will replace the need to know any of the underlying technologies.” But that turned out to be wrong. Even now, in 2017, most companies building Web software still rely on individuals to hand-write their frontend code. Indeed, from the point of view of business productivity, everything has been going in the wrong direction.

This category of software, creating Web pages, was eventually taken over Dreamweaver. The software came from Macromedia which was later bought by Adobe. In many ways, Dreamweaver is a great piece of software. It makes it easy for beginners to get started, and it let’s them do some sophisticated things. But it ran into some limits. Many of the limits have to do with HTML, and the fact that HTML is extremely fragile in regards to the how elements are placed on a page. An example:

<div id=”member_benefits”>
<ul class=”benefit_types”>
<li><a href=”/basic”>Basic</a></li>
<li><a href=”/professional”>Professional</a></li>
<li><a href=”/enterprise”>Enterprise</a></li>
</ul>
</div>

I have not used Dreamweaver in many years, but I can speak of some of the problems that used to occur. Suppose you want to rearrange the list, with Enterprise on top. In Dreamweaver, you could click and drag. Sometimes this works fine. Other times, the LI element ends up outside of the UL. Other times Dreamweaver creates a new LI for the A tag and its text, while leaving behind an empty LI tag. So you would end up with 4 LI elements in a list that only has 3 options.

The problem isn’t with Dreamweaver, the problem is with HTML. It was originally meant to be a markup language for describing the structure of a document, but it later became the language people used to build graphical interfaces for most apps going over TCP/IP. Markup languages are a terrible choice for graphical interfaces. As much as possible, when creating a graphical interface, you want to use a declarative system. Ideally, a declarative configuration file can specify your entire graphical interface. The entire tech industry is largely in agreement on this. Consider that Quark Express and Adobe InDesign do not use markup languages, internally, to specify the graphical layout of the documents that they create. Also consider that before Oracle bought Sun and killed JavaFX, JavaFX was going in a very exciting direction, with a highly declarative system for specifying graphical interfaces. Also consider that every web framework ever invented has systems for specifying a graphical interface in a declarative format. If you have used Ruby On Rails or Symfony (PHP) or Grails (Groovy) or nearly any other Web framework, you are aware that you can build a lot of the graphical interface by specifying configuration data in a YAML file. But you are probably also aware that all of these systems fail at some point, and they fail because of the limits of HTML.

If we had browsers that read configuration files and rendered them as graphical interfaces, without having to translate them into HTML, then the above HTML sample could be re-written as something like (I’m going to use EDN notation, but you could use anything):

{ :id :member-benefits }

{ :id :basic, :target “/basic”, :content “Basic”, :mime-type “text/plain” }

{ :id :professional, :target “/professional”, :content “Professional”, :mime-type “text/plain” }

{ :id :enterprise, :target “/enterprise”, :content “Enterprise”, :mime-type “text/plain” }

{
:type :class
:behaviors [ :link ]
:parent :member-benefits
:members [ :basic, :professional, :enterprise ]
}

It is important to note that I could rearrange these items without effecting the output. A config like this could be made to work regardless of the order in which it is listed, with a freedom we could never have with HTML, or any other markup language. This could work the same as any other ordering of the elements:

{
:type :class
:behaviors [ :link ]
:parent :member-benefits
:members [ :basic, :professional, :enterprise ]
}

{ :id :professional, :target “/professional”, :content “Professional”, :mime-type “text/plain” }

{ :id :member-benefits }

{ :id :basic, :target “/basic”, :content “Basic”, :mime-type “text/plain” }

{ :id :enterprise, :target “/enterprise”, :content “Enterprise”, :mime-type “text/plain” }

(If you don’t like my notation here, you can imagine something similar using any of the interface building tools provided by systems such as Ruby On Rails of Symfony, but these systems could go further if they didn’t need to be translated into HTML.)

You can not randomly mix up HTML. The following would produce different results, compared to our first HTML sample:

<li><a href=”/basic”>Basic</a></li>

<ul class=”benefit_types”>
</ul>

<div id=”member_benefits”>
</div>

<li><a href=”/professional”>Professional</a></li>
<li><a href=”/enterprise”>Enterprise</a></li>

It’s the sensitivity to placement that makes HTML so fragile, and the fragility is why tools such as Dreamweaver have had trouble fully automating the creation of graphical interfaces for TCP/IP. If you doubt this, compare Dreamweaver to InDesign. Why is that Dreamweaver is never considered good enough to handle complicated designs, whereas InDesign is certainly considered competent to handle anything a graphic designer can imagine? It’s because InDesign can internally use the best system for creating graphical designs whereas Dreamweaver is forced to use a crippled system that was designed to facilitate the structuring of data rather than the creation of graphical interfaces. If your response to this is “The real problem is that Dreamweaver is creating interfaces that are interactive, whereas InDesign creates static designs” then pretend I re-wrote this whole paragraph, with the comparison being between Dreamweaver and Flash. We still arrive at the same conclusion.

Consider that Tim Berners Lee became frustrated with HTML and moved on to working RDF, which he regards as his true masterpiece. RDF is what you should use when you want to structure data. HTML is a crippled half-aborted attempt to both structure data and provide a graphical interface to it. It clearly failed. It’s inventor moved on to a system that is much better suited to the structuring and manipulation of data. But the tech world has failed to move on from HTML. Instead we have endless workarounds to try to patch its failings.

HTML was created in 1989 and in 2017 it is obsolete. The tech industry should clearly get rid of it. Browsers that consume declarative configuration files would make it easier for companies such as Adobe to create software such as InDesign that could 100% handle the creation of graphical interfaces. And yet instead, the main trend of the last few years has been to use Javascript to build graphical interfaces, while still using HTML as the base graphical language. This has lead to an explosion in complexity. Ten years ago frontenders were typically less experienced, and less well paid, than the backenders who did serious programming work. Nowadays the situation is completely reversed. Nowadays producing graphical interfaces that work over TCP/IP is one of the most complex and demanding forms of computer programming.

While there are some frontenders who enjoy the pay and prestige that frontend work now has, the tech industry should view this situation as a failure. I’ve friends who joke that with React/Relay/GraphQL the Web finally has the functionality of VisualBasic 1.0. It’s funny, but it is also a tragic waste of time and resources, and it is a tragic waste of people’s skill and intellect. In a sane world, graphical interfaces are built by graphic designers who are generally paid less than experienced software developers. The highly skilled, highly paid software developers should be reserved for tasks that are fundamentally difficult, rather than for those tasks that are difficult only because of accidents of history and the unwillingness of the tech industry to modernize.

I’ll repeat my overall theme: as much work as possible should be given to those employees who are relatively low in skill. If a graphic designer can create a great graphical interface, they should be empowered to do so. But for now, the trend in the tech industry is going in the other direction. The ability to accomplish various tasks is increasingly concentrating in the hands of the most highly trained software developers. This is not a healthy trend. While it boosts the pay and prestige of elite programmers, it undermines business productivity, as this situation allows a small pool of employees to act as points of failure. And yes, there will always be some elite employees who can act as points of failure, but an intelligent corporate strategy would work to minimize this.

Why is this happening? I suspect part of the reason is class warfare, particularly the tension between good computer programmers and the companies that employ them (I’m talking about the best 10% of computer programmers here, but I’m excluding the top 0.1% who work for Apple or Google or Facebook). Hypothetically, these top programmers could advance ideas that would make some of their work so easy that less skilled people could do it, but what appeals to them more is automating some of their work, in a manner that keeps the work under their control. The interests of these very good programmers are not the same as the interests of the firms that employ them. But it is the rare manager who has the scope of responsibilities and depth of technical know-how that they could suggest a completely different strategy.

But if good programmers want to adopt technologies that increase their own power and prestige, it is worth noting that the very biggest tech companies (Apple, Google, Facebook) have monopoly interests that overlap with the interests of the 0.1% programming elite. In theory, Apple/Facebook/Google could promote a new declarative language that makes the creation of graphical interfaces over TCP/IP extremely easy. But if their elite programmers say “We’ve come up with this new technology and there’s only 100 people in the world who really understand it” then those top companies have an interest in allowing those technologies to be widely adopted, as those top companies will always have an advantage in those technologies. They can push complex systems that gives them an edge because they have the elite programmers who best understand the complexity of the new systems.

Still, these class tensions can only explain part of the problem. I was astonished that Google (Andy Rubin? Rich Miner?) continued to use markup languages for the interfaces for Android apps. Why would they do that? I suspect the sheer momentum of dead ideas. In every field, the mainstream of thought is slow to adapt to what most awake people are aware of. Thomas Kuhn writes about this in The Structure Of Scientific Revolutions. When I read that book, I was surprised to read that Darwin’s generation of biologists never accepted his theories. It wasn’t until the early 1900s that a younger generation of biologists finally established Darwinism as the dominant paradigm of biology. There is the old joke “Science advances one funeral at a time.” I’m sad to say, the tech industry is equally resistant to modernization.

If we can liberate our minds, we will build better systems. Indeed, we must free ourselves first, before we can help others. Some of this is purely psychological. Only when our hearts are full of a sincere love of ethical craftsmanship do we gain the wisdom to resist the temptations of pridefulness, arrogance, hubris and over-reach. When we are mentally ready to set aside our old bigotries, then we will make progress. Some of the motivation of the elite programmers probably derives from the simple fact that highly skilled people tend to think the world would be a better place if they were in control of everything. This is at least partly hubris, but I certainly understand the feeling. I’ve felt that way many times too. Countless times an inexperienced co-worker has asked for my help, and after a few minutes of trying to advise them, I become frustrated with their lack of skill, so I take over the task myself. The impulse is understandable, though it is ultimately bad for corporate productivity. Highly skilled individuals need to delegate as much as possible, so they can focus on those tasks that no one else can do.

[ [ UPDATE 2019-01-06 ] ]

I just saw this recent post, which makes some good points. In particular:

Problematic how? Well, HTML, CSS, JavaScript, Python, C#, and SQL may all be code, but they’re really quite different kinds of code and are suited to different kinds of people. Just taking the frontend technologies: HTML, a metalanguage, is closely associated with language, narrative and meaning: the realm of the writer. CSS codifies form, the purview of the typographer and graphic artist, while JavaScript (client-side in this case, but the real™ programming language to a computer scientist) deals in things like data transmission and events.

This is all to say that, if you put someone in charge of all of these things, it’s highly likely they are going to be much weaker in some areas than others (I’m identifying a trend here; there’s no need to comment with “but I can do all the things”, thank you). Worse: they’ll tend to have little interest in improving in areas with which they don’t identify or for which they aren’t rewarded. In my experience, men especially earn kudos for their knowledge of JavaScript, but little from CSS skills. CSS, which makes things look ‘pretty’, is considered feminine (don’t tell that to a peacock).

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well. This has two adverse effects:

1.) Poor quality code

2.) A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”

This is similar to what I was saying above. Overall productivity in the firm is dragged down by concentrating too many responsibilities into a single person. And the architecture of the software is damaged by the lack of a clean separation between the frontend and backend.

I made a related point in “How should your company handle data safety and version control?“. Someone on Hacker News responded that learning git was easy and so everyone in the organization should do it. After several rounds of arguing, I responded with:

It is frustrating that you continue to take your advanced skills for granted. It is frustrating that you can not see what should be an obvious fact: that your skills are above average and therefore it is a mathematical fact that most people have less skill than you, and their lack of skill is a real world business situation that needs to be dealt with realistically. And more so, for the rest of your career your skills will continue to develop, so the gap between you and the average will continue to grow, and therefore the damage that you can do will continue to grow, if you fail to recognize that you are above average.