HTML and Typescript.
With the increasing focus on JavaScript in Front End Development I have regularly found myself trying to explain to JavaScript, and Back End orientated developers why using HTML as it is intended is important, and why using a <div>for everything is not going to give you the best results.
So enter TypeScript, a popular way of building complex, large JavaScript applications.
TypeScript can often be found on JavaScript heavy tech stacks, if you aren’t familiar with TypeScript, or any typed languages this post probably isn’t for you.
If you are still intrigued, TypeScript is essentially a typed JavaScript language that does everything JavaScript does plus some extra stuff. It makes use of static typing so, for example, you can give your variables a type when you write your code and then TypeScript checks the types at compile time and will throw an error if the variable is given a value of a different type.
A simple example of a Typescript Interface defining a dog.
interface dog {
name: string
age: number
isFluffy: boolean
}Here I defined my interface called dog. I have a name with a type of string, an age with a type of number and isFluffy with a type of boolean.
If I try to give name a value that is of the type number TypeScript will throw an error because the value and the type don’t match. We tell TypeScript what we expect the data to be. This makes debugging, writing, reading and working with our code a lot easier because we are being explicit about what shape our data should be.
Which is essentially what we do with our HTML. We are explicit about what our content should be.
Whether it’s a heading, what kind of heading it should be, a list, a header, navigation, bold, italic, dates, image, paragraph, section— there is a whole suite of elements we can choose in order to best represent our content. We are simply assigning a type to our content.
And we do this to define the shape of our content to make it easier to write, read and work with, not just for us, but other technologies as well.
In TypeScript, we have the concept of an any type. When you assign a type of any it means the content can be anything. So name can be a number a string or even a boolean value. But if everything is typed as any then you lose the benefits of the language.
interface dog {
name: any
age: any
isFluffy: any
}This is the same with HTML. If you use the <div> everywhere, you aren’t making the most of language. Because of this it’s important that you actively choose what the right element is and don’t just use the default <div>.
If you choose a generic element, you will get generic output.
To quote Jeffery Zeldman
“…to build for people and the long term, then simple, structural, semantic HTML was best — each element deployed for it’s intended purpose. Don’t use a div when you mean a p” — Jeffery Zeldman
That’s it pretty simple. Get to know the HTML elements available to you, and use the appropriate one for your content, pick the right type. Make the most it, like you would any language you choose to code with.
HTML isn’t just the foundation for our websites and web applications, it plays a vital role in making them accessible, usable and performant across platforms and technologies. If you use HTML to it’s full potential you’re not just making the most out of built in features you’re making it more functional for people, bots, and for any tech, not just now but in the future as well.
So why make all your content anything, when it can be typed more explicitly.
Note: There are many great resources out there on HTML and it’s value, so I highly recommend reading up on it. Here are some places to get started.
- Building websites for Safari Reader mode, Mandy Michael
- HTML elements, unite! The Voltron-like powers of combining elements, Mandy Michael
- The intersection of Performance and Accessibility, Eric Bailey
- The Practical Value of Semantic HTML, Bruce Lawson
- Semantics to Screenreaders, Melanie Richards
- Semantic CSS, Snook
