DEV Community: doyinAdeyemo

Asynchronous JavaScript: Promises vs. Async/Await in Details

doyinAdeyemo — Tue, 03 Sep 2024 06:11:53 +0000

Asynchronous programming is pivotal in modern web development, particularly in JavaScript. Traditionally, programming languages execute code sequentially from top to bottom. However, this synchronous execution model can lead to inefficiencies, especially when dealing with time-consuming operations such as fetching data from a server, accessing files, or performing complex computations. Asynchronous programming addresses these challenges by allowing certain processes to run independently of the main execution thread, thereby enhancing the responsiveness and performance of web applications.

Inherently single-threaded, JavaScript utilizes asynchronous programming to manage operations that would otherwise block the execution thread until completion. This is achieved through features like callbacks, promises, and async/await syntax, which help handle operations that are inherently uncertain in their completion time. The importance of mastering asynchronous programming in JavaScript cannot be overstated. It enables developers to create smoother, faster, more interactive web experiences. As websites and web applications become increasingly complex and data-driven, handling asynchronous operations effectively is crucial for maintaining performance and providing a seamless user experience.

In essence, asynchronous programming not only optimizes the performance of web applications by preventing the blocking of the main thread but also contributes significantly to the scalability and maintainability of the codebase. As we delve deeper into this subject, we will explore the mechanisms and patterns JavaScript provides to handle asynchronous operations and why they are indispensable in the toolkit of modern web developers.

Understanding Asynchronous Javascript

Imagine placing your order at the counter in a bustling coffee shop. Instead of waiting for your drink to be prepared, you sit and browse through a magazine. Meanwhile, the barista works on your order. Once your coffee is ready, the barista calls you to pick it up. This scenario is similar to how asynchronous operations work in JavaScript.

In JavaScript, asynchronous operations are like sending your order to the kitchen; you don’t have to stand and wait for the cook to finish. You can continue reading your book, chatting with a friend, or enjoying the music in the café. You will be notified once your order is ready, and you can enjoy your meal. Similarly, asynchronous JavaScript allows tasks like API calls or file operations to run in the background. Like you in the café, the main program doesn’t get blocked; it continues to run and respond to other user inputs or actions.

Common Asynchronous Operations in JavaScript

API Calls: These are like ordering food from a delivery service while watching a movie. You don’t pause the movie to wait for the food; you continue watching, and when the doorbell rings, you get your food. In web development, requesting a server for data works the same way. You ask for data and continue interacting with the site, and it's displayed to you once the data arrives.

fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json()) // Convert the response to JSON
  .then(data => console.log(data))    // Log the data
  .catch(error => console.error('Error:', error)); // Handle any errors

File Operations: This is akin to sending documents to print on a printer while you tidy up your desk. You don’t need to stand by the printer waiting for all your documents; you keep doing your other tasks. Similarly, file operations in JavaScript (especially on platforms like Node.js) let you initiate a file read or write operation and then move on to other tasks, receiving a notification when the operation is complete.

const fs = require('fs');

fs.readFile('example.txt', 'utf8', (err, data) => {
  if (err) {
    console.error('Error reading the file:', err);
    return;
  }
  console.log(data); // Log the contents of the file
});

Timers and Delays: Using setTimeout() or setInterval() in JavaScript is like setting an oven timer when baking a cake. You set the timer and leave the oven to do its job while you whip up some frosting. The timer does not halt your other activities; it simply alerts you when to take the next step.

setTimeout(() => {
  console.log('This message appears after 2 seconds!');
}, 2000);

Event Listeners: Imagine setting up a motion sensor in your garden that rings a bell when it detects movement. This is how event listeners work. You set them up to watch for certain events (like clicks or keystrokes), and they run associated functions in response without interfering with other operations of your application.

document.getElementById('myButton').addEventListener('click', () => {
  console.log('Button was clicked!');
});

Promises

Imagine you're at a carnival and just tossed a ring towards a bottle, aiming to hook it. At that moment, three outcomes are possible: the ring lands perfectly (success), misses entirely (failure), or is still spinning in the air (pending). In JavaScript, this scenario is analogous to a Promise. A Promise is an object that represents the eventual completion or failure of an asynchronous operation. It’s like making a bet on whether the ring will land.

Anatomy of a Promise

Pending: The Promise is initially in the "pending" state. It's uncertain, like the ring spinning in the air.

Fulfilled: If the asynchronous operation completes successfully, the Promise is "fulfilled." Think of this as the ring landing on the bottle.

