Professional Front-end Developer Guide to the development triangle

If you’re interested in dabbing your toes in the front-end development, this post if for you. Our community is rich with developers covering all major areas of development, so we reached out to one of our loyal members to share a few front-line tips with you via this mini professional front-end developer guide!

Dominic Myers is a professional front-end developer with a wealth of experience. He spends most of his day being fascinated by, developing and implementing the newest trends in web development, primarily HTML, CSS and JavaScript, or whatever will get the job done. Here he shares his professional front-end developer guide to the front-end development triangle.

A Professional Front-end Developer Guide

I’ve spent the past couple of years writing, editing (and editing some more) a book about front-end development (which you can purchase here or here), which is finally making it’s slow and ponderous way into the light. That use of words suggests that it’s a vast and weighty tome of a book – and it certainly was when I first submitted it – but after all that editing, it’s finally down to a fighting weight, and I think it’s a better book for that. One thing I was keen to point out is the triangle of technologies we, as front-end developers, need to be conversant. In much the same way that fire isn’t possible without fuel, heat and oxygen, front-end development is impossible without a more than cursory knowledge of HTML, CSS and JavaScript (JS). 


In the dim and distant past, when attending the introductory lecture for a conversion Computer Science MSc, I didn’t understand why the rest of the students sniggered when someone answered HTML when asked if we had any experience of programming. Once the chuckling had subsided sufficiently, the lecturer was keen to point out that while HTML was not a programming language, with its lack of all those things recognisable as being associated with programming languages such as variables and functions it couldn’t be; it was still a language – be it a markup language. As such, it involves a certain level of abstraction. 

The writer of HTML needs to have an appreciation of the milieu in which it will reside: the browser. Browsers themselves are unusual beasts with all sorts of wild and weird characteristics. The same browser might act differently on different architectures, or in identical hardware but with varying levels of user privileges, or with plugins installed. The unfortunate HTML author might even have to deal with superseded versions of browsers (Yes, IE11, I’m looking at you! I spend a significant amount of time massaging ES6 into ES6 for IE11, most often by hand but sometimes with Babel – but even Babel has its limits).

Along with the vagaries of the browser, an appreciation of what the browser will do with HTML is necessary. It isn’t merely rendered line by line to the user interface; instead, it is converted to Document Object Model (DOM). I like to think of the DOM as something like a tree with a trunk quickly splitting into two – one being something of a stub and the other adorned with a whole plethora of branches, sub-branches and twigs. This second branch is when the HTML writer gets to play, and the palette of elements they get to play with grows larger all the time! I guess my analogy might get strained though, my knowledge of Dendrology is limited, but suffice it to say that there are many HTML elements, some of which have fallen from favour, while still others have found favour and been embraced.

Without this tree as a foundation, front-end development is nigh on impossible. I can’t tell you how many times I’ve seen CSS or JS courses suggesting that a rudimentary knowledge of HTML is a requirement. Rudimentary knowledge? HTML is our bread and butter and, while we can use CSS to get a `div` to behave like a `span`, why not use a `span` in the first place? But this brings us neatly to our next side of the triangle: CSS.


It is arguable that if my fellow student had said CSS instead of HTML, then the laughter might’ve been even louder – this was a few years ago before you say anything. CSS acts as adornment for our DOM tree; it gives its elements’ colour if you will. That’s not to say that altering the colouring is its limit – but it’s still essential. Also, please take note of when they were laughing; CSS was then not Turing Complete (footnote: Turing Completeness denotes a language where a question is asked and answered – there is no guarantee how long that answer might take though). CSS3 was demonstrably Turing Complete in 2011, though follow through on the links please, its a fascinating read.

CSS3 is profoundly compelling and allows the canny front-end developer to avoid all sorts of weird and wonderful JS trickery. Trees in autumn can be bare and stark but can still hold a beauty all their own, but trees in the flush of Spring, Summer and Autumn are nigh on always a delight to behold. CSS serves as the foliage and, while I appreciate aesthetics plain HTML I love decorated trees, all the while knowing that without the foundation of HTML – the trunk and branches if you will – all that gorgeous adornment would be on the ground, blowing in the wind. 


