DEV Community: Niraj Ratnawat

Why Netflix Doesn’t Trust Auto-Increment IDs: The Untold Power of UUIDs in a Distributed World

Niraj Ratnawat — Mon, 12 May 2025 15:16:07 +0000

At first glance, an ID might seem like the most boring part of your application. It's just a unique identifier, right?

But if you're building systems that scale - across regions, across teams, across microservices - your ID generation strategy can be the silent hero or the hidden landmine. And that’s exactly why companies like Netflix, Twitter, Stripe, and Shopify have ditched traditional auto-incrementing IDs in favor of UUIDs and Snowflake-like systems.

Let’s explore why UUIDs are not just random gibberish, but a critical architectural decision in high-scale systems - and what lessons we can steal from the giants.

The Problem With Auto-Increment IDs

Auto-incrementing integers are deceptively simple and convenient. They work great when:

You have a single database.
You can guarantee a single source of truth.
You're not worried about collisions across systems.

But modern systems don’t live in that world anymore. The problems start to show when:

You scale horizontally (e.g., microservices writing to different DBs).
You have geo-redundant deployments.
You ingest millions of concurrent events (e.g., Netflix's stream logs, Stripe’s transactions, Shopify’s orders).

What breaks?

❌ Collisions and Race Conditions

Multiple databases can't safely share an auto-increment counter without introducing locking or orchestration.

❌ Poor Mergeability

Data from separate systems (say, multiple regions or services) becomes a nightmare to merge.

❌ Predictability

Auto-increment IDs can leak sensitive information:

How many users have signed up
Volume of orders or transactions
Sequence of operations

In fact, I once worked with a system where simply knowing the current user ID could let you enumerate every customer in the database with /users/{id}.

Enter UUIDs: Globally Unique by Design

UUID (Universally Unique Identifier) is a 128-bit number used to uniquely identify information in distributed systems - no central authority needed.

It looks like this:

123e4567-e89b-12d3-a456-426614174000

That randomness is not for show. It’s your ticket to generating globally unique IDs without coordination.

There are different versions of UUIDs - each designed with a specific use-case in mind.

UUID Version	Description	Use Case
v1	Timestamp + MAC address	Time-sortable, but leaks host info
v4	Randomly generated	Most common, but unordered
v5	Hash of namespace and name	Deterministic UUIDs
v7 (new)	Timestamp-first, random suffix	Perfect for databases & logs

Real-World Case Study: How Netflix Handles IDs

Netflix’s backend is a polyglot architecture - microservices, Kafka streams, data lakes, global deployment zones, all generating billions of events per day.

They don’t use UUID v4s directly.

Instead, they use a Snowflake-inspired ID generation system, pioneered by Twitter and now a standard for distributed ID generation.

A typical Netflix ID might be composed of:

41 bits of timestamp (milliseconds since epoch)
10 bits for machine ID
12 bits for sequence (to avoid collision in the same millisecond)

This format:

Keeps IDs unique across all instances.
Makes them time-sortable for logs, metrics, and debugging.
Avoids the database indexing problem that plagues UUID v4.

⚠️ Fun fact: The original Snowflake system could generate 4096 unique IDs per machine per millisecond.

Why They Don’t Use Auto-Increment

Auto-incremented IDs simply don’t work in an architecture with:

Dozens of microservices writing independently
Global regions that can go into active-active mode
Systems that must work even when partially disconnected

Netflix has no central place to "ask for the next ID." Doing so would create latency, single points of failure, and tight coupling.

Instead, every instance can independently generate its own IDs - and they're still guaranteed to be unique and ordered.

UUID v7: The Future Is Timestamped

UUID v7 is gaining popularity because it solves many of the long-standing issues with UUID v4:

Ordered generation = better database index locality
Encodes time = more useful for logs, debugging, analytics
Still decentralized = no coordination needed

If you're designing a new system today, strongly consider UUID v7 or a Snowflake-style ID generator over v4 or auto-increment.

Tip: If you're using PostgreSQL, UUID v7 can outperform v4 for large-scale insert-heavy workloads simply because index bloat is avoided.

Bonus: When UUIDs Go Wrong

Here’s a story from a startup I consulted with:

They used UUID v4s for every table. Three years in, as the database grew, query performance dropped off a cliff. The culprit? Random insertion pattern caused by v4 UUIDs.

Every insert was touching a new part of the index tree, resulting in write amplification and cache inefficiency. They ended up migrating to ULIDs (like v7) to regain performance.

Lesson: Just because a UUID is “unique” doesn’t mean it’s “smart.”

Final Thoughts

IDs are often an afterthought in design - but they shouldn’t be. Netflix, Twitter, and others teach us that at scale, even your identifiers must be thoughtfully engineered.

If you’re building distributed systems, event-driven pipelines, or global-scale SaaS platforms, ditch auto-increment and random v4s. Embrace timestamped, sortable, decentralized IDs.

Your future self (and your infrastructure team) will thank you.

Footnote: Netflix doesn’t publicly publish the full internals of their ID generation, but numerous engineering talks, job postings, and system diagrams confirm that they use a variant of the Snowflake pattern for large-scale event tracking.

Further Reading:

Twitter Snowflake: https://github.com/twitter-archive/snowflake
UUID v7 spec: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-04
Stripe’s custom ID formats: https://stripe.com/blog/idempotency
ULID: https://github.com/ulid/spec

HTML Attributes vs. Properties: Unraveling the Web's DNA

Niraj Ratnawat — Sat, 21 Sep 2024 19:46:26 +0000

In the world of web development, understanding the relationship between HTML attributes and JavaScript properties is crucial. This knowledge forms the foundation of effective DOM manipulation and is essential for creating robust, efficient web applications. In this comprehensive guide, we'll explore the nuances of attributes and properties, their relationship, and best practices for working with them.

Introduction
Attributes: The HTML Building Blocks
Properties: JavaScript's Window to the DOM
Key Differences Between Attributes and Properties
The Attribute-Property Relationship
Reflection: When Attributes and Properties Sync
Special Cases and Gotchas
How Frameworks Handle Attributes and Properties
Performance Considerations
Best Practices
Conclusion

Introduction

At first glance, HTML attributes and DOM properties might seem interchangeable. After all, they both describe characteristics of HTML elements. However, they serve distinct purposes and behave differently in various scenarios. Understanding these differences is key to writing clean, efficient, and bug-free code.

In this guide, we'll delve deep into the world of attributes and properties, exploring their similarities, differences, and the nuanced relationship between them. Whether you're a beginner just starting out or an experienced developer looking to solidify your understanding, this guide will provide you with the knowledge you need to work effectively with HTML and JavaScript.

Attributes: The HTML Building Blocks

Attributes are the fundamental building blocks of HTML elements. They are defined in the HTML markup and provide initial or default values for elements. Attributes are always strings in HTML, regardless of the type of data they represent.

Let's look at some examples to understand attributes better:



<input type="text" value="Hello" id="myInput" required>
<a href="https://example.com" target="_blank" rel="noopener">Link</a>
<img src="image.jpg" alt="A beautiful landscape" width="300" height="200">

In these examples:

The <input> element has attributes type, value, id, and required.
The <a> (anchor) element has attributes href, target, and rel.
The <img> element has attributes src, alt, width, and height.

Each of these attributes serves a specific purpose:

type="text" specifies that this is a text input field.
value="Hello" sets the initial value of the input.
id="myInput" provides a unique identifier for the element.
required is a boolean attribute. Its presence indicates that the input must be filled out.
href="https://example.com" specifies the URL the link points to.
target="_blank" tells the browser to open the link in a new tab or window.
src="image.jpg" specifies the source file for the image.
alt="A beautiful landscape" provides alternative text for the image.

Attributes can be accessed and modified using JavaScript:



let input = document.querySelector('input');
console.log(input.getAttribute('type')); // "text"
input.setAttribute('type', 'password');
console.log(input.getAttribute('type')); // "password"

It's important to note that when you use getAttribute() and setAttribute(), you're always working with string values, even for boolean or numeric attributes.

Properties: JavaScript's Window to the DOM

While attributes define the initial state of an element, properties represent the current state of an element in the DOM (Document Object Model). Properties exist on DOM objects and can be of any JavaScript type - not just strings, but also numbers, booleans, objects, or even functions.

Let's look at some examples:



let input = document.querySelector('input');

console.log(input.type); // "text"
console.log(input.value); // "Hello"
console.log(input.id); // "myInput"
console.log(input.required); // true

let link = document.querySelector('a');

console.log(link.href); // "https://example.com/"
console.log(link.target); // "_blank"

let img = document.querySelector('img');

console.log(img.src); // full URL to image.jpg
console.log(img.alt); // "A beautiful landscape"
console.log(img.width); // 300 (number, not string)
console.log(img.height); // 200 (number, not string)

Notice how properties can have different types:

input.required is a boolean
img.width and img.height are numbers
Most others are strings

Properties allow JavaScript to interact with and manipulate HTML elements dynamically:



let input = document.querySelector('input');

input.type = 'password'; // Changes input type to password
input.value = 'New value'; // Updates the input's value
input.required = false; // Makes the input optional

let img = document.querySelector('img');

img.width = 400; // Resizes the image
img.src = 'new-image.jpg'; // Changes the image source

Properties provide a more natural and type-appropriate way to work with element characteristics in JavaScript.

Key Differences Between Attributes and Properties

Understanding the fundamental differences between attributes and properties is crucial for effective web development. Let's explore these differences in detail:

Before we dive into the more complex aspects, let's outline some fundamental differences between HTML attributes and JavaScript properties:

1. HTML Serialization

One of the most significant differences is how attributes and properties are represented in HTML.

Attributes are always serialized to HTML. This means they appear in the HTML markup and can be seen when you view the page source or inspect an element.

Properties, on the other hand, are not serialized to HTML. They exist only in the DOM and JavaScript, not in the HTML markup.

Let's see an example:



const div = document.createElement('div');
div.setAttribute('foo', 'bar'); // Set an attribute
div.customProp = 'baz'; // Set a property

console.log(div.outerHTML); // Outputs: <div foo="bar"></div>

In this example, the foo attribute is visible in the HTML, but the customProp property is not.

This difference is crucial when you're working with server-side rendering or need to inspect the HTML directly. Only attributes will be visible in these scenarios.

2. Value Types

Another key difference lies in the types of values that attributes and properties can hold.

Attributes are always strings in HTML. Even when they represent other types of data, they're stored and retrieved as strings.

Properties can be any valid JavaScript type - strings, numbers, booleans, objects, or even functions.

Let's look at a more detailed example:



const div = document.createElement('div');

// Setting attributes
div.setAttribute('string-attr', 'hello');
div.setAttribute('number-attr', 42);
div.setAttribute('boolean-attr', true);
div.setAttribute('object-attr', {foo: 'bar'});

// Setting properties
div.stringProp = 'hello';
div.numberProp = 42;
div.booleanProp = true;
div.objectProp = {foo: 'bar'};

// Getting attributes
console.log(typeof div.getAttribute('string-attr')); // 'string'
console.log(typeof div.getAttribute('number-attr')); // 'string'
console.log(typeof div.getAttribute('boolean-attr')); // 'string'
console.log(typeof div.getAttribute('object-attr')); // 'string'

// Getting properties
console.log(typeof div.stringProp); // 'string'
console.log(typeof div.numberProp); // 'number'
console.log(typeof div.booleanProp); // 'boolean'
console.log(typeof div.objectProp); // 'object'

This difference in value types can be particularly important when working with form inputs or when you need to perform calculations or comparisons in JavaScript.

3. Case Sensitivity

The third major difference involves case sensitivity.

Attribute names are case-insensitive in HTML. This means that class, CLASS, and Class all refer to the same attribute.

Property names, following JavaScript conventions, are case-sensitive. This means that element.className and element.classname are two different properties.

Let's see this in action:



<div id="test" DATA-CUSTOM="Hello"></div>

<script>
  const div = document.getElementById('test');

  console.log(div.getAttribute('data-custom')); // "Hello"
  console.log(div.getAttribute('DATA-CUSTOM')); // "Hello"
  console.log(div.getAttribute('Data-Custom')); // "Hello"

  div.customProp = 'foo';
  div.CustomProp = 'bar';

  console.log(div.customProp); // "foo"
  console.log(div.CustomProp); // "bar"
</script>

In this example, we can see that the attribute can be accessed using any case variation, but the properties are distinct based on their case.

It's worth noting that while attribute names are case-insensitive, attribute values are case-sensitive. This means that data-custom="Hello" and data-custom="hello" are treated as different values.

Understanding these key differences is crucial for writing robust JavaScript code, especially when working with DOM manipulation or form handling. In the next sections, we'll explore how these differences play out in various scenarios and how to handle them effectively.

The Attribute-Property Relationship

The relationship between attributes and properties is not always straightforward. While many attributes have corresponding properties, this correspondence is not always one-to-one, and the behavior can vary depending on the specific attribute and element type.

Let's explore this relationship in more detail:

1. Attributes with Corresponding Properties

Many HTML attributes have corresponding DOM properties. In many cases, these properties reflect the values of their corresponding attributes, but not always in the way you might expect.

Example:



<input id="myInput" type="text" value="Hello">

<script>
  const input = document.getElementById('myInput');

  console.log(input.id); // "myInput"
  console.log(input.type); // "text"
  console.log(input.value); // "Hello"
</script>

In this example, the id, type, and value attributes all have corresponding properties with the same names.

2. Properties without Corresponding Attributes

Some properties exist on DOM elements without having a corresponding attribute. These are often computed or derived values.

Example:



<div id="myDiv">Some text</div>

<script>
  const div = document.getElementById('myDiv');

  console.log(div.textContent); // "Some text"
  console.log(div.childElementCount); // 0
  console.log(div.clientWidth); // (depends on the element's rendered width)
</script>

In this case, textContent, childElementCount, and clientWidth are properties that don't have corresponding attributes.

3. Attributes without Corresponding Properties

Conversely, some attributes, especially custom data attributes, don't have corresponding properties (although they can be accessed via the dataset property).

Example:



<div id="myDiv" data-custom="Hello">Some text</div>

<script>
  const div = document.getElementById('myDiv');

  console.log(div.getAttribute('data-custom')); // "Hello"
  console.log(div.dataset.custom); // "Hello"
  console.log(div['data-custom']); // undefined
</script>

4. Different Names for Attributes and Properties

In some cases, the name of an attribute differs from its corresponding property name.

Example:



<label for="myInput" class="label">Input Label</label>

<script>
  const label = document.querySelector('label');

  console.log(label.getAttribute('for')); // "myInput"
  console.log(label.htmlFor); // "myInput"

  console.log(label.getAttribute('class')); // "label"
  console.log(label.className); // "label"
</script>

In this example, the for attribute corresponds to the htmlFor property, and the class attribute corresponds to the className property.

5. Different Types and Values

Even when an attribute has a corresponding property, the types and values might not always match exactly.

Example:



<input id="myCheckbox" type="checkbox" checked>

<script>
  const checkbox = document.getElementById('myCheckbox');

  console.log(checkbox.getAttribute('checked')); // ""
  console.log(checkbox.checked); // true

  checkbox.checked = false;
  console.log(checkbox.getAttribute('checked')); // "" (attribute remains unchanged)
  console.log(checkbox.checked); // false
</script>

In this case, the checked attribute is a boolean attribute (its presence indicates true, its absence indicates false), while the checked property is a true boolean value.

Understanding these nuances in the attribute-property relationship is crucial for effective DOM manipulation. In the next section, we'll explore how this relationship plays out in terms of synchronization between attributes and properties.

Reflection: When Attributes and Properties Sync

Reflection refers to how changes in attributes can affect properties and vice versa. This behavior isn't consistent across all attributes and properties, which can lead to some confusion. Let's explore different reflection scenarios in detail:

1. Full Bi-directional Reflection

Some attributes and properties fully reflect each other. Changes to either will update both. This is the most straightforward case, but it's not as common as you might think.

Example:



let div = document.createElement('div');

// Setting the property
div.id = 'myDiv';
console.log(div.id); // "myDiv"
console.log(div.getAttribute('id')); // "myDiv"

// Setting the attribute
div.setAttribute('id', 'newId');
console.log(div.id); // "newId"
console.log(div.getAttribute('id')); // "newId"

In this example, the id attribute and property fully reflect each other. Whether you change the attribute or the property, both are updated.

2. One-way Reflection

Some properties reflect changes from attributes, but not the other way around. This is more common and can be a source of confusion if you're not aware of it.

Example:



let input = document.createElement('input');

// Setting the property
input.value = 'hello';
console.log(input.value); // "hello"
console.log(input.getAttribute('value')); // null

// Setting the attribute
input.setAttribute('value', 'world');
console.log(input.value); // "world"
console.log(input.getAttribute('value')); // "world"

// Changing the property again
input.value = 'goodbye';
console.log(input.value); // "goodbye"
console.log(input.getAttribute('value')); // "world" (attribute unchanged)

In this case, changes to the value attribute are reflected in the value property, but changes to the value property are not reflected back to the attribute.

3. Complex Reflection

Some attributes and properties have a more complex relationship. The href attribute and property of an anchor (<a>) element is a good example of this.

Example:



<a id="myLink" href="/page">Link</a>

<script>
  let link = document.getElementById('myLink');

  console.log(link.href); // "http://current-domain.com/page" (full URL)
  console.log(link.getAttribute('href')); // "/page" (as written in HTML)

  // Setting the property
  link.href = '/newpage';
  console.log(link.href); // "http://current-domain.com/newpage"
    console.log(link.getAttribute('href')); // "/newpage"

  // Setting the attribute
  link.setAttribute('href', '/anotherpage');
  console.log(link.href); // "http://current-domain.com/anotherpage"
  console.log(link.getAttribute('href')); // "/anotherpage"
</script>

In this example, the href property always returns the full URL, while the attribute contains the value as it's written in the HTML. When you set either the property or the attribute, both are updated, but the property still returns the full URL.

4. No Reflection

In some cases, there's no reflection at all between an attribute and a property, even if they share the same name.

Example:



<input id="myInput" value="Initial Value">

<script>
  let input = document.getElementById('myInput');

  console.log(input.value); // "Initial Value"
  console.log(input.getAttribute('value')); // "Initial Value"

  // Change the property
  input.value = 'New Value';
  console.log(input.value); // "New Value"
  console.log(input.getAttribute('value')); // "Initial Value" (unchanged)

  // Change the attribute
  input.setAttribute('value', 'Another Value');
  console.log(input.value); // "New Value" (unchanged)
  console.log(input.getAttribute('value')); // "Another Value"
</script>

In this case, after the initial render, the value property and attribute operate independently. Changes to one do not affect the other.

Understanding these reflection patterns is crucial for effective DOM manipulation and can help you avoid unexpected behavior in your web applications.

Special Cases and Gotchas

When working with HTML attributes and DOM properties, there are several special cases and potential pitfalls to be aware of. Let's explore these in detail:

1. Boolean Attributes

Boolean attributes (like disabled, checked, required) have special behavior. Their presence indicates true, while their absence indicates false.

Example:



<input id="myCheckbox" type="checkbox" checked>

<script>
  let checkbox = document.getElementById('myCheckbox');

  console.log(checkbox.checked); // true
  console.log(checkbox.getAttribute('checked')); // "" (empty string)

  checkbox.checked = false;
  console.log(checkbox.checked); // false
  console.log(checkbox.getAttribute('checked')); // "" (attribute still present!)

  checkbox.removeAttribute('checked');
  console.log(checkbox.checked); // false
  console.log(checkbox.getAttribute('checked')); // null

  checkbox.setAttribute('checked', 'false'); // The value doesn't matter
  console.log(checkbox.checked); // true
  console.log(checkbox.getAttribute('checked')); // "false"
</script>

As you can see, the behavior of boolean attributes can be counterintuitive. The presence of the attribute, regardless of its value, makes the property true.

2. The `value` Attribute and Property

The value attribute and property behave differently depending on the type of form control. For text inputs, the property reflects the current text content, while the attribute reflects the initial value.

Example:



<input id="myInput" type="text" value="Initial">

<script>
  let input = document.getElementById('myInput');

  console.log(input.value); // "Initial"
  console.log(input.getAttribute('value')); // "Initial"

  input.value = 'Changed';
  console.log(input.value); // "Changed"
  console.log(input.getAttribute('value')); // "Initial"

  input.setAttribute('value', 'New');
  console.log(input.value); // "New"
  console.log(input.getAttribute('value')); // "New"

  // User types "User Input" into the field
  console.log(input.value); // "User Input"
  console.log(input.getAttribute('value')); // "New"
</script>

For <input> elements, there's also a defaultValue property that reflects the value attribute:



console.log(input.defaultValue); // "New"
input.defaultValue = 'Default';
console.log(input.getAttribute('value')); // "Default"

3. The `class` Attribute and `className` Property

While class is used as an attribute in HTML, the corresponding property in JavaScript is className. However, modern browsers also support a classList property for easier class manipulation.

Example:



<div id="myDiv" class="foo bar">Hello</div>

<script>
  let div = document.getElementById('myDiv');

  console.log(div.className); // "foo bar"
  console.log(div.getAttribute('class')); // "foo bar"

  div.className += ' baz';
  console.log(div.className); // "foo bar baz"
  console.log(div.getAttribute('class')); // "foo bar baz"

  // Using classList
  div.classList.add('qux');
  console.log(div.className); // "foo bar baz qux"
  console.log(div.classList.contains('bar')); // true
  div.classList.remove('foo');
  console.log(div.className); // "bar baz qux"
</script>

4. Style Attribute and Property

The style attribute contains a CSS string, while the style property is an object with individual style properties.

Example:



<div id="myDiv" style="color: red; background-color: yellow;">Hello</div>

<script>
  let div = document.getElementById('myDiv');

  console.log(div.getAttribute('style')); // "color: red; background-color: yellow;"
  console.log(div.style.color); // "red"
  console.log(div.style.backgroundColor); // "yellow"

  div.style.fontSize = '20px';
  console.log(div.getAttribute('style')); // "color: red; background-color: yellow; font-size: 20px;"

  div.setAttribute('style', 'border: 1px solid black;');
  console.log(div.style.color); // ""
  console.log(div.style.border); // "1px solid black"
</script>

5. The `data-*` Attributes

Custom data-* attributes have special behavior. They can be accessed via the dataset property, which converts attribute names to camelCase.

Example:



<div id="myDiv" data-user-id="123" data-user-name="John">Hello</div>

<script>
  let div = document.getElementById('myDiv');

  console.log(div.dataset.userId); // "123"
  console.log(div.dataset.userName); // "John"

  div.dataset.userAge = '30';
  console.log(div.getAttribute('data-user-age')); // "30"

  div.setAttribute('data-user-location', 'New York');
  console.log(div.dataset.userLocation); // "New York"
</script>

6. The `for` Attribute and `htmlFor` Property

For <label> elements, the for attribute is accessed via the htmlFor property in JavaScript.

Example:



<label id="myLabel" for="myInput">Name:</label>
<input id="myInput" type="text">

<script>
  let label = document.getElementById('myLabel');

  console.log(label.getAttribute('for')); // "myInput"
  console.log(label.htmlFor); // "myInput"

  label.htmlFor = 'newInput';
  console.log(label.getAttribute('for')); // "newInput"
</script>

Understanding these special cases and gotchas will help you write more robust and predictable code when working with HTML attributes and DOM properties.

How Frameworks Handle Attributes and Properties

Different JavaScript frameworks and libraries have their own approaches to handling the distinction between attributes and properties. Let's explore how some popular frameworks deal with this:

1. React

React generally favors properties over attributes, but it has a specific system for handling the distinction:

For built-in HTML elements, React uses a predefined list to determine whether to set an attribute or a property.
For custom elements (including Web Components), React sets attributes by default.
React uses camelCase for property names, even for attributes (e.g., className instead of class).

Example:



function MyComponent() {
  return (
    <div>
      <input type="text" value="Hello" readOnly={true} />
      <label htmlFor="myInput">Label</label>
      <custom-element customProp="value" />
    </div>
  );
}

In this example:

type and value are set as properties on the <input>.
readOnly is set as the property readOnly (not the attribute readonly).
htmlFor is used instead of for on the <label>.
customProp on the custom element is set as an attribute.

2. Vue.js

Vue.js uses a mix of heuristics and special bindings to handle attributes and properties:

Vue attempts to automatically choose between setting an attribute or a property based on the element type.
You can force attribute binding with v-bind:attr.prop or :attr.prop.
For boolean attributes, Vue removes the attribute when the value is falsy.

Example:



<template>
  <div>
    <input type="text" :value="message" :disabled="isDisabled">
    <custom-element :custom-prop.prop="propValue" :custom-attr.attr="attrValue" />
  </div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello',
      isDisabled: false,
      propValue: { foo: 'bar' },
      attrValue: 'value'
    }
  }
}
</script>

