Javascript on Osmar Petry

JavaScript Modules and Bundlers

Mon, 23 Mar 2026 00:00:00 +0000

The goal here is to understand JavaScript module systems (IIFE, CommonJS, ESModules), how modern bundlers sit on top of them, and which build types to use for business apps and component libraries.

Module systems describe how code is organized and imported/exported at the language level. Bundlers and build tools consume those modules and produce optimized outputs for different environments (browser, Node, CDN, etc.).

Part 1 — Module Systems

IIFE (Immediately Invoked Function Expression)

IIFEs are the classic pattern to create a private scope and avoid polluting window, often combined with a single global namespace like App.

Web Accessibility V3 — Topics cheat-sheet & decision guide

Mon, 01 Sep 2025 00:00:00 +0000

Summary

Course map covers Screen Readers, Accessible HTML, ARIA, Focus Management, and Visual Considerations, plus Debugging & team process.
Aim: ship perceivable, operable, understandable, robust experiences (POUR) with practical exercises and team-ready debugging habits.

Topics → what to do (at a glance)

Screen Readers: learn how they work, enable them, write solid alt text, and test.
Accessible HTML: prefer semantic elements and set document language; fix invalid markup.
ARIA: add only when semantics aren’t enough; know roles, states, properties, names/descriptions, and live regions.
Focus Management: full keyboard support, skip links, logical Tab order, avoid focus traps, and review shortcuts.
Visual: check color contrast, reflow/zoom, reduced motion, and prefers-color-scheme; connect performance with accessibility.
Debugging: use linters/devtools, improve team workflows, go beyond compliance, and practice with hands-on exercises.

Decision heuristics

Semantics first → ARIA last. If a native element already communicates role/state, don’t add ARIA.
Keyboard is the truth. If it’s not operable with keyboard and visible focus, it’s not accessible.
Name, role, value: can a screen reader expose them correctly? If not, fix semantics, labels, or ARIA.
Respect user prefs: prefers-reduced-motion, prefers-color-scheme, and zoom/reflow without loss.

Team workflow

Set standards (WCAG targets, browser/AT matrix).
Lint & test early (HTML validity, axe, devtools).
Exercise mindset: practice with screen readers and keyboard on real UI (modals, forms, navigation).
Go beyond checklists: optimize usability for assistive technology users, not just box-ticking.

Dev checklist

Landmark structure (header, nav, main, aside, footer).
Page language (<html lang>).
Forms: <label> + programmatic names; error text announced.
Interactive controls are native or fully re-created (role, keyboard, focus, ARIA).
Focus order and visible focus style.
Contrast meets WCAG; no information by color alone.
Motion: provide a reduced motion path; avoid parallax autoplay by default.
Respect zoom/reflow at 200–400% without horizontal scroll.

References

Web Accessibility — All Topics (Frontend Masters companion site): https://web-accessibility-v3.vercel.app/topics
GitHub repo: https://github.com/marcysutton/frontend-masters-web-accessibility-v3

[[react-forwardRef|Forwarding Ref]]
[[svg-are-the-best|SVG are the Best]]

XState — model UI behavior correctly and make it testable

Sat, 12 Jul 2025 00:00:00 +0000

The problem we’re solving

Imagine you join a company that runs an e-commerce platform. Product asks you to build a search page — the kind of page every user hits dozens of times a day. It sounds simple: a text input, a button, show results.

But then reality kicks in. The page has to handle empty queries, network failures, slow connections, retries, and race conditions where a user submits a second search before the first one finishes. A junior developer might reach for a handful of useState calls — isLoading, hasError, data, submitted — and suddenly you’re juggling four booleans that produce sixteen possible combinations. Most of those combinations are impossible, but nothing in the code prevents them. A loading spinner stays visible after an error. A success message flashes before the data arrives. Bugs creep in not because the developer made a logic error, but because the model itself was never defined.

Teach Yourself Programming in Ten Years

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Peter Norvig critiques promises of learning programming in weeks. Drawing on research in chess, music, and sports, he argues true mastery requires about ten years of deliberate practice—progressive challenges, feedback, and continual improvement. There are no shortcuts: success comes from sustained effort and critical self-analysis.