Rejected: If the operation fails or encounters an error, the Promise is "rejected." This is akin to the ring missing the target.

Creating a Promise Instance

Here is how you can create a promise for the above example:

const ringToss = new Promise((resolve, reject) => {
  let hasLanded = Math.random() > 0.5; // Random chance of success
  if (hasLanded) {
    resolve('You won a prize!'); // Fulfill the promise
  } else {
    reject('Try again!'); // Reject the promise
  }
});

console.log(ringToss); // Logs the Promise object showing its state

Working with Promises

Now that you've tossed the ring, you need strategies to handle the outcome, whether a win or a miss.

Methods to Handle Promises

.then(): This method is used when the promise is fulfilled. It’s like claiming your prize at the carnival booth.

.catch(): This handles rejections or errors. It’s the equivalent of deciding what to do after you miss the ring toss.

.finally(): This method is for code that runs regardless of the outcome, similar to walking away from the booth after winning or losing.

Chaining Promises

Chaining promises is like playing several carnival games in a row. You must complete one game to receive a token that lets you play the next.

enterBooth()
  .then(token => playGameOne(token))
  .then(prize => tradeForToken(prize))
  .then(token => playGameTwo(token))
  .then(prize => console.log(`You won: ${prize}`))
  .catch(error => console.error('Game error:', error));

In the example of chaining promises above, each step represents a sequential operation, each dependent on the success of the previous one. Here’s what happens in each step:

enterBooth(): This is likely the initial step where you "enter" the asynchronous operation. Imagine it as signing up or logging into an online service. This function returns a Promise.

.then(token => playGameOne(token)): Once you successfully enter, you receive a token. This token is then used to play the first game. This step is also a Promise, dependent on obtaining the token from enterBooth().

.then(prize => tradeForToken(prize)): If you win the first game, you receive a prize. This prize must be traded for another token to continue to the next game. This trading action is another asynchronous operation that returns a Promise.

.then(token => playGameTwo(token)): With the new token, you can play the second game. Again, this step is only possible if the previous step of trading the prize for a token is successful.

.then(prize => console.log(You won: ${prize})): If the second game is won, you will receive another prize. This prize is logged to the console, indicating the successful end of this promise chain.

You might be wondering when the .catch block comes into play. The .catch() block is invoked if any of the Promises in the chain fail or are rejected. This could happen if:

*You failed to enter the booth (enterBooth() fails).
*Any game along the way (playGameOne() or playGameTwo()) does not result in a prize.
*The prize cannot be traded for a token.

In any of these scenarios, the .catch() block catches the error, logs it or takes other corrective action. This prevents the error from stopping the entire script and allows for graceful error handling.

Final Words

Choosing between Promises and Async/Await largely depends on your project's specific needs. Async/Await might be the clearer choice for complex sequences of dependent operations due to its straightforward syntax and ease of error handling. Conversely, when dealing with multiple, simultaneous operations that do not depend on each other, utilizing Promises with techniques like Promise.all can significantly enhance performance. Both tools are essential in a JavaScript developer’s toolkit, empowering you to write more efficient, cleaner code.

Exploring JSR for JavaScript Module Management

doyinAdeyemo — Fri, 17 May 2024 12:25:11 +0000

JavaScript makes building dynamic and engaging websites possible. As web projects grow, managing the many JavaScript files or modules becomes increasingly important. Because they efficiently divide various functions and improve the general structure for simpler handling, these modules are crucial for developers to preserve code organization.

Over the past 15 years, Node has been a formidable presence in the JavaScript realm, and it's impossible to discuss Node's triumphs without acknowledging the equally astounding success of NPM (Node Package Manager). NPM, arguably the most triumphant package registry globally, boasts over 2.5 million packages and a staggering 250 billion downloads in the previous 30 days alone.

While npm remains a cornerstone of web development, the JavaScript community is clamoring for more. The community is already envisioning a new package registry, one that will redefine the landscape in 2024.

It must adopt ESM (ECMAScript Modules) as the JavaScript module web standard.
Its first principles should guide its design for TypeScript, which has quickly established itself as the de facto standard in development.
Simple, quick, and offers a great development experience.
It should be open-source, free, and functional anywhere JavaScript is used. It should expand rather than duplicate NPM's success.