In this example:

value and disabled on the <input> are likely set as properties.
custom-prop on the custom element is forced to be set as a property.
custom-attr on the custom element is forced to be set as an attribute.

3. Angular

Angular uses a specific syntax to distinguish between attribute and property bindings:

[property]="value" for property binding.
[attr.attribute]="value" for attribute binding.
By default, Angular assumes you want property binding.

Example:



<input [value]="message" [attr.aria-label]="inputLabel">
<custom-element [propertyName]="propValue" [attr.attribute-name]="attrValue"></custom-element>

In this example:

value on the <input> is set as a property.
aria-label on the <input> is set as an attribute.
propertyName on the custom element is set as a property.
attribute-name on the custom element is set as an attribute.

Understanding how different frameworks handle attributes and properties can help you write more effective and predictable code, especially when working across different frameworks or with native Web Components.

Performance Considerations

When working with attributes and properties, performance can be a significant factor, especially in applications that involve frequent DOM manipulation. Here are some key performance considerations:

1. Reading and Writing Speed

In general, accessing and modifying properties is faster than working with attributes. This is because properties are direct JavaScript object properties, while attribute access involves parsing strings and interacting with the DOM.

Example:



const element = document.getElementById('myElement');

// Property access (faster)
element.className = 'new-class';
let classes = element.className;

