Frontend development is a dynamic and ever-evolving field. With the constant introduction of new frameworks, libraries, and tools, it's easy to make mistakes, especially when you're under pressure to deliver a project quickly. In this blog post, we'll explore five common mistakes that frontend developers often make and provide practical solutions to fix them. We'll also include code examples to help you understand how to implement these fixes in your own projects.
1. Not Using Semantic HTML
The Mistake:
One of the most common mistakes frontend developers make is not using semantic HTML. Instead of using appropriate HTML elements like <header>, <nav>, <main>, <section>, and <footer>, developers often rely heavily on <div> and <span> tags. This can lead to poorly structured and inaccessible web pages.
The Fix:
Semantic HTML not only improves the readability of your code but also enhances accessibility and SEO. Use semantic elements to describe the structure of your content.
Example:
<!-- Bad Practice -->
<div id="header">
<div class="nav">
<div class="nav-item">Home</div>
<div class="nav-item">About</div>
</div>
</div>
<!-- Good Practice -->
<header>
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
</ul>
</nav>
</header>
In the good practice example, we use <header>, <nav>, and <ul> elements to create a more meaningful and accessible structure.
2. Ignoring Responsive Design
The Mistake:
Another common mistake is not implementing responsive design. With the variety of devices and screen sizes available today, it's crucial to ensure that your website looks good and functions well on all devices. Ignoring responsive design can lead to a poor user experience.
The Fix:
Use CSS media queries to create a responsive layout. Additionally, consider using a mobile-first approach, where you design for smaller screens first and then add styles for larger screens.
Example:
/* Bad Practice */
.container {
width: 1200px;
margin: 0 auto;
}
/* Good Practice */
.container {
max-width: 1200px;
margin: 0 auto;
padding: 0 20px;
}
@media (max-width: 768px) {
.container {
padding: 0 10px;
}
}
In the good practice example, we use max-width instead of a fixed width and add padding to ensure the container adjusts to different screen sizes.
3. Overloading JavaScript
The Mistake:
Frontend developers often rely too heavily on JavaScript for tasks that can be accomplished with HTML and CSS. Overloading JavaScript can lead to performance issues, especially on low-powered devices.
The Fix:
Use JavaScript only when necessary. Many interactive features, such as dropdown menus, modals, and animations, can be implemented using HTML and CSS alone.
Example:
<!-- Bad Practice -->
<button onclick="toggleDropdown()">Menu</button>
<div id="dropdown" style="display: none;">
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
</div>
<script>
function toggleDropdown() {
const dropdown = document.getElementById('dropdown');
dropdown.style.display = dropdown.style.display === 'none' ? 'block' : 'none';
}
</script>
<!-- Good Practice -->
<details>
<summary>Menu</summary>
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
</details>
In the good practice example, we use the <details> and <summary> elements to create a dropdown menu without any JavaScript.
4. Not Optimizing Images
The Mistake:
Images are often the largest assets on a webpage, and not optimizing them can lead to slow load times and a poor user experience. Frontend developers sometimes forget to compress images or use appropriate formats.
The Fix:
Optimize images by compressing them and using modern formats like WebP. Additionally, use responsive images with the srcset attribute to serve different sizes based on the user's device.
Example:
<!-- Bad Practice -->
<img src="large-image.jpg" alt="A large image">
<!-- Good Practice -->
<img
src="image-320w.webp"
srcset="image-320w.webp 320w, image-480w.webp 480w, image-800w.webp 800w"
sizes="(max-width: 320px) 280px, (max-width: 480px) 440px, 800px"
alt="An optimized image"
>
In the good practice example, we use the srcset attribute to serve different image sizes based on the viewport width, ensuring faster load times.
5. Not Testing Across Browsers
The Mistake:
Frontend developers often test their websites only on one or two browsers, usually Chrome and Firefox. This can lead to inconsistencies and bugs in other browsers like Safari, Edge, or even older versions of popular browsers.
The Fix:
Always test your website across multiple browsers and devices. Use tools like BrowserStack or CrossBrowserTesting to ensure compatibility. Additionally, consider using CSS prefixes and polyfills for older browsers.
Example:
/* Bad Practice */
.box {
display: flex;
justify-content: center;
align-items: center;
}
/* Good Practice */
.box {
display: -webkit-box; /* Safari */
display: -ms-flexbox; /* IE 10 */
display: flex;
-webkit-box-pack: center; /* Safari */
-ms-flex-pack: center; /* IE 10 */
justify-content: center;
-webkit-box-align: center; /* Safari */
-ms-flex-align: center; /* IE 10 */
align-items: center;
}
In the good practice example, we use CSS prefixes to ensure that the flexbox layout works correctly in older browsers.
Conclusion
Frontend development is a challenging but rewarding field. By avoiding these common mistakes and implementing the fixes we've discussed, you can create more efficient, accessible, and user-friendly websites. Remember to always use semantic HTML, prioritize responsive design, minimize JavaScript usage, optimize images, and test across browsers. Happy coding!
Top comments (23)
Valid points.
Though the example of dropdown menu is not correct, e.g. it does not satisfy your first point of semanticity. You could have simulated the details tag using javascript but using it as a dropdown menu is just not it.
Thank you for writing! I agree with most things, but I do have a remark about the example you give with the "Not testing in different browsers".
I totally agree with that testing in different browsers is always good to do! There are some minor differences between the different modern browsers and sometimes they need to be fixed. But supporting browsers that are end-of-life more than 3 years (Internet Explorer) is maybe a bit overkill. Also I think most of the CSS prefixes are not needed anymore, only for some experimental features maybe.
Can't recall it from the top of my head but unfortunately prefixes are still a thing, I finished a project a couple of months ago and umm .. ash! Line clamp! Atm you have to use prefixes for that... It's an ever flowing thing as it seems, just using the default fallback and the need for prefixes falls off eventually with better browser support, caniuse is a friend.
Oh yeah there are sure some prefixes still used/needed (unfortunately). But the 'great days of wild prefixes' are mostly over. Especially with grid and flex. So it was maybe more about the specific example given.
And yes caniuse is a great resource.
Good points. The biggest mistake for me, as a front end developer for over 20 years, is being a front end developer for over 20 years 😆. Reason: Not diversifying enough because the tech stack scope creep that seems more important to recruiters and companies than basic html, css, javascript and the browser. Though these bullet points like html 5, semantic, accessible, x-browser, (even oldschool xhtml, xsl) mobile responsive detail on a cv were like badges of honour they are small fry on the percentage of desirability.
Word of advice, once you master these, don't just stick with nextjs, typescript, npm . Connect the other dots like databases and cloud services. Yes semantic markup is important but its not going to land people on your nicely formatted web page. Seo web performance, bundle size and overal web feel and interactivity will steal the show, and if you can only do semantic markup it you limit your attractibility.
Great point! 2years of dedicated FE behind me and I can say I'm truly greatful for being able to get invested in all of these fields... Next up is Next.js, we did jQuery before... :) but I love CSS and quite hesitant on Tailwindi, what's your 5cents on Tw?
Tailwind is like angular. Proprietary language convention for oo css. Sure learn it if the company you work for uses it, but in practice its not efficient or performant, requires compiling just to see it working, when you could just write actual css in the browser and get immediate feedback, and copy paste it between mediums when whether its straight from the browser debug window to static html page boilerplate example to a nodejs templating library, reactjs css. module, angular, native web component etc. I even gave up scss to plain old css for agile manouverability. Its just much faster testing against browsers. Use css like a paintbrush or a heavy tank.
Thank you for posting! Number 4 is one that stuck out to me - I'll be more cognizant of the image file types I bring into my app. I also didn't know about the element at all! That's pretty neat.
In the screen width section you use max-width, while a good practice is starting with mobile and use min-width to add complexity. In browsers section you prefix flebox for IE 10 and safari 6, which are 13 years old now. Why? And you still use webp in image section without fallback, but webp is fully supported since safari 16 and is not supported by IE. Details and summary is not supported by IE either. Your points are both outdated and inconsistent.
This is a great breakdown of common frontend mistakes! Issues like inefficient state management, poor performance optimization, and accessibility oversights can seriously impact user experience. Debugging and following best practices are key to avoiding these pitfalls.
Which of these mistakes do you think is the hardest to avoid? Also, managing development workflows efficiently can save a lot of time—structured project management can help keep things on track!
Thank you for sharing, I also covered some common mistakes developers make especially related to CORS
dev.to/reynaldi/7-common-mistakes-...
Good information
Great insights 👍
Good points and good information
Some comments may only be visible to logged-in visitors. Sign in to view all comments.