Key points

Questions the abundance of “Learn X in 24 Hours/21 Days” books.
Excellence in any complex field typically demands ~10 years of deliberate practice (citing K. Anders Ericsson’s work).
Historical examples (Mozart, Beatles) show their peak came only after years of intense practice.
No magical formulas; commitment to long-term learning is essential.
Practical advice: explore multiple languages, seek challenges, learn from peers, blend theory with real projects.
Books alone are insufficient; hands-on experience is irreplaceable.

Connections

Ties to deliberate practice theory and Malcolm Gladwell’s “10,000 hours” popularisation.
Informs discussions on computing education and depth vs superficial knowledge.
Supports lifelong learning and career development perspectives in tech.

Questions

How to balance theory and deliberate practice?
Does the “ten-year” model apply uniformly across computing domains?
How to maintain motivation through multi-year learning journeys?
Which strategies accelerate progress without sacrificing depth?

Personal reflections

Reinforces patience and persistence when building programming expertise.
Relevant to today’s culture of immediacy—reminds us depth takes time.
Agrees that combining study, deliberate practice, and real projects yields steady growth.
Encourages valuing the learning process rather than chasing quick wins.

Detailed notes

Abundance of quick-learning resources doesn’t reflect real mastery requirements.
Deliberate practice: constant challenge, error analysis, improvement.
Role of mentors, community, and diverse language exposure.
Suggested languages: Python, Scheme, JavaScript, Alice, Squeak, Blockly (depending on learner profile).
“Ten years” is illustrative; the key is sustained, deliberate work.
Original essay: https://norvig.com/21-days.html

JavaScript Sets, Maps, and Hashing

Sun, 09 Feb 2025 00:00:00 +0000

TL;DR

Notes captured on 2025-02-09 during Deveficiente algorithms study.
Set = unique values with O(1) add/remove; Map = key-value store with O(1) lookups.
Hashing is reference-based for objects; custom equality needs manual hashing/serialization.
Useful for caching and deduplication; V8 resolves collisions with internal linked lists/trees.
C# exposes GetHashCode; in JS you must implement equivalent behaviour explicitly.

Sets

Store unique values; duplicates are ignored.
Backed by hash tables in engines like V8.
Typical operations (add, delete, has) run in O(1) on average.

const set = new Set();
set.add("value1");
set.add("value2");
console.log(set.has("value1")); // true
console.log(set.size); // 2

Maps

Store key-value pairs; keys can be any data type.
Also implemented with hashing for O(1) lookups.

const map = new Map();
const key = { id: 1 };
map.set(key, "object");
console.log(map.get(key)); // 'object'

Hashing behaviour