// Attribute access (slower)
element.setAttribute('class', 'new-class');
classes = element.getAttribute('class');

For performance-critical operations, especially those in tight loops, prefer property access over attribute manipulation when possible.

2. Batch DOM Updates

When you need to make multiple changes to the DOM, it's more efficient to batch these changes together. This reduces the number of reflows and repaints the browser needs to perform.

Example:



// Less efficient (multiple reflows)
element.className = 'foo';
element.style.color = 'red';
element.textContent = 'Hello';

// More efficient (single reflow)
element.className = 'foo';
element.style.cssText = 'color: red;';
element.textContent = 'Hello';

For even more complex manipulations, consider using DocumentFragment or updating elements while they're detached from the DOM.

3. Use Modern APIs

Modern DOM APIs often provide better performance than older alternatives. For example, classList is generally faster and more convenient than manipulating the className string directly.

Example:



// Less efficient
if (element.className.indexOf('active') === -1) {
  element.className += ' active';
}

// More efficient
element.classList.add('active');

Similarly, dataset provides a more efficient way to work with data attributes compared to getAttribute and setAttribute.

4. Avoid Unnecessary Attribute Reads

Reading an attribute value causes the browser to serialize the current value to a string, which can be costly, especially for properties that aren't string-based (like style or dataset).