Deno presented the JavaScript Registry (JSR) to pursue these fresh demands. With this new package registry, developers' interaction with JavaScript, TypeScript, and WebAssembly is expected to change completely. As we look into this ground-breaking advancement, let's examine what makes JSR a game-changer in the JavaScript ecosystem.

What is JSR?

JSR is a recently launched open-source JavaScript package registry centered on modern JavaScript and TypeScript. It boasts sophisticated capabilities like publishing TypeScript directly, auto-documentation and types, and smooth Node compatibility.

This robust package repository, with a smooth connection to well-known JavaScript package managers and runtimes (Node.js, Workerd, Deno, browsers, and more), makes finding and using packages for your applications simpler than ever.

JSR is intended especially for TypeScript and ESM (ECMAScript Modules) and builds on the popular package registry NPM. With JSR, you can easily include packages in your projects, regardless of the runtime you choose.

Why JSR?

The constraints in NPM served as the impetus for the creation of JSR. Deno's Kevin Whinnery underlined the need for a central package manager customized to meet particular needs. A decision to build a new package registry was made to address some of NPM's shortcomings, such as package squatting and lax semantic versioning compliance. Here are three main justifications for creating JSR even in the face of other well-known package registries:

1.ECMAScript Modules (ESM) as the new standard
When other package registries, such as NPM, YARN, PNPM, etc., were first released, the web platform was different. The new and potent package registry JSR has replaced CommonJS with ESM as the preferred module format.

2.Flexibility
It's not news that JavaScript runtimes are now available in the development environment outside of browsers and Node.js. The entire JavaScript ecosystem no longer makes sense with a Node.js-centric package registry with the rise of Deno, Bun, and other emerging JavaScript environments. This indicates the requirement for a new, adaptable package registry.

3.TypScript Compatibility
Although many developers consider JavaScript the standard programming language, contemporary applications require more, especially in terms of security. This is where TypeScript excels, hence its current great demand. TypeScript, a statically typed programming language built on top of JavaScript and test bed for the latest ECMAScript features, has emerged as a de facto standard and default choice for non-trivial JavaScript codebases. Hence, JSR was built with TypeScript in mind.

JSR Approach on Module Management

When Node.js first emerged as a popular runtime environment, JavaScript had no standard module structure. Node and the powerful npm package registry defaulted to CommonJS, a system with basic problems that rendered it unusable in browsers. Thus, JavaScript introduced syntax for ES modules (import) almost ten years ago, in 2015, when it underwent its biggest upgrade by switching from ECMAScript5 (ES5) to ECMAScript6 (ES6).

While ES modules are used in most JavaScript nowadays, the distribution of these modules is still complicated, particularly when TypeScript is involved. This obvious void in the ecosystem led to the development of JSR, a revolutionary package registry that completely changed how JavaScript and TypeScript are transferred among browsers, server-side runtimes, and other tools—rather than as another package management tool.

JSR streamlines the complexity that has long afflicted developers, fundamentally improving the code distribution process. As TypeScript-first and ESM-only, JSR eliminates the hassle of juggling package.json setups and the confusing tsconfig compiler settings.

5 Advantages of JSR

1.Fantastic TypeScript Optimization
TypeScript support was considered while creating the JSR. This implies that users and package authors can fully benefit from this native TypeScript support. Package owners can post TypeScript source code, which is utilized to produce extensive online documentation for their package automatically. Conversely, package users who deal with packages from the JSR gain type checking and other TypeScript capabilities.

Package authors don't have to worry about users executing their applications on other platforms like Node.js that don't have native TypeScript support because JSR is so adaptable. JSR will efficiently transpile the source code of package authors to JavaScript and distribute the resulting modules with.d.ts files to enable TypeScript tooling for Node.js applications. The nice thing about it all is that module creators won't need to perform any extra setup or building processes.

2.ECMAScript Module Support
ECMAScript Modules (ESM) is quickly becoming the preferred standard for importing modules for our project. It is not only more sophisticated than the CommonJS way but also has cleaner syntax. On top of that, there are different ways to import modules, which can either be named or default. Each module has a different way developers would like to import it for easier reference as the project grows.

It is soothing to think of JavaScript Registry as being created to be ESM only. By focusing on ESM only, JSR hopes to promote best practices and help developers work better by expediting development. Moving away from the old commonJS way improves performance and compatibility in many ways and simplifies module structure.

Furthermore, it is believed that JSR aims to unite the JavaScript ecosystem, making it easier for developers to create and distribute excellent packages, all through consistent improvement of the package registry to offer more simplification. JSR is actively advocating for a more effective and future-proof standard with JSR, not just keeping pace with the times. This means that the JavaScript ecosystem can only look forward to an even better package registry.

