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).
HTML
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.
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.
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.
Thoughts
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).
About
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!