// Less efficient
const styles = element.getAttribute('style');
const newStyles = styles + 'color: red;';
element.setAttribute('style', newStyles);

// More efficient
element.style.color = 'red';

5. Use Appropriate Storage

For storing custom data on elements, dataset properties are generally more performant than custom attributes:



// Less efficient
element.setAttribute('data-user-id', '123');
const userId = element.getAttribute('data-user-id');

// More efficient
element.dataset.userId = '123';
const userId = element.dataset.userId;

6. Minimize DOM Access

Each time you access the DOM, it can potentially cause a reflow. If you need to access a property multiple times, consider caching it in a variable:



// Less efficient
for (let i = 0; i < 1000; i++) {
    element.style.left = i + 'px';
}

// More efficient
const style = element.style;
for (let i = 0; i < 1000; i++) {
    style.left = i + 'px';
}

7. Consider Using Virtual DOM

For applications with complex and frequent DOM updates, consider using a framework that implements a virtual DOM (like React). Virtual DOM can batch and optimize DOM updates, potentially leading to significant performance improvements.

Best Practices

Based on our exploration of attributes and properties, here are some best practices to follow:

Use Properties for DOM Manipulation: When working with standard HTML elements in JavaScript, prefer using properties over attributes for better performance and type-appropriate values.



   // Prefer this
   element.value = 'New Value';

   // Over this
   element.setAttribute('value', 'New Value');