3.Cross-Runtime Support
The old friends of developers, NPM, yarn, and more are known to be Node.js-centric, and one of the advantages JSR offers is to move away from this rigidity and ensure the package modules in its registry offer cross-runtime support, which means they can run on any runtime or development environment. Now, that is some flexibility!
As of the time this article is written, JSR works with Deno and other npm environments that populate the node_modules directory with package modules needed to build a project. This means that Node.js, Bun, Cloudflare Workers, and other projects that manage dependencies with a package.json can interoperate with JSR as well. In the near future, JSR intends to expand its support for bundlers and other runtimes, making the package registry even more formidable.

4.Lightweight and Secure
JSR is incredibly fast and secure. It employs a global Content Delivery Network (CDN) to serve registry packages securely. The download rate experienced from using the package registry is impressively great, thanks to the local caching and high parallelism they leverage. In addition, the package download is efficient, ensuring that only the expected file is downloaded—no extras.

5.Highly Impressive JSR Score
The JSR package registry employed 'JSR score' to automatically rate published packages based on key metrics that indicate package quality and ensure the best user experience. Packages in search results are ranked by the JSR score, which ranges from 0% to 100%. This gives packages a hierarchy and enables users to assess package quality at a glance.

A couple of factors go into calculating the JS score. A well-crafted documentation, which must contain a README file, module documentation, and public functions and types documentation, determines how well a package module is ranked. Also, the degree of discoverability, boosted by using the right keywords, contributes to the JS score. Moreover, a significant part of the evaluation of these programs is compatibility. Publishing authors can indicate at least one runtime as 'compatible' in a section on the package page that JSR has given.

It should be mentioned that even though these rating components are excellent for evaluating the caliber of packages, JSR has ensured that authors are not required to complete them all for their packages to score 100%. This is a little laxity added to ensure that authors and users can utilize the package registry without problems.

JSR vs. NPM

The most important thing to remember when comparing the Node Package Manager (NPM) registry to the JavaScript Registry is that the latter is a registry built on top of the former, the same way TypeScript is considered to be built on top of JavaScript.

Essentially a superset of the npm registry, JSR provides a far safer and more efficient package management solution. Projects and packages did not have as high of a technology requirement as when npm initially started. JSR has been driven by new requirements to concentrate on TypeScript integration and speed optimization, which provide developers with significantly better security and usability.
The much faster and more efficient new JSR is a big benefit for developers. It downloads quickly and only the desired module—no other files. Cutting down on load times and making the best use of available resources surely enhances the whole development experience. For JSR, that's a success.

JSR vs. Yarn

Yarn is a package registry developed by Facebook to mitigate some of the problems noticed with the npm package registry at the time. The intention was to provide more advanced capabilities while also ensuring the registry remains secure, reliable, and efficient. This means that nothing was sacrificed for an improved performance by Yarn.

It has been a serious competition between yarn and npm registry since the inception of the former, whose coming has spurred the npm inventors to add many more features to the registry. Now, yarn is seen as an alternative to NPM rather than a replacement.

But how does Yarn compare to JSR? The fact that JSR is recent gives a sense of a registry brimming with the latest features that a package registry should have. JSR is powerful and flexible, coupled with other features that make the registry recommended.

Yarn version 2 onwards does not use the node_modules folder. Instead, it generates a .pnp. js file that maps the project's dependencies. As a result, project launch and package installation happen faster and with more ideal dependency trees. Yarn’s way of operating shows that the JSR is more similar to the npm registry than it is to Yarn

Conclusion

Though it is still in its infancy, JSR offers a vision of a more secure, effective, and developer-friendly package management system, a daring move ahead in the JavaScript environment. Users have raised a couple of integration problems; some have been fixed, while others are currently being worked out.

JSR addresses a great deal of deno.land/x, npm, pnpm, yarn, and many other registries issues while maintaining all its benefits as a "package-management as code" solution. In addition, the ability to interact with the rest of the Javascript ecosystem solves many actual problems.

It is significant, at the very least, to have a registry that puts TypeScript on par with Javascript. The rest of the Javascript ecosystem has not had easy access to this benefit, which Deno Land has been claiming for years.

As the community investigates and uses JSR, its effects on JavaScript approaches to development and the larger ecosystem will become clear, maybe establishing a new benchmark for software development and package administration.