CSS has taken over from JS in some areas, though there is still a tendency for front-end developers to reach for JS rather than utilise CSS.

I can understand this: if all you’ve got is a hammer, everything looks like a nail. If I can do something quick and dirty using JS rather than research the CSS technique, then I used to do that. I did before I clocked just how performant it was to use the native capabilities inherent in CSS, it’s lightning-fast so learn and use it, please!

That brings us nicely to the next side of our triangle: JS.


I dread to imagine what the reaction would’ve been to my fellow student saying JavaScript. I dare say snorts of derision rather than any form of laughter. JS has a history of being seen as something of a joke language, which is a shame as it is rather elegant – especially now.

If HTML is the bare tree and CSS is the foliage, then JS allows us to act like tree surgeons with superpowers! With JS we can make all sorts of alterations to the DOM (the DOM is, after all, merely an API for HTML). We can add, subtract and alter the constituents of the HTML with JS, we have superpowers with JS. But take heed of my caution above regarding CSS, just because you can do something with JS, first please check you can’t do the same thing with CSS! After all, with great power comes great responsibility! 


There is an excess of books and courses on JS and the frameworks and libraries that have sprung up about it. Strangely, such an overabundance can present something of a barrier to those seeking to enter front-end development. With a whole feast presented to you, it’s easy to find an old and obsolete resource and end up eating something well past its sell-by date, getting food poisoning and resolving to give it up as a bad job.

But, should you find something bright, shiny and new and that works off the bat, or drink the kool-aid by some other route, the sheer power of JS can mean that you leave good old HTML and CSS by the roadside. You might even get tempted to start implementing some CSS-in-JS and never have to touch a CSS file throughout your career, only looking at the MDN Web Docs to find out what the JS name for a CSS property is.


I think it is this disconnect between JS and the other two sides of the triangle that prompted Chris Coyier to write about “The title ‘Front-End Developer’ is obsolete.”. Something of a provocative title and one that he doesn’t endorse but uses as a launchpad to explore the confusion regarding the term “front-end developer”. Most, if not all, job postings for front-end developers will ask for one of three things: Angular, React or Vue. That list is likely to change though, and it’ll change at a rate of knots, in much the same way as the things themselves and their associated toolchains will also change. Sometimes the postings won’t even mention HTML or CSS or will suggest candidates should know SCSS, further alienating those whose bread and butter is HTML and CSS.

Does this mean that we’re looking at a further sub-division within development? The need for developers dedicated to working with the front-end led to a separation of developers into front- and back-ends. Are we now seeing a further split between HTML and CSS developers and JS developers, with HTML and CSS developers getting short shift? I’m not so sure TBH, those dedicated JS developers do generate HTML and CSS, but do so via JS, leading to a further question of how well they appreciate the nuances of both HTML and CSS? Perhaps more of a focus during preparation for the career on these would suffice. HTML is rock solid, and CSS standardised nowadays so the necessity of knowing how anything other than evergreen browsers interprets identical HTML and CSS.

I’m not sure about what to do to address the situation of this further fracturing, or even if it’s worth discussing – I’m just conscious of it, and I’m wary of losing something. JS gives you superpowers and enables the canny developer to spin a whole DOM out of nothing, made up of HTML and CSS. The superpowered JS has some mean powers but still, in the end, relies upon a thorough knowledge of both HTML and CSS, it isn’t a one-man-band. All three together and employed skillfully are an orchestra with a profound impact and rich timbre. We owe it to ourselves as developers to embrace the full triangle. a cursory knowledge of HTML, CSS and JavaScript (JS). 


Dominic Myers is a front-end developer with a wealth of professional experience. He spends most of his day being fascinated by, developing and implementing the newest trends in web development, primarily HTML, CSS and JavaScript, or whatever will get the job done. He shares his knowledge online via his blog and forums such as Stack Overflow.

If you are involved in front-end and want to share your views, visit our latest survey and help shape the trends.