Objects/arrays are compared by reference. Two objects with identical structure are not equal unless they share the same reference.
For custom hash keys (similar to C# GetHashCode), stringify values or build hashing utilities.

function hashObject(obj) {
 return JSON.stringify(obj);
}
const cache = new Map();
const obj = { id: 1, name: "test" };
cache.set(hashObject(obj), "cached");

Cache patterns

const cache = new Map();

function getData(key) {
 if (cache.has(key)) {
 return cache.get(key);
 }
 const value = fetchFromSource(key);
 cache.set(key, value);
 return value;
}

Internal details (V8)

Hash collisions handled via linked lists or adaptive structures (e.g., small arrays, balanced trees).
Sparse arrays may convert to hash tables internally for memory efficiency.

Set vs Map recap

Set: unique values.
Map: key-value pairs, versatile for caching, memoization.

References

MDN: Set, Map.
V8 blog on hash tables and inline caching.

[[javascript-closures-and-curries|Closures and Curries]]
[[react-forwardRef|Forwarding Ref]]

Closures and Curries

Wed, 15 Jan 2025 00:00:00 +0000

Closures and currying are both important concepts in JavaScript, especially for functional programming.

Closure

A closure is a function that has access to its outer scope even after the outer function has returned. It “closes over” its outer scope, hence the name. Here’s an example:

function outerFunction(x) {
 return function innerFunction(y) {
 return x + y;
 };
}
const add5 = outerFunction(5);
console.log(add5(3)); // 8

In the above example, **innerFunction** has access to **x** even after **outerFunction** has returned. This allows us to keep state across multiple invocations of the inner function. We can use closures to store a function with a first parameter, you can see an example here:

Prototype

Wed, 15 Jan 2025 00:00:00 +0000

Every object in JavaScript has an internal link to another object called its prototype. When you access a property that doesn’t exist on an object, the engine walks up this chain — prototype by prototype — until it finds the property or reaches null. This is the prototype chain, and it is the mechanism behind all inheritance in JavaScript.

Understanding prototypes is essential because class syntax in ES6 is just syntactic sugar over this system. Under the hood, extends sets up the same prototype chain. Knowing the raw model helps debug unexpected property lookups, instanceof checks, and performance issues around deep prototype chains.

React ForwardRef

Wed, 15 Jan 2025 00:00:00 +0000

By default, React does not let a parent component access the DOM node of a child component. forwardRef breaks that boundary explicitly — the child opts in to exposing its DOM node (or instance) to whoever holds the ref.

The typical need is imperative control from a parent: focusing an input inside a design-system <Input> wrapper, scrolling a <List> to a specific row, or triggering animations on a child element. Without forwardRef, the parent would need to own the DOM directly, which defeats the purpose of encapsulation.

This Object Inside Call, Apply and Bind

Wed, 15 Jan 2025 00:00:00 +0000

JavaScript has four rules that determine what this refers to inside a function: implicit binding, explicit binding (.call, .apply, .bind), new binding, and window binding. Understanding these rules is essential because this behaves differently depending on how and where a function is called — not where it is defined.

At AutoLot, the car dealership platform, the team kept running into bugs where this was undefined or pointed to window instead of the expected object. Once they mapped each scenario to one of the four binding rules, those bugs disappeared.

Testing Concepts Notes

Fri, 15 Jan 2021 00:00:00 +0000

BDD

BDD (Behavior Driven Development) is a method of testing where you use “Given” for the scenario, “When” for the environment of the action, and “Then” for the action.

Imagine AutoLot, a car dealership chain building an online vehicle marketplace. A product manager, a developer, and a QA engineer sit together and write this scenario in plain English:

Given a customer browsing the SUV category
When the customer clicks "Schedule Test Drive" on a 2024 Honda CR-V
Then the test drive request should appear as "pending" in the customer's dashboard

This is BDD in practice — the three roles agree on the expected behavior before any code is written. The npm package jest-cucumber lets you map these Gherkin-style scenarios directly to Jest tests.

Testing Library vs Enzyme

Fri, 15 Jan 2021 00:00:00 +0000

Introduction

Testing Library is built around a simple philosophy: the more your tests resemble the way your software is used, the more confidence they can give you. Its three core principles are: tests only break when your app breaks (not when implementation details change), you interact with your app the same way as your users, and built-in selectors find elements the way users do to help you write inclusive code.

Javascript on Osmar Petry

JavaScript Modules and Bundlers

Part 1 — Module Systems

IIFE (Immediately Invoked Function Expression)

Web Accessibility V3 — Topics cheat-sheet & decision guide

Summary

Topics → what to do (at a glance)

Decision heuristics

Team workflow

Dev checklist

References

Related Notes

XState — model UI behavior correctly and make it testable

The problem we’re solving

Teach Yourself Programming in Ten Years

Abstract

Key points

Connections

Questions

Personal reflections

Detailed notes

JavaScript Sets, Maps, and Hashing

TL;DR

Sets

Maps

Hashing behaviour

Cache patterns

Internal details (V8)

Set vs Map recap

References

Related Notes

Closures and Curries

Closure

Prototype

React ForwardRef

This Object Inside Call, Apply and Bind

Testing Concepts Notes

BDD

Testing Library vs Enzyme

Introduction