Semantic HTML: Beginner’s Guide to Semantic Tags and Their Importance to Accessibility and SEO.

doyinAdeyemo — Thu, 28 Mar 2024 13:16:25 +0000

Introduction To Semantic HTML

Far too many beginners become so disturbed at the first introduction to semantic HTML. This topic seems confusing to many, but with the right material, it can be easy to understand and start using immediately.

Semantic HTML doesn’t have a weird meaning other than still using HTML elements with meaningful opening and closing tags. Speaking of meaningful, semantic elements, unlike non-semantic ones, can quickly give even non-developers a hint of what they do. Seeing semantic element tags like aside, header, section and more quickly gives you an idea of what they do on the webpage. Yes, that’s the whole idea of using semantic HTML.

Semantic HTML allows developers to enforce the meaning of information on websites and web applications. Semantic HTML provides healthy alternatives to using div and span, helping search engines better understand the content on webpages and aiding assistive technologies to present content better to users.

Why Should You Even Use Semantic HTML?

When I teach beginners, the same question is always on their lips: Why use it? Is it even mandatory for me to use semantic HTML? After this section, you'll find reasons to be convinced that leveraging semantic HTML gives real power in the development world.

1.Accessibility
The internet is a vast space featuring many users with different tastes and experiences. Some of these users are visually impaired, so they use assistive technologies like screen readers to engage with webpage content. Screen readers read aloud the content of web pages.

As a good developer, you must consider users with visual impairments and provide them with ways to have the best experience on your website or web application. So how do you achieve this? The answer is quite short and simple: semantic HTML.

Semantic HTML ensures your webpage content follows a meaningful structure that makes it easier for the screen reader to understand and read out loud. With non-semantic HTML, users may find it challenging to comprehend and navigate a website or web app if the screen reader just interprets a page as a collection of undifferentiated text.

2.Search Engine Optimization (SEO)
SEO is perhaps one of the key things to keep in mind when launching a website or web application. So, what is SEO? Imagine yourself on a rabbit chase to Google, Bing, and other search engines to research a disturbing coding concept. These search engines take your input/query and present you with the best-related content. This is possible because their algorithm understood the webpage content, thanks to semantic HTML.

Good use of semantic HTML gives your content a good shot at ranking high and better in the search results, as the search engines understand its context and relevance more accurately. Better SEO increases websites' visibility, consequently leading to more traffic.

3.Code Maintainability
A good code is one with a defined structure and clarity. We often write code that others will eventually read, either to improve upon or learn a thing or two from. A codebase with tons of

and and scarce semantic HTML is deficient and mostly difficult to read, understand, and maintain.

The clarity gained from using semantic HTML significantly helps developers reduce the time spent figuring out what different sections of a codebase do. This makes it relatively easy to maintain, update, upgrade, and collaborate with other developers.

Enough of the text; let’s see some actual code!

8 Commonly-Used Semantic HTML

1.header: The header element has opening and closing tags of header. It can be a semantic wrapper for many other elements you want to make an introductory part of a particular section. This element can be found anywhere on the webpage, and the usage and meaning would still not be lost. For instance, it can be found at the topmost part of a website, housing the primary navigation links, as you can see in the diagram below:

2.nav: The nav semantic element has opening and closing tags of nav, which can be interpreted as ‘navigation.’ It is always used to wrap links that can be used to navigate between pages on the same website or navigate to a completely new website. It is commonly used when there is more than one link involved. A perfect use case is shown in the picture below:

3.main: The main element has opening and closing tags of main. This HTML element is the semantic wrapper that embodies all the core content of the webpage, excluding the header, footer, aside, and nav. I often implore newbie developers to follow a popular page layout that features three sections in sequential order: header, main, and footer. This way, you can be sure to be on the safer side of semantic usage.

4.section: The section semantic element in HTML is best used for grouping related content on a webpage. It has opening and closing tags of section. We could liken this element to creating separate chapters in a book, each focusing on a theme.

In the development world, the section element is one of the very few that often comes into use. For instance, if you want to develop a landing page for a client, you could have your page broken into sections. You could have the hero section, about section, services section, how-it-works section, testimonial section, and more. This way, the section element keeps the landing page tidy and organized, making it easier for people and search engines to understand and fully interpret what different parts of your webpage are about.

You must note that the section semantic element makes the most sense when used inside the main. Therefore, the practice of three partitions of header, main, and footer still holds.

