JavaScript is a dynamically typed language, meaning that the type of a value will be determined at runtime and that the type contained by any variable may be liable to change during runtime. This is in contrast to statically-typed languages, which have compile-time warnings related to your usage of types. The implication of this is that, as JavaScript programmers, we need to be much more careful in the way we employ types and how we name our variables.

As we know, when we name things, we are implying a contract. This contract will define how other programmers make use of that thing. This is part of the reason why, in various languages, something called Hungarian notation has been very popular. It involves including type annotations in a name itself, like so:

• Instead of button, we may use elButton or buttonElement
• Instead of age, we may use nAge or ageNumber
• Instead of details, we may use objDetails or detailsObject

Hungarian notation is useful for the following reasons:

• Certainty: It provides more certainty of a name's purpose and contract to the readers of your code
• Consistency: It leads to a more consistent naming approach
• Enforcement: It may lead to better-enforced typing conventions within your code

However, it also has the following disadvantages:

• Runtime changes: If the underlying types are changed by bad code at runtime (for example, if a function mutates nAge into a string), then the name ceases to be useful and may only mislead us.
• Codebase rigidity: It may lead to a rigid code base where it's hard to make appropriate changes to types. Refactoring old code may become more burdensome.
• Lack of meaning: Knowing only a variable's type does not inform us as to its purpose, concept, or contract as much as a truly descriptive non-typed variable name would.

In the landscape of JavaScript, we see Hungarian notation used in a few places: the most common is when naming a variable that may refer to a DOM element. The notations for these names will usually be in the form elHeader, headerEl, headingElement, or even $header. The latter, with a dollar prefix, is most famously used in the jQuery library. Its fame there led to it being a standard in various other places. Chromium DevTools, for example, employs a dollar prefix for element references and methods related to querying the DOM (for example, $$(...) is aliased to document.querySelectorAll(...)).

Hungarian notation is something that can be utilized partially, where you're concerned there may be ambiguity. For example, you can use it where you have both a complex type and a primitive type referring to the same concept within a single scope:

function renderArticle(name) {
  const article = Article.getByName(name);
  const title = article.getTitle();
  const strArticle = article.toString();
  // ...
}

Here, we have an article variable that refers to an instance of the Article class. In addition to this, we also want to use a string representation of our article. To get around a potential naming conflict, we have used an str prefix to indicate that the variable refers to a string value. In isolated cases like these, Hungarian notation can be useful. You don't need to use it exhaustively, but it's a useful tool to have up your sleeve.