we write about the things we build and the things we consume
Dan Govan

‘just’ html

As a front end developer I’ve always operated in the weird no man’s land between web design and software development, doing work that can mostly be described as tinkering and jury-rigging. Years ago it was mostly making the app look like the design, making the design fit the copy and wiring the copy into the app. These days it’s more making sites work at every width with varying content while still being in line with the designs, or putting together a prototype app that brings new functionality in an intuitive manner.

The field’s been expanding in all directions since I started out, but people outside the bubble still think the work is as simple as an image tag. I can think of a few reasons why: it’s mostly human-readable, what it produces is entirely relatable (everyone has opinions on design), and it’s also gotten more involved since a lot of people last tinkered with it.

But the more interesting angle is that dabblers and tangential technologists only see the problems once they’ve already been solved, so I had an idea to introduce a shorthand analogue to the most common technologies used to make websites and find a new way of looking at some dear old friends.

design == decoration information architecture

On top of looking cohesive and presentable your page has maybe 1 second to load, and then about 3 seconds to communicate that it’s both authoritative and informative. When people are sniffing for data they’re super impatient. Javascript on the other hand…

javascript == programming decoration

In terms of the front end, the core functionality should always be there without JavaScript. It’s the single largest point of failure in delivering a web page by a long way. So hopefully it’s mostly DOM manipulation, progressive enhancement and micro interactions to make the UX smoother and more intuitive. Of course if you’re using a bunch of frameworks it’s a different story.

html == markdown semantics

It’s not enough to just transcribe the content inside angle brackets. On top of fitting the design we also need to think about how it linearises when accessed via a screen reader or if CSS fails, and how it’s going to be broken down by google spiders for some SEO goodness. But at its core it’s ‘just’ naming, which everyone simultaneously agrees is easy and very hard.

css == pretty colours mechanics

Every web page is a mechanical system, where you nudge things one way or the other by floating, positioning, transforms, margins or paddings and then stack it all up like reverse tetris, in spite of the fact you don’t know the lengths of the contents or the width of the browser window. As a nice illustration, the units I’ve used recently are px, %, ems, rems, vmin/vmax, and vh/vw and there are plenty more. It’s all about understanding what is built relative to what, how those change in relation to each other. Having studied mechanics at uni they feel very similar. Just with much less maths!

Hopefully this has given a bit of alternative non-technical insight into what these much-used words can mean in different situations in modern webdev. It’s not just front end of course; “just” is a word that should probably be excised from the workplace altogether!

blog comments powered by Disqus
sign up to #metabeers