5.article: The article semantic element has open and closing tags of article. This element can provide a wrapper for content that stands independently of the rest of the document, such as product details, blog posts, etc.

Newbie developers have struggled to distinguish between the section and article elements. They are different in usage; you must understand this to use them correctly. In the picture below, you’ll notice I used an article inside the section element. This means the former can be a child element of the latter; it is just a wrapper.

6.blockquote: The blockquote semantic element has opening and closing tags of blockquote. This element is used to wrap text content that is an extended quotation. Let’s say you are building a website featuring user feedback. It is best practice to wrap this text feedback inside a blockquote. When the browser sees this semantic element, it indents the text content within, setting it apart from the surrounding text. blockquote has its use in citations, testimonials, etc.

7.figure and figcaption: Finally, the twins of semantic HTML 😂. These two can be likened to how you use WhatsApp to upload media content to your status. You often upload a picture or video and provide a caption for viewers to read to get more details about the uploaded media content.

Now, let us come back to the code. If you want to show a picture on your webpage, instead of wrapping it inside a div element, you can use the semantic figure and then use figcaption to provide a caption or more details about it. It is as simple as that.

8.footer: Ah, finally, the footer element! This semantic element is a container for the bottom-most part of a webpage, section, table, and many more. The content of the footer depends on its location on the webpage. If found in the bottom-most part of the webpage, it mainly contains secondary links, including terms of use, privacy policy, or any other links that cannot fit into the primary navigation in the header element.

Speaking of containing other links, footer is deemed the site map. What does that even mean? From this element, you can navigate to almost every page on the website or web application, thanks to the links it houses.

Does this mean nothing or no other element must come after the footer? Yes! Also, you must use this element correctly and ensure it serves its purpose.

Effective Use of Semantic HTML

Here is an essential section of this article, and that is because just knowing a few semantic elements doesn’t translate to using each of them properly. Therefore, this section will show you some of the best practices when using semantic HTML in practice and tips for beginners. Let us dive right into it.

Best Practices

Use Appropriate Elements: Choosing the semantic element that best suits the content and purpose of what you want to represent is always essential. It just doesn’t make sense when you use nav for content other than navigation links.
Be Consistent: It is best practice to apply semantic elements consistently across your website to preserve a healthy standard, all in the vein of reaping the utmost dividends of using semantic HTML.
Appropriate Nesting: In the pictures up there, there were times I used semantic elements in a nested way, just like having nav inside header and article inside section element. This is a healthy nesting; you must also follow the best practices.
Don’t Overuse: Ah, yes! This is very important. While semantic elements serve an excellent purpose for your website, it is equally important not to go overboard. Not every div or span in your code has to be replaced by semantic elements; no, it just doesn’t work that way. Only use semantic elements where they add meaningful value to the document structure.
Integrate Accessibility Features: I must admit that this is slightly above the beginner level, but you must know of its benefits anyway. Semantic HTML used alongside ARIA (Accessible Rich Internet Applications) holds absolute power, mainly when working on a complex application.

Tips for Beginners

Start with the Page Structure: Before you start adding content to your webpage, consider outlining the basic structure of the page using semantic elements. As we discussed in the previous section, you can divide your page into three parts using semantic elements: header, main, and footer. This way, you have a reasonable starting point. This approach can help you think about the content regarding meaning and purpose. You just have to do it right.
Learn Each Semantic Element: Before you start using, ensure you learn each semantic element well. This will prevent you from having trouble using them. You just need to understand their meanings and purposes, which will ultimately greatly improve the way you structure your content.
Keep SEO in Mind: Remember, SEO is one of the benefits of using semantic HTML. Therefore, keep SEO in mind by using semantic elements to convey the structure and importance of your content.
Practice: They say practice makes perfect. The adage is not lost in this context either. You must practice what you learn; learn and practice more. There is just no better way of saying it. Also, you must regularly review and refine your code to better apply semantic principles.

Final Words

Creating well-thought-out, accessible, and search-engine-friendly websites or web applications hinges on how well you understand and implement semantic HTML, which also extends its importance to enhancing the user experience.

It helps better when you consider semantic HTML to be the backbone of web content, providing meaning and structure. Understanding semantic HTML profoundly should spur you to ensure a more inclusive, efficient, and effective website that conveys the intended message.

You must always remember that the goal is to make the web a better, more accessible place for all. Therefore, embracing the power of semantic HTML to develop robust and user-friendly web pages puts you a step ahead of the competition.