Use Attributes for Custom Data: For storing custom data, especially on custom elements, use data attributes.



   <div id="user" data-user-id="123" data-user-name="John Doe"></div>



   const user = document.getElementById('user');
   console.log(user.dataset.userId); // "123"

Use Appropriate Property Names: Remember that some attributes have different corresponding property names. Use the correct JavaScript property names.



   // Correct
   element.className = 'my-class';
   label.htmlFor = 'my-input';

   // Incorrect
   element.class = 'my-class';
   label.for = 'my-input';

Be Cautious with Boolean Attributes: Remember that the presence of a boolean attribute implies true, regardless of its value. Use properties to get or set boolean values.



   // Check if checkbox is checked
   const isChecked = checkbox.checked;

   // Set checkbox to checked
   checkbox.checked = true;

Use Modern APIs: Leverage modern APIs like classList and dataset for more efficient and cleaner code.



   // Add a class
   element.classList.add('active');

   // Set a data attribute
   element.dataset.status = 'complete';

Be Aware of Framework Differences: If you're working with a framework, be aware of how it handles attributes and properties. Use the framework's recommended syntax for bindings.
Consider Performance: For performance-critical operations, prefer property access over attribute manipulation, and batch DOM updates when possible.
Use Appropriate Types: Remember that attributes are always strings, while properties can be of any type. Use properties when you need to work with non-string values.



   // Prefer this
   element.disabled = false;

   // Over this
   element.setAttribute('disabled', 'false'); // This would actually enable the element!