Did you enjoy this professional front-end developer guide? Do you have a topic that you are passionate about and would like to share with our developer audience in our blog? Get in touch!


So… is HTML really a programming language?

Earlier this year we polled more than 13,000 developers during our biannual Developer Economics survey (updating now), and 11% of those developers told us that HTML is their primary development language – that’s Hypertext Markup Language to the uninitiated. This response immediately begs the question: can HTML really be considered a “programming language” at all, or if we should consign to being a tool for the layout of JavaScript functions?


Which is your favourite programming language? Take the DE survey and be the judge of which language will sit on the throne.

Developers answering our survey were asked to pick from a list of languages, HTML5 was on that list, along with JavaScript and more-traditional languages including C and Java. Most programmers work in more than one language, so perhaps those who selected HTML5 as their primary language really meant that they were JavaScript programmers who used a lot of HTML? It’s a nice thought, but the idea breaks down when look at those additional languages and see that only 13% of those who said their primary language was HTML admitted to also using JavaScript, so how are these people creating applications?

14% said they also use ActionScript, which can also come wrapped in HTML, but 12% of those primarily using HTML said they also program in C/C++, which is a combination we’re unlikely to see in the same project.

HTML was never designed as a programming language – the original 18 tags permitted the most-basic of layout options. The only interesting tag was the hyperlink itself; the revolutionary concept that created the web as we now know it, the rest are trivial. HTML was based, loosely, on SGML, which is another bastard offspring of XML – the eXtensible Markup Language – but the key word across these is “markup”: all three are intended to provide syntactical data to accompany textual information*, not applications as we know them.

But HTML has come a very long way since then, and has capabilities we would normally associate with a development language. Drag and Drop, Geolocation, and Local Storage, are blurring the line between applications and web sites, allowing cross-platform development where the only way to spot the difference is the title bar at the top of the window (and sometimes not even then), and there are a host of applications which bear testament to the fact that HTML can be used to create real applications.

Zero Lines JS is a fine example. A graphical game, requiring the player to navigate their ship between approaching enemies at increasing speed to a suitably-irritating soundtrack. It might not be the next Watch Dogs, or even the next Candy Crush Saga, but it would be hard to deny that it is a real application and one which (as the name infers) is written entirely in HTML with a few Cascading Style Sheets (CSS).

Less gaudy is the aptly named “You Don’t Need JavaScript for That”, which demonstrates various techniques to accomplish programmatical tasks without recourse to programming languages. Examples include a tabbed panel (bringing content to the front based on the selected tab) and an image slideshow, all done entirely in HTML5.

Purists will moan, of course, that these examples don’t make it a “real” programming language, that HTML is nothing more than a markup language made to enrich documents, and there was a time when that was true. Developers aren’t as hierarchal as they used to be, but those closer to the metal still look down on those who’ve traded an intimate knowledge of the hardware for speed of development. C programmers consider objects to be unnecessary fluff, but concur with users of C++ that anything which isn’t run through a compiler is just improper (and that includes Java with its bytecode nonsense). Java programmers consider anything without proper encapsulation to be faking its object orientation, while JavaScript developers see no reason for strong typing, and consider HTML to be a layout tool.

Meanwhile those versed in Assembler look down from their ivory towers, stroke their beards, and concur that when performance really matters they will always get the gig.

But despite being at the bottom of the heap we can see that HTML5 is being used to create applications, and it must therefore be considered a programming language. We might argue whether validating a filled-out form constitutes an application, but when you can crash a spaceship into an oncoming armada then there’s little room for discussion.

At Vision Mobile we’re currently updating our survey, asking developers what language and tools they’re now using, including those who choose to program in HTML. It will be interesting to see if an increasing number think that the layout tool has evolved, or if a momentary fad is passing. Take a look at the survey, and use the feedback from at the end to let us know how you feel about HTML being included in the list of languages, and what you think might end up on that list next time.

* To be accurate, XML is intended to be a framework from which one can derive markup languages, but that’s not really pertinent here.


The Developer Economics survey is now Live.
Have your say in which should be the next most popular programming language and you may win amazing prizes and gear. Discover more.