Use semantic markup

Where possible, always try to use native browser elements for your web content. Reaching straight for widgets and plugins will lead to an increased bundle size and possibly an Excessive DOM. This will mean your browser has to work harder on queries whilst also increasing the amount of data you are sending over the wire - both of which contribute to an increased energy usage and battery drain.

Semantic Markup

Today, the web platform provides a wide range of HTML elements for you to use when creating content for the web. Having a healthy working knowledge of these tags is undeniably useful, but even the most experienced web developers can still encounter tags and features that they've never used before or didn't know existed.

Did you know, for example, that there is a date input that is natively supported accross all major browsers? And that it can be styled to suit your application?

<label for="my-date">Pick a Date:</label>
<input type="date" id="my-date" name="my-date" value="2021-09-30" />

Whilst using semantic markup does not always mean you are safe from an accessibility perspective, using semantic markup will normally get you most if not all of the way towards being inclusive and is strongly encouraged. Any shortcomings in screen reader browser support are likely to become better over time, meaning that using semantic markup is also an effective way of future-proofing your site.

Widgets, Components and Plugins

If you do reach a point where you have exhausted all native browser options, you may find that it's time to reach out to the open source community to find an appropriate plugin/component. Javascript has a huge ecosystem and there is a lot of choice - here are some things to look out for;

  • Evaluate the popular ones first. It's not all about github stars and npm downloads, but as a general rule the components with the most stars/downloads are normally the better ones, so start with those but don't just default to them.
  • Check that the component you choose is accessible - they will normally state this in their documentation.
  • Don't use a sledgehammer to crack a nut - if a plugin provides 100 features and you only need one of them, you are probably going to be downloading (and serving to your users) a lot more code than they are actually using, contributing negatively to your page weight.
  • Just because a component looks good doesn't mean it is good. Take a look at the markup the component generates before making a decision. Are there problems that could be fixed? Would this component be perfect if it just had one more feature? Consider getting involved with that component's development and submimtting a pull request to the creator. Just because a component doesn't do quite what you want it to does not mean that you need to always choose second best.

There is an online convention known as awesome lists which you can use to browse your options. If you find (or create) a great component that is not on one of these lists, consider submitting a change request to get it added.