Be Careful with Reflection: Be aware that not all attributes and properties reflect each other. Test your code to ensure it behaves as expected.

Conclusion

Understanding the distinction between HTML attributes and JavaScript properties is crucial for effective web development. While they often seem to represent the same information, their behavior can differ in important ways:

Attributes are defined in HTML markup and are always strings.
Properties are defined on DOM objects and can be of any type.
Some attributes and properties reflect each other, while others don't.
There are special cases and exceptions, particularly for boolean attributes and certain property names.

By following the best practices outlined in this guide and being aware of the performance implications, you can write more efficient, predictable, and maintainable code. Remember that different frameworks may handle attributes and properties differently, so always consult your framework's documentation when in doubt.

As web technologies continue to evolve, the relationship between attributes and properties may change. Stay informed about new web standards and browser implementations to ensure your code remains up-to-date and efficient.

Mastering the nuances of attributes and properties will make you a more effective web developer, enabling you to create robust and performant web applications.

Understanding Decorators in TypeScript: A First-Principles Approach

Niraj Ratnawat — Fri, 20 Sep 2024 14:46:36 +0000

Decorators in TypeScript provide a powerful mechanism for modifying the behavior of classes, methods, properties, and parameters. While they may seem like a modern convenience, decorators are rooted in the well-established decorator pattern found in object-oriented programming. By abstracting common functionality like logging, validation, or access control, decorators allow developers to write cleaner, more maintainable code.

