“HTML is easy”, “Developing a front-end is easier than a back-end”, “Once the back-end is implemented, updating the UI should not be difficult” – these and other similar statements were heard around me every now and then during my work in the field of web development.
And very often they made me sad.
The fact is that I spent most of my time writing the front end, including working with HTML, CSS and JavaScript (in fact, mostly TypeScript). When someone tells me that my job is “easy”, I start to think that my skills are not very valuable and that I can be easily replaced by any developer…
In the article, I decided to describe my thoughts that were born over the past two years while working with people from different teams with different experience in HTML development and front-end technologies in general. Here I will voice several of my main questions “Why?”, accompanied by possible answers.
▍ Why do people think HTML is easy?
What does “simple” even mean? The simplicity of any object is usually determined in relation to the person viewing it. When I know a certain technology or programming language well, this subject turns out to be easier for me than for a beginner.
Some people tend to make guesses about the complexity of front-end development, and in my experience this usually ends up being those who don’t work in this area regularly, especially with HTML.
Here are a few reasons that, in my opinion, explain this:
- HTML syntax is not difficult to learn. Combine angle brackets, tag names and key-value pairs (attributes) and you’re done!
- HTML syntax is both human and machine readable, which is one of the main ideas of XML-like languages.
- After writing a few lines of code in the file
.html
You can immediately view the result without compilation by opening it in a browser. - HTML has a low barrier to entry. Some WYSIWYG editors have an option to switch the view to “code”, where you can redo the HTML version of the text without even really understanding the process (you can see a preview, what could go wrong here?)
- Browsers are wonderful tools that forgive you a lot of mistakes (J. David Eisenberg described this in his old article, giving thoughts that are relevant to this day). When you open an HTML page with syntax errors, the browser will still render something. Forgot to close a tag? No problem. Added an unknown tag or attribute? The browser will simply ignore it. Compared to a language in which the entire program crashes because of a missing semicolon, this state of affairs actually feels “simple.”
Okay, let’s get this over with. Next we’ll look at why people tend to compare web technologies or contrast front-end development with back-end development.
▍ Why do people think front-end development is easy?
The most difficult part is programming the backend of the site or application, after which creating the frontend is no longer difficult. Right? Sometimes it seems to me that this is exactly what many developers think.
Trying to understand “Why” they think this way, I came to the following conclusion:
Users and project stakeholders often do not encounter the business logic of the backend and work only with the UI. Thinking about the placement of different buttons, information elements, or the overall operation of the UI is easier because it is more tangible compared to complex database queries or nested loops for
and instructions if
. The backend is a black box that does its magic and simply spits out data to the frontend. The front-end developer ultimately “just” needs to display this data, add colors and build the layout (using CSS), thereby finishing the job.
Fortunately, there are many client component libraries available to us in this process. All you have to do is combine several (ready-made) views, fill them with data, and you don’t even have to think about colors and layouts – isn’t that cool? With this kind of comprehensive help, almost anyone can create great front-end solutions without having to know much about HTML/CSS!
</sarcasm>
▍ Frontend by non-frontend developers
I have personally observed how people who consider front-end programming an easy task (who call themselves not front-end, but full-stack developers) made the most serious errors in their code (even when using frameworks and libraries).
Gaydon described this topic in the article “Reluctant Gatekeeping: The Problem With Full Stack“:
[…] if you assign all these and other tasks to someone else […]he will likely be significantly weaker in certain areas than others. […] In my experience, men are more likely to demonstrate knowledge of JavaScript or Python, but not CSS. CSS, which gives everything “beauty,” is considered a woman’s domain.
Some of the serious errors I identified were syntactic, others related to semantics, performance, accessibility, and so on. In prototype views, they often go unnoticed during testing because the browser is not strict with them, performance on the developer’s machine is usually high, and accessibility tests are not performed… As a result, everything works, the browser displays the expected view, and the developer concludes that the code is ready for transfer to production.
Why is incorrect HTML code a problem?
The first problems may begin to appear after the code is deployed to production. Users who were not involved in the development will encounter them when they begin to interact with the product. Some of these problems may result from errors in the HTML code.
▍ Inconvenience for the user
Let’s look at the problems caused by incorrect HTML code that the user may encounter:
- Inconvenient forms (I have separate article with examples of problems when using forms).
- Poor performance (there is an interesting story on YouTube called “Get your ‘head’ straight“, in which Harry Roberts talks about possible problems in the header of an HTML document.
- Incorrect use of headers (
h1
–h6
) or missing text alternatives for non-text content, causing inconvenience for those using a screen reader. - Incorrect use or non-use of interactive elements (“Div is not a button!”) or unintuitive tab order between them, making navigation and keyboard interaction difficult.
- In principle, everything that is described in htmlhell.dev.
- Incorrect HTML code leads to incorrect JavaScript operation, and therefore non-functional functionality.
▍ Inconveniences for the developer
Problems with using your product due to incorrect HTML/front-end code may not only arise for users. Your fellow developers may also be scratching their heads at times because…
- …when HTML code is poorly structured, it becomes more difficult to write CSS for it. In other words, after joining the CSS development process, the HTML code often needs to be adjusted. When you have experience with both of these languages, your HTML and CSS code is likely to be good and maintainable.
- …if the HTML code of your project’s UI components is not flexible enough, then when you add new functionality, you may not be able to reuse them or scale the project in principle without resorting to refactoring.
- …when developers don’t work with the platform and try to reinvent the wheel without taking into account the capabilities of browsers (for example, implementing transition between pages not using a link, but through JavaScript), the likelihood of bugs increases, which can be fixed without breaking the rest of the application. turns out to be more difficult.
▍ Why is this important?
As mentioned above, browsers are wise and forgive us many mistakes. Sites can remain functional for many users, even if they are sometimes inaccessible, load slowly, or sometimes crash. Maintaining such sites is also quite doable if you find good-hearted developers who don’t mind tinkering with the smelly code base.
But I am sure that we are capable of more.
We, as developers, should strive to ensure that sites and applications work for the majority, nay, all Internet users, and create products that meet the needs of all our (potential) customers. Writing scalable and maintainable code not only leads to accessibility, speed, and usability of sites, but also makes life easier for developers.
▍ It’s not just about writing HTML
I’ve met people who started their web development journey by diving headlong into mastering the latest frameworks, then building a simple website using Angular, neglecting to learn the basics. The problem here is that if you don’t have basic knowledge of HTML (CSS or JS), most of the well-known frameworks will not help you achieve success, quite the contrary. In this case, it can be compared to cracking a nut with a sledgehammer. No matter what tools or latest technology you use, it’s the HTML, CSS, and JS code that ends up sent to the browser, so knowing how these languages work is essential to building good apps.
Writing HTML in itself really isn’t difficult.
But! Building user interfaces by elegantly laying out language features using CSS, creating a pleasing design and a memorable user experience requires skills that should not be underestimated, just like HTML. After all, it is one of those languages—perhaps the most important—that shape the web.
A similar position regarding the value (experience) of web development was shared by:
- Christian Heilmann, who defended self-sufficiency of front-end development as a full-time job.
- Jeremy Keith, who worriedthat we can “reach a point in the industry where complex, hyper-engineered solutions become the standard approach to web development.”
- Andy Bell, who believes that frontend is much more than design.
Let’s stop comparing web technologies and their value. We will not discuss what is easier/more difficult or more/less important. Let’s work in teams, listen and learn from more experienced people, whether they are experts in HTML, CSS, TypeScript, PHP, Python or [назовите свой язык]… Let’s work together to make the Internet a wonderful space and value the people who primarily work on the front end!
Discounts, raffle results and news about the RUVDS satellite are in our Telegram channel 🚀
Acknowledgement and Usage Notice
The editorial team at TechBurst Magazine acknowledges the invaluable contribution of Дмитрий Брайт the author of the original article that forms the foundation of our publication. We sincerely appreciate the author’s work. All images in this publication are sourced directly from the original article, where a reference to the author’s profile is provided as well. This publication respects the author’s rights and enhances the visibility of their original work. If there are any concerns or the author wishes to discuss this matter further, we welcome an open dialogue to address potential issues and find an amicable resolution. Feel free to contact us through the ‘Contact Us’ section; the link is available in the website footer.