In this article, we will explore decorators from first principles, break down their core functionality, and implement them from scratch. Along the way, we'll look at some real-world applications that showcase the utility of decorators in everyday TypeScript development.

What is a Decorator?

In TypeScript, a decorator is simply a function that can be attached to a class, method, property, or parameter. This function is executed at design time, giving you the ability to alter the behavior or structure of code before it runs. Decorators enable meta-programming, allowing us to add additional functionality without modifying the original logic.

Let's start with a simple example of a method decorator that logs when a method is called:



function log(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  const originalMethod = descriptor.value;

  descriptor.value = function (...args: any[]) {
    console.log(`Calling ${propertyKey} with arguments: ${args}`);
    return originalMethod.apply(this, args);
  };

  return descriptor;
}

class Example {
  @log
  greet(name: string) {
    return `Hello, ${name}`;
  }
}

const example = new Example();
example.greet('John');

Here, the log decorator wraps the greet method, logging its invocation and parameters before executing it. This pattern is useful for separating cross-cutting concerns like logging from the core logic.

How Decorators Work

Decorators in TypeScript are functions that take in metadata related to the item they are decorating. Based on this metadata (like class prototypes, method names, or property descriptors), decorators can modify behavior or even replace the decorated object.

Types of Decorators

Decorators can be applied to various targets, each with different purposes:

Class Decorators : A function that receives the constructor of the class.



function classDecorator(constructor: Function) {
  // Modify or extend the class constructor or prototype
}

Method Decorators : A function that receives the target object, the method name, and the method’s descriptor.



function methodDecorator(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  // Modify the method's descriptor
}

Property Decorators : A function that receives the target object and the property name.



function propertyDecorator(target: any, propertyKey: string) {
  // Modify the behavior of the property
}

Parameter Decorators : A function that receives the target, the method name, and the index of the parameter.



function parameterDecorator(target: any, propertyKey: string, parameterIndex: number) {
  // Modify or inspect the method's parameter
}

Passing Arguments to Decorators

One of the most powerful features of decorators is their ability to take arguments, allowing you to customize their behavior. For example, let’s create a method decorator that logs method calls conditionally based on an argument.



function logConditionally(shouldLog: boolean) {
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    const originalMethod = descriptor.value;

    descriptor.value = function (...args: any[]) {
      if (shouldLog) {
        console.log(`Calling ${propertyKey} with arguments: ${args}`);
      }
      return originalMethod.apply(this, args);
    };

    return descriptor;
  };
}

class Example {
  @logConditionally(true)
  greet(name: string) {
    return `Hello, ${name}`;
  }
}

const example = new Example();
example.greet('TypeScript Developer');

By passing true to the logConditionally decorator, we ensure that the method logs its execution. If we pass false, the logging is skipped. This flexibility is key to making decorators versatile and reusable.

Real-World Applications of Decorators

Decorators have found practical use in many libraries and frameworks. Here are some notable examples that illustrate how decorators streamline complex functionality:

Validation in class-validator: In data-driven applications, validation is crucial. The class-validator package uses decorators to simplify the process of validating fields in TypeScript classes.



import { IsEmail, IsNotEmpty } from 'class-validator';

class User {
  @IsNotEmpty()
  name: string;

  @IsEmail()
  email: string;
}

In this example, the @IsEmail and @IsNotEmpty decorators ensure that the email field is a valid email address and the name field is not empty. These decorators save time by eliminating the need for manual validation logic.

Object-Relational Mapping with TypeORM: Decorators are widely used in ORM frameworks like TypeORM to map TypeScript classes to database tables. This mapping is done declaratively using decorators.



import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @Column()
  email: string;
}

Here, @Entity, @Column, and @PrimaryGeneratedColumn define the structure of the User table. These decorators abstract away the complexity of SQL table creation, making the code more readable and maintainable.

Angular Dependency Injection: In Angular, decorators play a pivotal role in managing services and components. The @Injectable decorator marks a class as a service that can be injected into other components or services.



@Injectable({
  providedIn: 'root',
})
class UserService {
  constructor(private http: HttpClient) {}
}

The @Injectable decorator in this case signals to Angular's dependency injection system that the UserService should be provided globally. This allows for seamless integration of services across the application.

Implementing Your Own Decorators: A Breakdown

Decorators are, at their core, just functions. Let’s break down the process of creating decorators from scratch:

Class Decorator

A class decorator receives the constructor of the class and can be used to modify the class prototype or even replace the constructor.



function AddTimestamp(constructor: Function) {

  constructor.prototype.timestamp = new Date();

}

@AddTimestamp

class MyClass {

  id: number;

  constructor(id: number) {

    this.id = id;

  }

}

const instance = new MyClass(1);

console.log(instance.timestamp);  // Outputs the current timestamp

Method Decorator

A method decorator modifies the method descriptor, allowing you to alter the behavior of the method itself.



function logExecutionTime(target: any, propertyKey: string, descriptor: PropertyDescriptor) {

  const originalMethod = descriptor.value;

descriptor.value = function (...args: any[]) {

    const start = performance.now();

    const result = originalMethod.apply(this, args);

    const end = performance.now();

    console.log(</span><span class="p">${</span><span class="nx">propertyKey</span><span class="p">}</span><span class="s2"> executed in </span><span class="p">${</span><span class="nx">end</span> <span class="o">-</span> <span class="nx">start</span><span class="p">}</span><span class="s2">ms);

    return result;

  };

return descriptor;

}

class Service {

  @logExecutionTime

  execute() {

    // Simulate work

    for (let i = 0; i < 1e6; i++) {}

  }

}

const service = new Service();

service.execute();  // Logs the execution time

Property Decorator

A property decorator allows you to intercept property access and modification, which can be useful for tracking changes.



function trackChanges(target: any, propertyKey: string) {

  let value = target[propertyKey];

const getter = () => value;

  const setter = (newValue: any) => {

    console.log(</span><span class="p">${</span><span class="nx">propertyKey</span><span class="p">}</span><span class="s2"> changed from </span><span class="p">${</span><span class="nx">value</span><span class="p">}</span><span class="s2"> to </span><span class="p">${</span><span class="nx">newValue</span><span class="p">}</span><span class="s2">);

    value = newValue;

  };

Object.defineProperty(target, propertyKey, {

    get: getter,

    set: setter,

  });

}

class Product {

  @trackChanges

  price: number;

constructor(price: number) {

    this.price = price;

  }

}

const product = new Product(100);

product.price = 200;  // Logs the change

Conclusion

Decorators in TypeScript allow you to abstract and reuse functionality in a clean, declarative manner. Whether you're working with validation, ORMs, or dependency injection, decorators help reduce boilerplate and keep your code modular and maintainable. Understanding how they work from first principles makes it easier to leverage their full potential and craft custom solutions tailored to your application.

By taking a deeper look at the structure and real-world applications of decorators, you've now seen how they can simplify complex coding tasks and streamline code across various domains.

DEV Community: Niraj Ratnawat

Why Netflix Doesn’t Trust Auto-Increment IDs: The Untold Power of UUIDs in a Distributed World

The Problem With Auto-Increment IDs

What breaks?

❌ Collisions and Race Conditions

❌ Poor Mergeability

❌ Predictability

Enter UUIDs: Globally Unique by Design

Real-World Case Study: How Netflix Handles IDs

Why They Don’t Use Auto-Increment

UUID v7: The Future Is Timestamped

Bonus: When UUIDs Go Wrong

Final Thoughts

HTML Attributes vs. Properties: Unraveling the Web's DNA

Table of Contents

Introduction

Attributes: The HTML Building Blocks

Properties: JavaScript's Window to the DOM

Key Differences Between Attributes and Properties

1. HTML Serialization

2. Value Types

3. Case Sensitivity

The Attribute-Property Relationship

1. Attributes with Corresponding Properties

2. Properties without Corresponding Attributes

3. Attributes without Corresponding Properties

4. Different Names for Attributes and Properties

5. Different Types and Values

Reflection: When Attributes and Properties Sync

1. Full Bi-directional Reflection

2. One-way Reflection

3. Complex Reflection

4. No Reflection

Special Cases and Gotchas

1. Boolean Attributes

2. The value Attribute and Property

3. The class Attribute and className Property

4. Style Attribute and Property

5. The data-* Attributes

6. The for Attribute and htmlFor Property

How Frameworks Handle Attributes and Properties

1. React

2. Vue.js

3. Angular

Performance Considerations

1. Reading and Writing Speed

2. Batch DOM Updates

3. Use Modern APIs

4. Avoid Unnecessary Attribute Reads

5. Use Appropriate Storage

6. Minimize DOM Access

7. Consider Using Virtual DOM

Best Practices

Conclusion

Further Reading

Understanding Decorators in TypeScript: A First-Principles Approach

What is a Decorator?

How Decorators Work

Types of Decorators

Passing Arguments to Decorators

Real-World Applications of Decorators

Implementing Your Own Decorators: A Breakdown

Class Decorator

Method Decorator

Property Decorator

Conclusion

2. The `value` Attribute and Property

3. The `class` Attribute and `className` Property

5. The `data-*` Attributes

6. The `for` Attribute and `htmlFor` Property