DEV Community: Max Prilutskiy

Hidden Classes: The JavaScript performance secret that changed everything

Max Prilutskiy — Wed, 17 Sep 2025 22:30:31 +0000

Last week, I was profiling a Node.js service at Lingo.dev that was mysteriously slow. Chrome DevTools kept mentioning something called "Hidden Classes" in the performance panel. One accidental click on that term sent me down a rabbit hole that completely transformed how I write JavaScript.

Here's the wild part: by understanding this one concept, you can make your JavaScript code run 10x, 50x, sometimes even 100x faster. No exaggeration. I've been writing JavaScript for years, and discovering Hidden Classes felt like finding out that my car had a turbo button I never knew existed.

By the end of this article, you'll understand exactly how V8 (Chrome's JavaScript engine) optimizes your objects behind the scenes, why seemingly innocent code can destroy performance, and most importantly - how to write JavaScript that runs at near-native speeds. Let's dive into one of JavaScript's best-kept optimization secrets.

What Are Hidden Classes, Really?

Here's the thing that blew my mind: JavaScript doesn't have classes. Not really. When we write class in JavaScript, it's syntactic sugar over prototypes. But V8 creates actual classes internally - Hidden Classes - to make your dynamic JavaScript objects behave like static C++ structs.

Think about it. In C++, when you access struct.field, the compiler knows exactly where that field lives in memory. It's just pointer arithmetic. But JavaScript? We can add properties whenever we want:

const user = {};
user.name = "Alice";        // Just added a property!
user.age = 28;              // Another one!
user.premium = true;        // Why not?
delete user.age;            // Changed my mind!
user["dynamic" + "Prop"] = "chaos"; // Living dangerously!

How does V8 make this dynamic chaos fast? Hidden Classes. Every time you create an object, V8 assigns it a hidden class (internally called a Map) that describes the object's shape - what properties it has and where they're stored in memory.

V8's team explains this brilliantly: Hidden Classes are V8's secret weapon for turning JavaScript's flexibility into C++-like performance.

The Shape-Shifting Magic

This is where it gets interesting. Watch what happens when we create objects:

// Step 1: Empty object gets Hidden Class HC0
const point = {};

// Step 2: Adding 'x' creates Hidden Class HC1
// HC1 says: "I have property 'x' at offset 0"
point.x = 5;

// Step 3: Adding 'y' creates Hidden Class HC2
// HC2 says: "I have 'x' at offset 0, 'y' at offset 1"
point.y = 10;

But here's the genius part - V8 creates a transition chain:

HC0 → (add x) → HC1 → (add y) → HC2

Now when you create another object with the same pattern:

const point2 = {};   // Reuses HC0!
point2.x = 15;       // Follows transition to HC1!
point2.y = 20;       // Follows transition to HC2!

V8 doesn't create new hidden classes. It reuses the existing chain! This is why object creation order matters so much.

I created a visualization to show this in action:

// These objects share the same Hidden Class
const users = [
  {name: "Alice", age: 28, city: "NYC"},
  {name: "Bob",   age: 34, city: "LA"},
  {name: "Carol", age: 29, city: "Chicago"}
];

// But this breaks the pattern - different Hidden Class!
const wrongOrder = {age: 25, name: "Dave", city: "Boston"};

Performance: The Numbers That Matter

I didn't believe the performance impact until I ran benchmarks. Check this out:

// Monomorphic function - processes one shape
function getX(point) {
  return point.x;
}

// Create 1 million points with same shape
const goodPoints = [];
for (let i = 0; i < 1000000; i++) {
  goodPoints.push({x: i, y: i * 2});
}

// Create 1 million points with different shapes
const badPoints = [];
for (let i = 0; i < 1000000; i++) {
  if (i % 2) {
    badPoints.push({x: i, y: i * 2});      // Shape A
  } else {
    badPoints.push({y: i * 2, x: i});      // Shape B - different order!
  }
}

console.time('Monomorphic');
let sum = 0;
for (const p of goodPoints) sum += getX(p);
console.timeEnd('Monomorphic');  // ~8ms on my machine

console.time('Polymorphic');
sum = 0;
for (const p of badPoints) sum += getX(p);
console.timeEnd('Polymorphic');  // ~450ms on my machine

That's a 56x difference! For the exact same logical operation!

Why? When getX sees only one hidden class (monomorphic), V8's inline cache remembers: "property x is always at offset 0". It becomes a simple memory read. But with multiple shapes (polymorphic), V8 checks: "Is this HC1? Check offset 0. Is this HC2? Check offset 1..." Eventually, with too many shapes (megamorphic), it gives up and does slow dictionary lookups.

Benedikt Meurer's optimization killers guide shows even more dramatic examples.

Common Pitfalls That Murder Performance

After diving deep into V8's source and Mathias Bynens' excellent articles, I found patterns that destroy Hidden Class optimizations:

The Delete Disaster

// DON'T DO THIS
const user = {name: "Alice", age: 28, premium: false};
delete user.premium;  // Forces dictionary mode - game over!

// DO THIS INSTEAD
user.premium = null;  // Maintains Hidden Class
user.premium = undefined;  // Also maintains Hidden Class

Once you delete, V8 converts the object to dictionary mode - a hash table. Every property access becomes a hash lookup. I've seen this single line slow down entire applications.

The Order Chaos

// DON'T: Random property order
function createUser(data) {
  const user = {};
  if (data.name) user.name = data.name;
  if (data.email) user.email = data.email;
  if (data.age) user.age = data.age;
  return user;
}
// Creates different Hidden Classes based on which properties exist!

// DO: Consistent shape
function createUser(data) {
  return {
    name: data.name || null,
    email: data.email || null,
    age: data.age || null
  };
}
// Always same Hidden Class!

The Dynamic Property Trap

// DON'T: Dynamic property names in hot code
function process(obj, fields) {
  const result = {};
  for (const field of fields) {
    result[field] = obj[field];  // Different shapes each time!
  }
  return result;
}

// DO: Known shapes
function processUser(user) {
  return {
    id: user.id,
    name: user.name,
    email: user.email
  };  // Always same shape!
}

The Art of Monomorphic Code

After weeks of optimization, here are patterns that consistently deliver peak performance:

Constructor Pattern

class Point {
  constructor(x = 0, y = 0) {
    // Initialize ALL properties in constructor
    this.x = x;
    this.y = y;
    this._cached = null;  // Even future properties!
  }

  cache(value) {
    this._cached = value;  // No new properties added
  }
}

Object Pool Pattern

// Reuse objects with consistent shape
const pointPool = [];

function acquirePoint(x, y) {
  if (pointPool.length > 0) {
    const p = pointPool.pop();
    p.x = x;
    p.y = y;
    return p;
  }
  return {x, y};  // Consistent shape
}

function releasePoint(p) {
  pointPool.push(p);
}

Array Processing Pattern

// Processing uniform arrays is FAST
const users = userIds.map(id => ({
  id,
  name: null,
  email: null,
  lastSeen: null
}));

// Later: fill in data without changing shape
for (const user of users) {
  const data = await fetchUser(user.id);
  user.name = data.name;
  user.email = data.email;
  user.lastSeen = data.lastSeen;
}

Bonus: Peeking Under the Hood with V8 Flags

Want to see Hidden Classes in action? V8 has secret flags that expose everything:

# See Hidden Class transitions
node --trace-maps your-script.js

# See inline cache states
node --trace-ic your-script.js

# See deoptimizations happen
node --trace-deopt your-script.js

I spent an entire weekend running these flags on production code. The output is verbose but incredibly educational. You can literally see V8 creating Hidden Classes, following transitions, and deoptimizing when you mess up.

Here's a mind-blowing trace output I got:

[TraceMaps: ReplaceDescriptors from= 0x1234...a (map 0x1234...b) to= 0x1234...c reason= field]
  -x: +0 const DATA
  +x: +0 const DATA
  +y: +1 const DATA

That's V8 creating a transition from HC1 (has x) to HC2 (has x and y). It's like watching the Matrix!

The Performance Transformation

Remember that slow Node.js service I mentioned at the beginning? After applying Hidden Class optimizations:

Response time: 340ms → 28ms
Memory usage: -40%
CPU utilization: -65%

The changes were surprisingly simple: consistent property initialization, removing delete statements, and ensuring uniform object shapes in hot paths. The Chrome DevTools Performance panel confirmed: inline cache hits went from 12% to 94%.

Conclusion

Hidden Classes are JavaScript's performance secret sauce. They're why V8 can make a dynamic language compete with static ones. Understanding them transformed how I write JavaScript - not through complex algorithms or fancy libraries, but by respecting how JavaScript engines actually work.

The beauty is that monomorphic code isn't just faster - it's often cleaner and more predictable. When you initialize all properties upfront, your objects become self-documenting. When you avoid delete, you're forced to handle nulls properly. When you maintain consistent shapes, your code becomes more maintainable.

Next time you're debugging performance issues, remember: those innocent-looking objects might be shape-shifting more than you think. A few strategic changes to maintain Hidden Class stability can unlock massive performance gains.

Join the Conversation:

At Lingo.dev, we develop APIs and open source tools to help developers produce perfect translations for their apps and documentation. Performance optimization like Hidden Classes is crucial when processing thousands of translation strings in real-time.

🐦 Follow us on Twitter for dev memes

💬 Join our fast-growing Discord community where developers work on next-gen i18n tools, share tips & tricks and debate whether that last millisecond matters (spoiler: it does)

Have a performance mystery you've solved? Share it with the community - we love learning about clever optimizations in the wild!

[Boost]

Max Prilutskiy — Wed, 17 Sep 2025 05:41:30 +0000

David Turnbull for Lingo.dev

Sep 17 '25

21 native browser APIs you might not have used before

#api #javascript #webdev

Comments 4

5 min read

Introducing Lingo.dev Compiler: Localize a React app without rewriting its code

Max Prilutskiy — Tue, 03 Jun 2025 18:46:01 +0000

Today, we're introducing Lingo.dev Compiler: An npm library, that lets you build multilingual React apps without having to rewrite the existing React code.

It doesn't require extracting i18n keys, or wrapping text in tags.

100% free and open-source.

Here's how it works:

The core challenge: How do you translate React components without touching the source code?

Traditional i18n requires rewriting your entire codebase - extracting strings to JSON files, wrapping components in translation tags, maintaining separate dictionaries.

We asked ourselves: "What if that actually wasn't necessary?"

AST

So, we came up with this idea to processes React app's Abstract Syntax Tree and perform localization at build time.

But here's the tricky part: we had to solve how to deterministically group elements that should be translated together.

For example, this entire block gets processed as one translation unit:

Not three separate fragments that lose meaning when isolated. This prevents mistranslations and maintains semantic relationships that LLMs need for context.

HMR

The biggest technical uncertainty was Hot Module Replacement compatibility.

We were lucky to solve this one pretty quickly, but picture this: you're coding in English but need to instantly see how your UI looks in Spanish or Japanese. Text expansion/contraction can break layouts in ways you'd never catch otherwise.

We rebuilt our processor to work seamlessly with HMR, so there’s no need in building twice to see translations.

Performance

Large codebases, including ours, can't afford slow incremental builds, so performance was another beast entirely. We're talking about processing thousands of components, each potentially containing dozens of translatable strings.

Our solution: aggressive caching that stores AST analysis results between runs + heavily parallelized LLM calls. Also Groq. So, only changed components get reprocessed. Everything else hits the cache.

By the way

What's interesting, is that this approach was technically possible before LLMs, but practically useless. You'd still need human translators familiar with your product domain for precise translations. The AST processing was just expensive preprocessing for manual work.

However now, with context-aware models, we can generate quality translations automatically. That's why compile-time, AI-powered localization isn't just possible – it's becoming the most practical approach for modern UIs.

We predict this compile-time approach will become standard. Think about it: why should developers maintain separate translation files when the compiler can generate them automatically?

Major i18n libraries will adopt similar AST-based models. Frameworks like Next.js and Remix will eventually bake this directly into their core. The traditional extract-wrap-maintain cycle is becoming obsolete.

Frameworks

Here's how we handle framework integration:

// Next.js
export default lingoCompiler.next({
  sourceLocale: "en",
  targetLocales: ["es", "fr", "de"],
  models: { "*:*": "groq:mistral-saba-24b" }

})(nextConfig);

Works with Next.js App Router, React Router, Remix, and Vite. Zero runtime cost - translations are pre-compiled into optimized bundles.

The compiler creates versioned dictionaries using MD5 fingerprinting.

// Generated in lingo/ directory
{
  "content": "Welcome to our platform!",
  "fingerprint": "a1b2c3d4e5f6",
  "translations": {
    "es": "¡Bienvenido a nuestra plataforma!",
    "fr": "Bienvenue sur notre plateforme!"
  }
}

Only retranslates when content actually changes. Git integration tracks translation history. Delta processing minimizes costs.

Bonus

Bonus feature I didn't mention: the compiler gracefully handles dynamic React patterns too:

// Compiler handles dynamic content gracefully

function UserGreeting({ name, count }) {
  return (
    div
      Welcome back, {name}! You have {count} messages.
    /div
  );
}

// Preserves React behavior while translating static text
// "Welcome back" + "You have" + "messages" get translated
// {name} and {count} remain dynamic

We were able to get the best of both worlds - no code changes + full React compatibility.

Workflow

The development workflow is beautifully simple:

Write React components using natural language text
Run development server - compiler extracts and translates content, using your API key
Commit translation files to version control
Deploy with built-in multilingual support

No configuration files to maintain. No manual string extraction. Just build and ship.

Next steps

Break it, test it, let us know what you think!

Here’s how to get started:

npm i lingo.dev

Docs: https://lingo.dev/compiler

GitHub: https://github.com/lingodotdev/lingo.dev

Demo: https://www.youtube.com/watch?v=sSo2ERxAvB4

Discord: https://lingo.dev/go/discord

We're scratching our own itch here, and we're excited to share it with the dev community!

(We’ve also just launch on HackerNews, please look us up, upvote + reply 😅)

https://news.ycombinator.com

Upcoming JavaScript Features You Should Know About

Max Prilutskiy — Fri, 30 May 2025 17:42:05 +0000

After 20 years of writing JavaScript, I've seen many changes - from callback hell to async/await. But the upcoming JavaScript features will transform how we write code completely.

We've tested these proposals using transpilers and polyfills, ans the results are impressive: code that took 30 lines now takes 10, complex logic becomes readable at a glance, and even junior developers (and Devin 😅) can understand complex parts of our codebase.

If you've read my previous articles on HTML5 elements you didn't know you need or CSS modal windows, you know we like unusual tech at Lingo.dev. These upcoming JavaScript features solve real problems that have annoyed developers for years.

Pipeline Operator Improves Code Readability

Complex data transformations in JavaScript often result in deeply nested function calls that are difficult to read and maintain. Developers must trace through nested functions from inside out, jumping between parentheses to understand the flow of data.

The pipeline operator (|>) solves this problem by allowing data to flow through a series of operations in a clear, top-to-bottom manner:

// Instead of this nested mess
const result = saveToDatabase(
  validateUser(
    normalizeData(
      enrichUserProfile(user)
    )
  )
);

// You'll write this
const result = user
  |> enrichUserProfile
  |> normalizeData
  |> validateUser
  |> saveToDatabase;

Let's look at a more complex real-world example. Consider an image processing service that has grown over time:

// Before: Nested function hell
function processImage(image) {
  return compressImage(
    addWatermark(
      optimizeForWeb(
        applyFilter(
          resizeImage(image, { width: 800, height: 600 }),
          'sepia'
        )
      ),
      'Copyright 2025'
    ),
    0.8
  );
}

// After: Clean, readable pipeline
function processImage(image) {
  return image
    |> (img) => resizeImage(img, { width: 800, height: 600 })
    |> (img) => applyFilter(img, 'sepia')
    |> optimizeForWeb
    |> (img) => addWatermark(img, 'Copyright 2025')
    |> (img) => compressImage(img, 0.8);
}

Here's another practical example showing how the pipeline operator simplifies data processing for analytics:

// Before: Hard to follow the data flow
function analyzeUserData(users) {
  return generateReport(
    groupByMetric(
      filterInactiveUsers(
        normalizeUserData(users)
      ),
      'registrationMonth'
    )
  );
}

// After: Clear data transformation steps
function analyzeUserData(users) {
  return users
    |> normalizeUserData
    |> filterInactiveUsers
    |> (data) => groupByMetric(data, 'registrationMonth')
    |> generateReport;
}

The pipeline operator also makes it easier to insert debugging or logging between steps:

function processPayment(payment) {
  return payment
    |> validatePayment
    |> (result) => {
        console.log(`Validation result: ${JSON.stringify(result)}`);
        return result;
      }
    |> processTransaction
    |> (result) => {
        console.log(`Transaction result: ${JSON.stringify(result)}`);
        return result;
      }
    |> sendReceipt;
}

How to Use It Today

The pipeline operator is currently at Stage 2 in the TC39 process as of May 2025. While not yet part of the official JavaScript specification, you can start using it today:

With Babel (Generic Setup):

# Install the pipeline operator plugin
npm install --save-dev @babel/plugin-proposal-pipeline-operator

Add to your .babelrc:

{
  "plugins": [
    ["@babel/plugin-proposal-pipeline-operator", { "proposal": "hack", "topicToken": "%"}]
  ]
}

With Vite:

# Install dependencies
npm install --save-dev vite-plugin-babel @babel/core @babel/plugin-proposal-pipeline-operator

// vite.config.js
import { defineConfig } from 'vite';
import babel from 'vite-plugin-babel';

export default defineConfig({
  plugins: [
    babel({
      babelConfig: {
        plugins: [
          ['@babel/plugin-proposal-pipeline-operator', { proposal: 'hack', topicToken: '%' }]
        ]
      }
    })
  ]
});

With Next.js:

# Install the pipeline operator plugin
npm install --save-dev @babel/plugin-proposal-pipeline-operator

// .babelrc
{
  "presets": ["next/babel"],
  "plugins": [
    ["@babel/plugin-proposal-pipeline-operator", { "proposal": "hack", "topicToken": "%" }]
  ]
}

With tsup:

# Install dependencies
npm install --save-dev tsup @babel/core @babel/plugin-proposal-pipeline-operator

// tsup.config.ts
import { defineConfig } from 'tsup';
import * as babel from '@babel/core';
import fs from 'fs';

export default defineConfig({
  entry: ['src/index.ts'],
  format: ['cjs', 'esm'],
  dts: true,
  esbuildPlugins: [
    {
      name: 'babel',
      setup(build) {
        build.onLoad({ filter: /\.(jsx?|tsx?)$/ }, async (args) => {
          const source = await fs.promises.readFile(args.path, 'utf8');
          const result = await babel.transformAsync(source, {
            filename: args.path,
            presets: [
              ['@babel/preset-env', { targets: 'defaults' }],
              '@babel/preset-typescript'
            ],
            plugins: [
              ['@babel/plugin-proposal-pipeline-operator', { proposal: 'hack', topicToken: '%' }]
            ]
          });

          return {
            contents: result?.code || '',
            loader: args.path.endsWith('x') ? 'jsx' : 'js'
          };
        });
      }
    }
  ]
});

With Remix (using Vite):

# Install dependencies
npm install --save-dev vite-plugin-babel @babel/core @babel/plugin-proposal-pipeline-operator

// vite.config.js
import { defineConfig } from 'vite';
import { vitePlugin as remix } from '@remix-run/dev';
import babel from 'vite-plugin-babel';

export default defineConfig({
  plugins: [
    babel({
      babelConfig: {
        plugins: [
          ['@babel/plugin-proposal-pipeline-operator', { proposal: 'hack', topicToken: '%' }]
        ]
      }
    }),
    remix()
  ]
});

Pattern Matching Simplifies Complex Conditionals

Complex if/else statements and switch cases quickly become unwieldy in large codebases. Functions with nested if/else blocks checking various object properties make it nearly impossible to verify all edge cases.

Pattern matching provides a direct solution to this problem.

This feature brings functional programming capabilities to JavaScript, allowing you to match and destructure complex data in a single operation:

function processMessage(message) {
  return match (message) {
    when String(text) => `Text message: ${text}`,
    when [String(sender), String(content)] => `Message from ${sender}: ${content}`,
    when { type: 'error', content: String(text), code: Number(code) } => 
      `Error: ${text} (Code: ${code})`,
    when _ => 'Unknown message format'
  };
}

Without pattern matching, you'd need multiple if/else statements with type checking:

function processMessage(message) {
  // Check if it's a string
  if (typeof message === 'string') {
    return `Text message: ${message}`;
  }

  // Check if it's an array with specific structure
  if (Array.isArray(message) && 
      message.length === 2 && 
      typeof message[0] === 'string' && 
      typeof message[1] === 'string') {
    return `Message from ${message[0]}: ${message[1]}`;
  }

  // Check if it's an object with specific properties
  if (message && 
      typeof message === 'object' && 
      message.type === 'error' && 
      typeof message.content === 'string' && 
      typeof message.code === 'number') {
    return `Error: ${message.content} (Code: ${message.code})`;
  }

  // Default case
  return 'Unknown message format';
}

Pattern matching excels when handling complex state transitions in modern web applications:

function handleUserAction(state, action) {
  return match ([state, action]) {
    when [{ status: 'idle' }, { type: 'FETCH_START' }] => 
      ({ status: 'loading', data: state.data }),

    when [{ status: 'loading' }, { type: 'FETCH_SUCCESS', payload }] => 
      ({ status: 'success', data: payload, error: null }),

    when [{ status: 'loading' }, { type: 'FETCH_ERROR', error }] => 
      ({ status: 'error', data: null, error }),

    when [{ status: 'success' }, { type: 'REFRESH' }] => 
      ({ status: 'loading', data: state.data }),

    when _ => state
  };
}

The equivalent code without pattern matching is significantly more verbose:

function handleUserAction(state, action) {
  // Check idle state + fetch start
  if (state.status === 'idle' && action.type === 'FETCH_START') {
    return { status: 'loading', data: state.data };
  }

  // Check loading state + fetch success
  if (state.status === 'loading' && action.type === 'FETCH_SUCCESS') {
    return { status: 'success', data: action.payload, error: null };
  }

  // Check loading state + fetch error
  if (state.status === 'loading' && action.type === 'FETCH_ERROR') {
    return { status: 'error', data: null, error: action.error };
  }

  // Check success state + refresh
  if (state.status === 'success' && action.type === 'REFRESH') {
    return { status: 'loading', data: state.data };
  }

  // Default: return unchanged state
  return state;
}

Pattern matching also provides exhaustiveness checking - the compiler warns you if you've missed handling a possible case. This eliminates an entire class of bugs that plague traditional conditional logic.

Here's another practical example for parsing configuration formats:

function parseConfig(config) {
  return match (config) {
    when { version: 1, settings: Object(settings) } => 
      parseV1Settings(settings),

    when { version: 2, config: Object(settings) } => 
      parseV2Settings(settings),

    when String(jsonString) => 
      parseConfig(JSON.parse(jsonString)),

    when [String(env), Object(overrides)] =>
      mergeConfigs(getEnvConfig(env), overrides),

    when _ => 
      throw new Error(`Invalid configuration format: ${JSON.stringify(config)}`)
  };
}

How to Use It Today

Pattern matching is currently at Stage 1 in the TC39 process as of May 2025, which means it's still in the proposal phase with ongoing discussions about syntax and semantics. However, you can experiment with it today:

With Babel (Generic Setup):

# Install the pattern matching plugin
npm install --save-dev babel-plugin-proposal-pattern-matching

Add to your .babelrc:

{
  "plugins": ["babel-plugin-proposal-pattern-matching"]
}

With Vite:

# Install dependencies
npm install --save-dev vite-plugin-babel @babel/core babel-plugin-proposal-pattern-matching

// vite.config.js
import { defineConfig } from 'vite';
import babel from 'vite-plugin-babel';

export default defineConfig({
  plugins: [
    babel({
      babelConfig: {
        plugins: [
          'babel-plugin-proposal-pattern-matching'
        ]
      }
    })
  ]
});

With Next.js:

# Install the pattern matching plugin
npm install --save-dev babel-plugin-proposal-pattern-matching

// .babelrc
{
  "presets": ["next/babel"],
  "plugins": [
    "babel-plugin-proposal-pattern-matching"
  ]
}

With tsup:

# Install dependencies
npm install --save-dev tsup @babel/core babel-plugin-proposal-pattern-matching

// tsup.config.ts
import { defineConfig } from 'tsup';
import * as babel from '@babel/core';
import fs from 'fs';

export default defineConfig({
  entry: ['src/index.ts'],
  format: ['cjs', 'esm'],
  dts: true,
  esbuildPlugins: [
    {
      name: 'babel',
      setup(build) {
        build.onLoad({ filter: /\.(jsx?|tsx?)$/ }, async (args) => {
          const source = await fs.promises.readFile(args.path, 'utf8');
          const result = await babel.transformAsync(source, {
            filename: args.path,
            presets: [
              ['@babel/preset-env', { targets: 'defaults' }],
              '@babel/preset-typescript'
            ],
            plugins: [
              'babel-plugin-proposal-pattern-matching'
            ]
          });

          return {
            contents: result?.code || '',
            loader: args.path.endsWith('x') ? 'jsx' : 'js'
          };
        });
      }
    }
  ]
});

Production Alternatives:

For production code today, use the ts-pattern library:

npm install ts-pattern

import { match, P } from 'ts-pattern';

function processMessage(message: unknown) {
  return match(message)
    .with(P.string, text => `Text message: ${text}`)
    .with([P.string, P.string], ([sender, content]) => 
      `Message from ${sender}: ${content}`)
    .with({ type: 'error', content: P.string, code: P.number }, 
      ({ content, code }) => `Error: ${content} (Code: ${code})`)
    .otherwise(() => 'Unknown message format');
}

Temporal API Solves Date Handling Problems

JavaScript's built-in Date object has long been a source of frustration for developers. It's mutable (dates can be accidentally modified), has confusing month indexing (January is 0!), and timezone handling is problematic. These issues have led to the widespread use of libraries like Moment.js, date-fns, and Luxon.

The Temporal API provides a complete solution to these problems by reimagining date and time handling in JavaScript.

Here's a practical example of scheduling a meeting across timezones:

// Current approach with Date (likely to have bugs)
function scheduleMeeting(startDate, durationInMinutes, timeZone) {
  const start = new Date(startDate);
  const end = new Date(start.getTime() + durationInMinutes * 60000);

  return {
    start: start.toISOString(),
    end: end.toISOString(),
    timeZone: timeZone // Not actually used in calculations
  };
}

// With Temporal API
function scheduleMeeting(startDateTime, durationInMinutes, timeZone) {
  const start = Temporal.ZonedDateTime.from(startDateTime);
  const end = start.add({ minutes: durationInMinutes });

  return {
    start: start.toString(),
    end: end.toString(),
    timeZone: start.timeZoneId // Properly tracked
  };
}

For international flight booking systems, calculating flight durations across timezones becomes straightforward:

// Current approach with Date (error-prone)
function calculateFlightDuration(departure, arrival, departureTimeZone, arrivalTimeZone) {
  // Convert to milliseconds and calculate difference
  const departureTime = new Date(departure);
  const arrivalTime = new Date(arrival);

  // This doesn't account for timezone differences correctly
  const durationMs = arrivalTime - departureTime;

  return {
    hours: Math.floor(durationMs / (1000 * 60 * 60)),
    minutes: Math.floor((durationMs % (1000 * 60 * 60)) / (1000 * 60)),
    // No easy way to get arrival in departure's timezone
  };
}

// With Temporal API
function calculateFlightDuration(departure, arrival) {
  const departureTime = Temporal.ZonedDateTime.from(departure);
  const arrivalTime = Temporal.ZonedDateTime.from(arrival);

  // Accurate duration calculation across time zones
  const duration = departureTime.until(arrivalTime);

  return {
    hours: duration.hours,
    minutes: duration.minutes,
    inLocalTime: arrivalTime.toLocaleString(),
    inDepartureTime: arrivalTime.withTimeZone(departureTime.timeZoneId).toLocaleString()
  };
}

Here's another example showing how Temporal API handles recurring events, which are notoriously difficult with the current Date object:

// Current approach with Date (complex and error-prone)
function getNextMeetingDates(startDate, count) {
  const dates = [];
  const current = new Date(startDate);

  for (let i = 0; i < count; i++) {
    dates.push(new Date(current));

    // Add 2 weeks - error-prone due to month boundaries, DST changes, etc.
    current.setDate(current.getDate() + 14);
  }

  return dates;
}

// With Temporal API
function getNextMeetingDates(startDate, count) {
  const start = Temporal.PlainDate.from(startDate);
  const dates = [];

  for (let i = 0; i < count; i++) {
    const nextDate = start.add({ days: i * 14 });
    dates.push(nextDate);
  }

  return dates;
}

The Temporal API provides several key advantages:

Immutability: All Temporal objects are immutable, preventing accidental modifications
Separate types for different use cases: PlainDate, PlainTime, ZonedDateTime, etc.
Intuitive methods: Clear, chainable methods for date arithmetic
Proper timezone handling: Built-in support for timezones and daylight saving time
Consistent behavior: Works the same way across all browsers

How to Use It Today

The Temporal API is at Stage 3 in the TC39 process as of May 2025, which means it's nearing completion and implementations are being developed. Here's how to use it today:

With the Official Polyfill:

npm install @js-temporal/polyfill

// Import in your code
import { Temporal } from '@js-temporal/polyfill';

// Get the current date and time
const now = Temporal.Now.plainDateTimeISO();
console.log(`Current time: ${now.toString()}`);

With Vite:

# Install the Temporal API polyfill
npm install @js-temporal/polyfill

// main.js or any entry file
import { Temporal } from '@js-temporal/polyfill';

// Now you can use Temporal API in your code
const now = Temporal.Now.plainDateTimeISO();
console.log(`Current time: ${now.toString()}`);

With Next.js:

# Install the Temporal API polyfill
npm install @js-temporal/polyfill

// pages/_app.js
import { Temporal } from '@js-temporal/polyfill';

// Make Temporal available globally if needed
if (typeof window !== 'undefined') {
  window.Temporal = Temporal;
}

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

export default MyApp;

With tsup:

# Install the Temporal API polyfill
npm install @js-temporal/polyfill

// src/index.ts
import { Temporal } from '@js-temporal/polyfill';

// Export it if you want to make it available to consumers of your package
export { Temporal };

// Your other code here

Browser Support:

Chrome/Edge: Available behind the "Experimental JavaScript" flag
Firefox: Available in Firefox 139 and later
Safari: Not yet implemented

To check if Temporal is natively supported:

if (typeof Temporal !== 'undefined') {
  console.log('Temporal API is natively supported');
} else {
  console.log('Using polyfill');
  // Import polyfill
}

Resource Management Eliminates Memory Leaks

JavaScript has long lacked deterministic resource cleanup. When working with files, database connections, or hardware access, developers must manually ensure resources are properly released - even in error cases.

This limitation leads to memory leaks and resource exhaustion bugs. The typical pattern involves try/finally blocks that quickly become unwieldy:

async function processFile(path) {
  let file = null;
  try {
    file = await fs.promises.open(path, 'r');
    const content = await file.readFile({ encoding: 'utf8' });
    return processContent(content);
  } finally {
    if (file) {
      await file.close();
    }
  }
}

The new using and await using statements provide deterministic resource management in JavaScript:

async function processFile(path) {
  await using file = await fs.promises.open(path, 'r');
  const content = await file.readFile({ encoding: 'utf8' });
  return processContent(content);
  // File is automatically closed when the block exits
}

Let's look at a more complex example with multiple resources that must be managed in a specific order:

// Current approach: Nested try/finally blocks
async function processData(dbConfig, filePath) {
  let db = null;
  let file = null;

  try {
    db = await Database.connect(dbConfig);

    try {
      file = await fs.promises.open(filePath, 'r');
      const data = await file.readFile({ encoding: 'utf8' });
      const processed = processRawData(data);

      return db.store(processed);
    } finally {
      if (file) {
        await file.close();
      }
    }
  } finally {
    if (db) {
      await db.disconnect();
    }
  }
}

// With resource management: Clean and safe
async function processData(dbConfig, filePath) {
  await using db = await Database.connect(dbConfig);
  await using file = await fs.promises.open(filePath, 'r');

  const data = await file.readFile({ encoding: 'utf8' });
  const processed = processRawData(data);

  return db.store(processed);
  // Resources are automatically cleaned up in reverse order:
  // 1. file is closed
  // 2. db is disconnected
}

For database-heavy applications, this feature transforms connection pool management:

class DatabaseConnection {
  constructor(config) {
    this.config = config;
    this.connection = null;
  }

  async connect() {
    this.connection = await createConnection(this.config);
    return this;
  }

  async query(sql, params) {
    return this.connection.query(sql, params);
  }

  async [Symbol.asyncDispose]() {
    if (this.connection) {
      await this.connection.close();
      this.connection = null;
    }
  }
}

// Using the connection with automatic cleanup
async function getUserData(userId) {
  await using db = await new DatabaseConnection(config).connect();
  return db.query('SELECT * FROM users WHERE id = ?', [userId]);
  // Connection is automatically closed when the function exits
}

Here's another example showing how to manage hardware resources like WebUSB devices:

// Current approach: Manual cleanup required
async function readFromUSBDevice(deviceFilter) {
  let device = null;
  try {
    const devices = await navigator.usb.getDevices();
    device = devices.find(d => d.productId === deviceFilter.productId);

    if (!device) {
      device = await navigator.usb.requestDevice({ filters: [deviceFilter] });
    }

    await device.open();
    await device.selectConfiguration(1);
    await device.claimInterface(0);

    const result = await device.transferIn(1, 64);
    return new TextDecoder().decode(result.data);
  } finally {
    if (device) {
      try {
        await device.close();
      } catch (e) {
        console.error("Error closing device:", e);
      }
    }
  }
}

// With resource management: Automatic cleanup
class USBDeviceResource {
  constructor(device) {
    this.device = device;
  }

  static async create(deviceFilter) {
    const devices = await navigator.usb.getDevices();
    let device = devices.find(d => d.productId === deviceFilter.productId);

    if (!device) {
      device = await navigator.usb.requestDevice({ filters: [deviceFilter] });
    }

    await device.open();
    await device.selectConfiguration(1);
    await device.claimInterface(0);

    return new USBDeviceResource(device);
  }

  async read() {
    const result = await this.device.transferIn(1, 64);
    return new TextDecoder().decode(result.data);
  }

  async [Symbol.asyncDispose]() {
    try {
      await this.device.close();
    } catch (e) {
      console.error("Error closing device:", e);
    }
  }
}

async function readFromUSBDevice(deviceFilter) {
  await using device = await USBDeviceResource.create(deviceFilter);
  return device.read();
  // Device is automatically closed when the function exits
}

How to Use It Today

The Explicit Resource Management proposal (using/await using) is at Stage 3 in the TC39 process as of May 2025, which means it's nearing standardization. Here's how to use it today:

With Babel (Generic Setup):

# Install the resource management plugin
npm install --save-dev @babel/plugin-proposal-explicit-resource-management

Add to your .babelrc:

{
  "plugins": ["@babel/plugin-proposal-explicit-resource-management"]
}

With Vite:

# Install dependencies
npm install --save-dev vite-plugin-babel @babel/core @babel/plugin-proposal-explicit-resource-management

// vite.config.js
import { defineConfig } from 'vite';
import babel from 'vite-plugin-babel';

export default defineConfig({
  plugins: [
    babel({
      babelConfig: {
        plugins: [
          '@babel/plugin-proposal-explicit-resource-management'
        ]
      }
    })
  ]
});

With Next.js:

# Install the resource management plugin
npm install --save-dev @babel/plugin-proposal-explicit-resource-management

// .babelrc
{
  "presets": ["next/babel"],
  "plugins": [
    "@babel/plugin-proposal-explicit-resource-management"
  ]
}

With tsup:

# Install dependencies
npm install --save-dev tsup @babel/core @babel/plugin-proposal-explicit-resource-management

// tsup.config.ts
import { defineConfig } from 'tsup';
import * as babel from '@babel/core';
import fs from 'fs';

export default defineConfig({
  entry: ['src/index.ts'],
  format: ['cjs', 'esm'],
  dts: true,
  esbuildPlugins: [
    {
      name: 'babel',
      setup(build) {
        build.onLoad({ filter: /\.(jsx?|tsx?)$/ }, async (args) => {
          const source = await fs.promises.readFile(args.path, 'utf8');
          const result = await babel.transformAsync(source, {
            filename: args.path,
            presets: [
              ['@babel/preset-env', { targets: 'defaults' }],
              '@babel/preset-typescript'
            ],
            plugins: [
              '@babel/plugin-proposal-explicit-resource-management'
            ]
          });

          return {
            contents: result?.code || '',
            loader: args.path.endsWith('x') ? 'jsx' : 'js'
          };
        });
      }
    }
  ]
});

Making Objects Disposable:

To make your objects work with using, implement the Symbol.dispose method:

class MyResource {
  [Symbol.dispose]() {
    // Cleanup code here
  }
}

For async resources, implement Symbol.asyncDispose:

class MyAsyncResource {
  async [Symbol.asyncDispose]() {
    // Async cleanup code here
  }
}

Polyfill for Symbols:

// polyfill.js
if (!Symbol.dispose) {
  Symbol.dispose = Symbol("Symbol.dispose");
}

if (!Symbol.asyncDispose) {
  Symbol.asyncDispose = Symbol("Symbol.asyncDispose");
}

Decorators Add Functionality Without Changing Core Logic

JavaScript decorators provide a clean way to modify classes and methods with additional functionality. If you've used TypeScript or frameworks like Angular, you're already familiar with the concept. Now decorators are coming to vanilla JavaScript.

Decorators solve a fundamental problem: how to add cross-cutting concerns like logging, validation, or performance monitoring without cluttering your business logic.

Here's a practical example:

class UserController {
  @authenticate
  @rateLimit(100)
  @validate(userSchema)
  @logAccess
  async updateUserProfile(userId, profileData) {
    // The method is automatically wrapped with:
    // 1. Authentication check
    // 2. Rate limiting (100 requests per hour)
    // 3. Input validation against userSchema
    // 4. Access logging

    const user = await this.userRepository.findById(userId);
    Object.assign(user, profileData);
    return this.userRepository.save(user);
  }
}

Without decorators, you'd need to manually wrap each method, resulting in code that's harder to read and maintain:

class UserController {
  async updateUserProfile(userId, profileData) {
    // Authentication check
    if (!isAuthenticated()) {
      throw new Error('Unauthorized');
    }

    // Rate limiting
    if (isRateLimited(this.constructor.name, 'updateUserProfile', 100)) {
      throw new Error('Rate limit exceeded');
    }

    // Input validation
    const validationResult = validateWithSchema(userSchema, profileData);
    if (!validationResult.valid) {
      throw new Error(`Invalid data: ${validationResult.errors.join(', ')}`);
    }

    // Logging
    logAccess(this.constructor.name, 'updateUserProfile', userId);

    // Actual business logic
    const user = await this.userRepository.findById(userId);
    Object.assign(user, profileData);
    return this.userRepository.save(user);
  }
}

Here's a real-world example of using decorators for performance monitoring:

class DataProcessor {
  @measure
  @cache
  processLargeDataset(data) {
    // Complex and time-consuming operation
    return data.map(item => /* complex transformation */)
               .filter(item => /* complex filtering */)
               .reduce((acc, item) => /* complex aggregation */);
  }
}

// Performance measurement decorator
function measure(target, name, descriptor) {
  const original = descriptor.value;
  descriptor.value = function(...args) {
    const start = performance.now();
    const result = original.apply(this, args);
    const end = performance.now();
    console.log(`${name} took ${end - start}ms to execute`);
    return result;
  };
  return descriptor;
}

// Caching decorator
function cache(target, name, descriptor) {
  const original = descriptor.value;
  const cacheStore = new Map();

  descriptor.value = function(...args) {
    const key = JSON.stringify(args);
    if (cacheStore.has(key)) {
      console.log(`Cache hit for ${name}`);
      return cacheStore.get(key);
    }

    console.log(`Cache miss for ${name}`);
    const result = original.apply(this, args);
    cacheStore.set(key, result);
    return result;
  };

  return descriptor;
}

Decorators are particularly valuable for API development. Here's an example of using decorators to implement a RESTful API with proper error handling:

class ProductAPI {
  @route('GET', '/products')
  @paginate
  @handleErrors
  async getAllProducts(req) {
    return this.productRepository.findAll();
  }

  @route('GET', '/products/:id')
  @handleErrors
  async getProductById(req) {
    const product = await this.productRepository.findById(req.params.id);
    if (!product) {
      throw new NotFoundError(`Product with ID ${req.params.id} not found`);
    }
    return product;
  }

  @route('POST', '/products')
  @validate(productSchema)
  @handleErrors
  async createProduct(req) {
    return this.productRepository.create(req.body);
  }
}

// Route decorator
function route(method, path) {
  return function(target, name, descriptor) {
    if (!target.constructor._routes) {
      target.constructor._routes = [];
    }

    target.constructor._routes.push({
      method,
      path,
      handler: descriptor.value,
      name
    });

    return descriptor;
  };
}

// Error handling decorator
function handleErrors(target, name, descriptor) {
  const original = descriptor.value;

  descriptor.value = async function(req, res) {
    try {
      const result = await original.call(this, req);
      return res.json(result);
    } catch (error) {
      if (error instanceof NotFoundError) {
        return res.status(404).json({ error: error.message });
      }
      if (error instanceof ValidationError) {
        return res.status(400).json({ error: error.message });
      }
      console.error(`Error in ${name}:`, error);
      return res.status(500).json({ error: 'Internal server error' });
    }
  };

  return descriptor;
}

How to Use Decorators Today

Decorators are at Stage 3 in the TC39 process as of May 2025, with implementations in progress in major browsers. Here's how to use them today:

With Babel (Generic Setup):

# Install the decorators plugin
npm install --save-dev @babel/plugin-proposal-decorators

Add to your .babelrc:

{
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "2023-05" }]
  ]
}

With Vite:

# Install dependencies
npm install --save-dev vite-plugin-babel @babel/core @babel/plugin-proposal-decorators

// vite.config.js
import { defineConfig } from 'vite';
import babel from 'vite-plugin-babel';

export default defineConfig({
  plugins: [
    babel({
      babelConfig: {
        plugins: [
          ['@babel/plugin-proposal-decorators', { version: '2023-05' }]
        ]
      }
    })
  ]
});

With Next.js:

# Install the decorators plugin
npm install --save-dev @babel/plugin-proposal-decorators

// .babelrc
{
  "presets": ["next/babel"],
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "2023-05" }]
  ]
}

With TypeScript:

Enable decorators in tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "experimentalDecorators": true
  }
}

With tsup:

# Install dependencies
npm install --save-dev tsup @babel/core @babel/plugin-proposal-decorators

// tsup.config.ts
import { defineConfig } from 'tsup';
import * as babel from '@babel/core';
import fs from 'fs';

export default defineConfig({
  entry: ['src/index.ts'],
  format: ['cjs', 'esm'],
  dts: true,
  esbuildPlugins: [
    {
      name: 'babel',
      setup(build) {
        build.onLoad({ filter: /\.(jsx?|tsx?)$/ }, async (args) => {
          const source = await fs.promises.readFile(args.path, 'utf8');
          const result = await babel.transformAsync(source, {
            filename: args.path,
            presets: [
              ['@babel/preset-env', { targets: 'defaults' }],
              '@babel/preset-typescript'
            ],
            plugins: [
              ['@babel/plugin-proposal-decorators', { version: '2023-05' }]
            ]
          });

          return {
            contents: result?.code || '',
            loader: args.path.endsWith('x') ? 'jsx' : 'js'
          };
        });
      }
    }
  ]
});

Important Note:

The decorator proposal has gone through several iterations. Make sure you're using the latest syntax (2023-05 version) as older versions are incompatible. The current specification defines three capabilities for decorators:

They can replace the decorated value with a matching value
They can provide access to the decorated value
They can initialize the decorated value

Testing Your Configuration

After setting up your configuration, create a simple test file to verify that the features are working:

// test-features.js

// Test pipeline operator
const double = x => x * 2;
const add = x => x + 1;
const square = x => x * x;

const result = 5
  |> double
  |> add
  |> square;

console.log("Pipeline result:", result); // Should be 121

// Test pattern matching
function processValue(value) {
  return match (value) {
    when String(s) => `String: ${s}`,
    when Number(n) => `Number: ${n}`,
    when { type, data } => `Object with type ${type}`,
    when _ => 'Unknown'
  };
}

console.log("Pattern matching:", processValue("test"), processValue(42), processValue({ type: "user", data: {} }));

// Test Temporal API
import { Temporal } from '@js-temporal/polyfill';
const now = Temporal.Now.plainDateTimeISO();
console.log("Current time:", now.toString());

// Test resource management
class Resource {
  constructor(name) {
    this.name = name;
    console.log(`Resource ${name} created`);
  }

  [Symbol.dispose]() {
    console.log(`Resource ${this.name} disposed`);
  }
}

{
  using resource = new Resource("test");
  console.log("Using resource");
} // Resource should be disposed here

// Test decorators
function log(target, name, descriptor) {
  const original = descriptor.value;
  descriptor.value = function(...args) {
    console.log(`Calling ${name} with ${JSON.stringify(args)}`);
    return original.apply(this, args);
  };
  return descriptor;
}

class Calculator {
  @log
  add(a, b) {
    return a + b;
  }
}

const calc = new Calculator();
console.log("Decorator result:", calc.add(2, 3));

Conclusion

These upcoming JavaScript features aren't just syntactic sugar - they fundamentally change how we write code. At Lingo.dev, we've already seen how they can transform complex, error-prone code into clean, maintainable solutions.

The best part is you don't have to wait. With the right tools, you can start using these features today. Each one solves real problems that developers face daily, from managing resources to handling dates correctly.

What upcoming JavaScript feature are you most excited about? Have you found other ways to solve these problems in your codebase?

Share your thoughts!

Useful links:

Lingo.dev on Twitter/X - dev + fun;
GitHub repo - give us a star :)

Shocking Things You Can Do in JavaScript

Max Prilutskiy — Sat, 24 May 2025 03:09:05 +0000

Think you know JavaScript? I thought I did too, until I discovered features that completely changed how I write code. During a recent pair programming session, my teammate watched in disbelief as I transformed a 30-line utility function into three lines of native JavaScript.

"Wait, since when can you do that?" he asked. That moment made me realize how many of us developers are missing out on JavaScript's most powerful capabilities.

At Lingo.dev, we're constantly exploring the edges of what's possible with modern web. When I shared these discoveries with my dev friends, even the senior developers were surprised by some of these features. That's when I knew I had to write this article.

The truth is, JavaScript has quietly evolved into a language with shocking capabilities that eliminate the need for many popular libraries. These aren't experimental features or proposals - they're stable, cross-platform functionalities available right now that will make you rethink what's possible in vanilla JavaScript.

So after my last article on surprising HTML5 elements got such a positive response, I realized I'd share more hidden gems. And after 20 years of coding, I'm still finding JavaScript features that make me do a double-take. Just like when I discovered you could create modal windows with pure CSS and no JavaScript, these JavaScript capabilities show how powerful modern web standards have become.

Set operations that make lodash obsolete

I used to reach for lodash whenever I needed to compare arrays or find unique values. Not anymore. Modern JavaScript Sets now include native methods for all the set operations you'd expect from a proper programming language.

// Creating sets of programming languages
const frontendLangs = new Set(['JavaScript', 'TypeScript', 'HTML', 'CSS']);
const backendLangs = new Set(['Python', 'JavaScript', 'Java', 'Go', 'Ruby']);

// Find languages used in both frontend and backend (intersection)
const fullstackLangs = frontendLangs.intersection(backendLangs);
console.log([...fullstackLangs]); // ['JavaScript']

// Find languages unique to frontend (difference)
const frontendOnlyLangs = frontendLangs.difference(backendLangs);
console.log([...frontendOnlyLangs]); // ['TypeScript', 'HTML', 'CSS']

I've lost count of how many times I've written utility functions to find the intersection or difference between arrays. Now it's built right into the language with intersection(), difference(), union(), and even symmetricDifference(). There are also predicate methods like isSubsetOf(), isSupersetOf(), and isDisjointFrom() that make set comparisons trivial.

What's particularly elegant about these methods is that they work with any "set-like" object that provides a size property, a has() method, and a keys() iterator. This means you can use Maps as sets of keys, making these operations even more versatile than their lodash counterparts.

Non-destructive array methods that respect immutability

Working with immutable data has always been a pain point in JavaScript. We've written countless utility functions and reached for libraries like Immer just to avoid mutating our arrays. Now JavaScript has native solutions with the "to-" prefixed array methods.

// Original array of user scores
const scores = [82, 95, 68, 90, 77];

// Sort scores without modifying original array
const sortedScores = scores.toSorted((a, b) => b - a);
console.log('Original scores:', scores); // [82, 95, 68, 90, 77]
console.log('Sorted scores (high to low):', sortedScores); // [95, 90, 82, 77, 68]

// Replace a score without modifying original array
const updatedScores = scores.with(2, 73); // Replace index 2 (value 68) with 73
console.log('Updated scores:', updatedScores); // [82, 95, 73, 90, 77]

These methods mirror their mutating counterparts but return new arrays instead: toSorted() instead of sort(), toReversed() instead of reverse(), toSpliced() instead of splice(), and with() as a non-destructive version of bracket assignment.

The beauty of these methods is that they can be chained together for complex transformations while preserving your original data. No more defensive copying with [...array] or array.slice() before every operation.

Object grouping that transforms your data instantly

Ever needed to group an array of objects by some property? I used to write a reducer function every single time. Now there's a built-in solution that's both elegant and powerful.

// A collection of products
const products = [
  { name: "Laptop", category: "Electronics", price: 1200, inStock: true },
  { name: "Headphones", category: "Electronics", price: 100, inStock: true },
  { name: "Coffee Maker", category: "Kitchen", price: 80, inStock: false },
  { name: "Running Shoes", category: "Apparel", price: 120, inStock: true },
  { name: "Blender", category: "Kitchen", price: 60, inStock: true },
  { name: "T-shirt", category: "Apparel", price: 25, inStock: false }
];

// Group products by category
const productsByCategory = Object.groupBy(products, product => product.category);

This gives you an object with keys for each category and arrays of matching products as values. It's the kind of operation that used to require a reduce function with a bunch of conditionals, but now it's a one-liner.

What makes this feature particularly powerful is its flexibility. You can group by any computed value, not just object properties. Want to group by price range? Just return a string like 'Budget', 'Mid-range', or 'Premium' from your callback. Need to group by multiple criteria? Return a composite key. The possibilities are endless.

Text segmentation that actually understands language

If you've ever worked with internationalization, you know that splitting text by spaces doesn't work for many languages. Japanese, Chinese, Thai, and others don't use spaces between words, making proper text segmentation a nightmare. Enter Intl.Segmenter.

// Text segmentation for languages without spaces between words
const japaneseText = "吾輩は猫である。名前はまだない。";

// Create a word segmenter for Japanese
const japaneseWordSegmenter = new Intl.Segmenter('ja-JP', { granularity: 'word' });

// Segment Japanese text into words
const japaneseWords = [...japaneseWordSegmenter.segment(japaneseText)]
  .filter(segment => segment.isWordLike)
  .map(segment => segment.segment);

console.log(japaneseWords);
// ['吾輩', 'は', '猫', 'である', '名前', 'は', 'まだ', 'ない']

This feature is a game-changer for multilingual applications. You can segment text by graphemes (characters), words, or sentences, with full support for the nuances of each language. It's the kind of functionality that used to require specialized libraries or server-side processing.

The API is surprisingly simple yet powerful. You create a segmenter with a locale and granularity, then call its segment() method on any string. The result is an iterator that gives you each segment along with metadata like whether it's a word or punctuation.

At Lingo.dev, we've been using this a lot deep inside our localization API, and it's dramatically simplified our text processing pipeline. What used to require multiple specialized libraries and server-side processing can now be handled directly in the browser with just a few lines of code.

Logical assignment operators that simplify common patterns

JavaScript has always had compound assignment operators like += and *=, but the logical assignment operators take this concept to a new level by combining logical operations with assignment.

// User preferences with defaults
let userPrefs = {
  theme: 'light',
  notifications: false,
  // fontSize is not set
};

// Function to update preferences
function updatePreferences(newPrefs) {
  // Only set theme if it's not already set (nullish coalescing assignment)
  userPrefs.theme ??= newPrefs.theme;

  // Enable notifications if they're currently disabled (logical AND assignment)
  userPrefs.notifications &&= newPrefs.notifications;

  // Set fontSize if it's not set, or keep current value if it exists (nullish coalescing assignment)
  userPrefs.fontSize ??= newPrefs.fontSize;

  return userPrefs;
}

The three logical assignment operators are:

??= (nullish coalescing assignment): Assigns only if the left side is null or undefined
&&= (logical AND assignment): Assigns only if the left side is truthy
||= (logical OR assignment): Assigns only if the left side is falsy

These operators eliminate common patterns like x = x || y or if (x === null || x === undefined) x = y, making your code more concise and readable. They're particularly useful for setting default values, conditionally updating flags, and implementing short-circuit logic.

Top-level await that simplifies async module initialization

Asynchronous code has always been a bit awkward in JavaScript, especially when it comes to module initialization. Before top-level await, you had to use immediately invoked async functions or promise chains just to load data during module initialization. Now you can use await directly at the top level of a module.

// In a module file (e.g., dataService.js)

// Fetch configuration before module initialization
const config = await fetch('/api/config').then(res => res.json());

// Initialize database connection
const dbConnection = await initDatabase(config.dbUrl);

// Export initialized services
export const userService = new UserService(dbConnection);
export const productService = new ProductService(dbConnection, config.apiKeys);

This feature fundamentally changes how we structure applications. Modules can now handle their own initialization, and importers don't need to worry about whether a module is ready to use. The JavaScript runtime takes care of resolving all dependencies in the correct order.

Top-level await also enables dynamic module loading based on runtime conditions. You can fetch configuration, check feature flags, or perform authentication before deciding which modules to load. This level of flexibility was previously impossible without complex bootstrapping code.

Private class features that enable true encapsulation

JavaScript classes have always lacked true encapsulation. Developers resorted to naming conventions like _privateProperty or closures to hide implementation details, but these approaches were either not enforced or cumbersome. Private class features solve this problem elegantly.

class BankAccount {
  // Private fields
  #balance = 0;
  #transactions = [];
  #interestRate = 0.01;
  #accountNumber;

  constructor(initialDeposit, accountNumber) {
    this.#accountNumber = accountNumber;
    if (initialDeposit > 0) {
      this.deposit(initialDeposit);
    }
  }

  // Public methods
  deposit(amount) {
    if (amount <= 0) throw new Error('Deposit amount must be positive');
    this.#balance += amount;
    this.#addTransaction('deposit', amount);
    return this.balance;
  }

  // Private method
  #addTransaction(type, amount) {
    this.#transactions.push({
      type,
      amount,
      date: new Date(),
      balance: this.#balance
    });
  }

  // Getter for read-only access to private field
  get balance() {
    return this.#balance;
  }
}

The # prefix denotes private fields, methods, and accessors that are only accessible within the class itself. Any attempt to access these members from outside the class results in a syntax error, providing true encapsulation that's enforced by the language.

This feature transforms how we design classes in JavaScript. You can now clearly separate public API from implementation details, prevent external code from depending on internals, and refactor with confidence knowing that private members are truly private.

Atomics and SharedArrayBuffer for true parallelism

JavaScript has always been single-threaded, with Web Workers providing concurrency but not shared memory. Atomics and SharedArrayBuffer change this paradigm, enabling true parallel programming with shared memory.

// Create a shared buffer that can be accessed by multiple threads
const buffer = new SharedArrayBuffer(4); // 4 bytes
const view = new Int32Array(buffer); // View as a single 32-bit integer

// Initialize the value
view[0] = 0;

// Create a worker thread
const worker = new Worker('./atomic-worker.js');

// Send the shared buffer to the worker
worker.postMessage({ buffer });

// Increment the shared value 1000 times
for (let i = 0; i < 1000; i++) {
  // Atomically add 1 to the value at index 0
  Atomics.add(view, 0, 1);
}

The Atomics API provides operations that execute as a single, uninterruptible unit, preventing race conditions when multiple threads access shared memory. This enables high-performance parallel computing directly in the browser, opening up possibilities for applications that were previously impossible in JavaScript.

You can implement sophisticated synchronization primitives like mutexes, semaphores, and barriers using Atomics. This brings JavaScript closer to languages like Java and C++ in terms of parallel programming capabilities, while maintaining the safety guarantees that prevent common concurrency bugs.

JavaScript continues to surprise

JavaScript continues to surprise me, even after years of working with it daily. These features represent just a fraction of what modern JavaScript can do without external dependencies. By embracing these capabilities, we can write cleaner, more maintainable code while reducing our bundle sizes.

When we explore these kinds of native solutions at Lingo.dev, we often find they outperform the third-party alternatives we've relied on for years. There's something elegant about leveraging what the language itself provides rather than reaching for yet another package.

Next time you're about to install a utility library, take a moment to check if JavaScript already has what you need. You might be shocked by what you find.

Useful links:

Lingo.dev on Twitter/X - dev + fun;
GitHub repo - give it a star :)

HTML5 Elements You Didn't Know You Need

Max Prilutskiy — Wed, 21 May 2025 01:24:01 +0000

As you know, we love unusual tech at Lingo.dev. So when in my last essay, David commented he was surprised to not see "dialog" HTML element, it hit me - wait, but there's so many HTML5 elements that we don't even know about!

In our rush to embrace sophisticated frameworks and libraries, we've overlooked some of the most elegant solutions built right into HTML5. There's something beautiful about achieving with a single tag what might otherwise take dozens of lines of JavaScript.

The best code is often the code you don't have to write. How many times have you reached for a JavaScript library to create a modal window? Or written complex CSS for collapsible sections? What if I told you that HTML5 already has native elements for these exact purposes?

These aren't just any HTML elements - they're the ones that make you go "Wait, we could do that all along?" Let's explore eight surprisingly powerful HTML elements you probably aren't using - but absolutely should be.

1. The `<dialog>` Element: Native Modal Windows

Picture this: you're starting a new project and need to add a modal dialog. Your first instinct? Reach for React, grab a UI library, or write a bunch of JavaScript. I get it - I've done the same thing countless times.

But HTML5 has a built-in element specifically designed for this purpose:

<dialog id="myDialog">
  <h2>This is a Native Dialog</h2>
  <p>No JavaScript frameworks required!</p>
  <button id="closeDialog">Close</button>
</dialog>

<button id="openDialog">Open Dialog</button>

You still need a bit of JavaScript to handle the open/close actions:

const dialog = document.getElementById('myDialog');
document.getElementById('openDialog').addEventListener('click', () => {
  dialog.showModal(); // Makes the dialog appear as a modal
});
document.getElementById('closeDialog').addEventListener('click', () => {
  dialog.close(); // Closes the dialog
});

The browser handles focus management, backdrop rendering, and keyboard accessibility. Most developers I talk to have never used this element, despite it being supported in all major browsers since around 2022.

You can style it however you want:

dialog {
  padding: 20px;
  border-radius: 8px;
  border: 1px solid #ddd;
  box-shadow: 0 4px 8px rgba(0,0,0,0.1);
}

dialog::backdrop {
  background-color: rgba(0,0,0,0.6);
}

I've been using this in production for a couple of years now. The main gotcha is iOS Safari support, which was spotty until 2023, but it's solid now. For complex modals with lots of interactive elements, you might still want a dedicated library, but for most use cases, the native element works perfectly.

2. The `<details>` and `<summary>` Elements: Native Accordions

Accordions are everywhere on the web - FAQs, product details, settings panels. Most developers reach for a JavaScript solution, but HTML5 has native elements for this:

<details>
  <summary>Click to expand</summary>
  <p>This content can be expanded and collapsed without any JavaScript!</p>
</details>

That's all you need. The browser handles the toggle functionality, accessibility attributes, and keyboard navigation.

You can style it to match your design system:

details > summary {
  list-style: none; /* Removes the default triangle */
}

details > summary::before {
  content: '▶';
  display: inline-block;
  margin-right: 0.5em;
  transition: transform 0.2s;
}

details[open] > summary::before {
  transform: rotate(90deg);
}

These elements are particularly useful for nested navigation. I used them recently in a documentation site where we needed three levels of collapsible navigation:

<details>
  <summary>Programming Languages</summary>
  <details>
    <summary>Frontend</summary>
    <ul>
      <li>HTML</li>
      <li>CSS</li>
      <li>JavaScript</li>
    </ul>
  </details>
  <details>
    <summary>Backend</summary>
    <ul>
      <li>Python</li>
      <li>Java</li>
      <li>Ruby</li>
    </ul>
  </details>
</details>

The main limitation is animation - if you need smooth animations when opening/closing, you'll need to add JavaScript. But for many use cases, the default behavior is perfectly fine.

3. The `<datalist>` Element: Native Autocomplete

Autocomplete functionality is a staple of modern web forms. Most developers reach for a third-party solution, but HTML5 has a built-in element for this:

<input list="browsers" name="browser" placeholder="Choose a browser">
<datalist id="browsers">
  <option value="Chrome">
  <option value="Firefox">
  <option value="Safari">
  <option value="Edge">
</datalist>

This gives you a text input that shows suggestions as you type, with the ability to select from the list or enter custom text.

One interesting use case is creating a color picker with named colors:

<input type="text" list="colors" placeholder="Choose a color">
<datalist id="colors">
  <option value="#FF0000">Red</option>
  <option value="#00FF00">Green</option>
  <option value="#0000FF">Blue</option>
</datalist>

The user can either type a color name or a hex code. Add a bit of JavaScript to show a preview:

const input = document.querySelector('input');
const preview = document.getElementById('colorPreview');

input.addEventListener('input', () => {
  preview.style.backgroundColor = input.value;
});

The main limitation of <datalist> is styling - you can't easily customize the appearance of the dropdown options. If you need custom styling for the suggestions, you might still need a JavaScript solution. But for many use cases, the native element is perfectly adequate.

4. The `<meter>` Element: Semantic Measurement Display

When displaying values within a known range, most developers use a div with a background color. But HTML5 has a dedicated element for this:

<meter value="75" min="0" max="100" low="30" high="70" optimum="80"></meter>

The browser styles it based on the thresholds you set. If the value is in the "low" range, it might show as yellow. If it's in the "high" range, it might show as orange. And if it's near the "optimum" value, it shows as green.

This is particularly useful for dashboards:

<!-- Disk usage (lower is better) -->
<meter value="75" min="0" max="100" low="70" high="90" optimum="0">75%</meter>

<!-- Battery level (higher is better) -->
<meter value="35" min="0" max="100" low="20" high="60" optimum="100">35%</meter>

<!-- CPU usage (lower is better) -->
<meter value="82" min="0" max="100" low="60" high="80" optimum="0">82%</meter>

The optimum attribute indicates whether higher or lower values are better, which affects the color.

Browser support is good, but styling options are limited. If you need a highly customized appearance, you might still need a custom solution. But for dashboards and monitoring UIs, the native element works well and communicates semantic meaning to screen readers.

5. The `<output>` Element: Dynamic Calculation Results

When building calculators or interactive forms, most developers use a div to show the result. But HTML5 has a dedicated element for this:

<form oninput="result.value = parseInt(a.value) + parseInt(b.value)">
  <input type="number" id="a" value="0"> +
  <input type="number" id="b" value="0"> =
  <output name="result" for="a b">0</output>
</form>

The for attribute creates an explicit relationship between the inputs and the output, which helps screen readers understand that the output is a result of those specific inputs.

I used this in a side-project last year for a mortgage calculator:

<form
  oninput="
  const P = principal.valueAsNumber,
        r = (rate.valueAsNumber/100)/12,
        n = term.valueAsNumber*12,
        m = r ? (P*r)/(1-Math.pow(1+r,-n)) : P/n;
  payment.value        = m.toFixed(2);
  totalInterest.value  = (m*n - P).toFixed(2);
"
>
  <input id="principal" type="number" value="200000" />
  <input id="rate" type="number" value="3.5" step="0.1" />
  <input id="term" type="number" value="30" />
  Payment $<output id="payment" for="principal rate term">0.00</output> Interest
  $<output id="totalInterest" for="principal rate term">0.00</output>
</form>

The main advantage is semantic meaning - screen readers can announce that the value is a calculation result. It's also a form element, so it can be included in form submissions if needed.

6. The `<mark>` Element: Semantic Highlighting

When highlighting text, most developers use a span with a background color. But HTML5 has a dedicated element for this:

<p>The <mark>quick brown fox</mark> jumps over the lazy dog.</p>

By default, browsers style it with a yellow background, but you can customize it:

mark {
  background-color: #fff9c4;
  padding: 2px 4px;
  border-radius: 3px;
}

This is particularly useful for search results:

const searchTerm = "HTML";
const content = "HTML elements are the building blocks of HTML pages.";

const highlighted = content.replace(
  new RegExp(searchTerm, 'gi'),
  match => `<mark>${match}</mark>`
);

The advantage is semantic meaning - screen readers can announce that text is highlighted, giving users a better understanding of why certain text stands out.

I've found this especially useful in documentation sites and knowledge bases, where highlighting search terms helps users quickly find what they're looking for.

7. The `<time>` Element: Semantic Dates and Times

Most developers display dates and times using regular text elements, but HTML5 has a dedicated element for this:

<p>The article was published on <time datetime="2025-05-20">May 20, 2025</time>.</p>

The datetime attribute allows you to specify the date in a standardized format (ISO 8601) that machines can understand, while displaying a human-friendly format to users.

This is useful for search engines, which can extract the exact date, and for browsers or extensions that might want to offer features like adding events to calendars.

You can use it for various date and time formats:

<!-- Just a date -->
<time datetime="2025-05-20">May 20, 2025</time>

<!-- Date and time -->
<time datetime="2025-05-20T14:30:00">2:30 PM on May 20, 2025</time>

<!-- Just a time -->
<time datetime="14:30:00">2:30 PM</time>

<!-- A duration -->
<time datetime="PT2H30M">2 hours and 30 minutes</time>

One practical application is for relative times:

<p>Posted <time datetime="2025-05-18T14:30:00" class="relative-time">2 days ago</time></p>

With JavaScript, you can update these periodically:

function updateRelativeTimes() {
  document.querySelectorAll('.relative-time').forEach(el => {
    const date = new Date(el.getAttribute('datetime'));
    el.textContent = getRelativeTimeString(date);
  });
}

// Update every minute
setInterval(updateRelativeTimes, 60000);

This element is particularly valuable for blogs, news sites, and social media platforms, where accurate date and time information is important.

8. The `<figure>` and `<figcaption>` Elements: Semantic Image Captions

Most developers implement image captions with divs and paragraphs, but HTML5 has dedicated elements for this:

<figure>
  <img src="chart.jpg" alt="Sales chart for Q2 2025">
  <figcaption>Fig.1 - Company sales increased by 25% in Q2 2025.</figcaption>
</figure>

The <figure> element isn't just for images - it can be used for any content that is referenced as a single unit:

<!-- Code snippet with caption -->
<figure>
  <pre><code>
function greet(name) {
  return `Hello, ${name}!`;
}
  </code></pre>
  <figcaption>A simple JavaScript greeting function using template literals.</figcaption>
</figure>

<!-- Quote with attribution -->
<figure>
  <blockquote>
    <p>The best way to predict the future is to invent it.</p>
  </blockquote>
  <figcaption>— Alan Kay</figcaption>
</figure>

These elements are particularly useful for content management systems and blogs, where editors need to add captions to images and other media.

A simple CSS setup can create a nice-looking gallery:

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 20px;
}

figure {
  margin: 0;
  border-radius: 8px;
  overflow: hidden;
  box-shadow: 0 2px 5px rgba(0,0,0,0.1);
  transition: transform 0.3s;
}

figure:hover {
  transform: translateY(-5px);
}

figure img {
  width: 100%;
  height: 200px;
  object-fit: cover;
  display: block;
}

figcaption {
  padding: 10px;
  background-color: #f5f5f5;
  font-style: italic;
}

The main advantage is semantic meaning - screen readers can announce that the text is a caption for the associated content, improving accessibility.

Conclusion?

Embrace the Power of Native HTML.

We've explored eight HTML5 elements that offer elegant, built-in solutions to common web development challenges:

<dialog> for native modal windows
<details> and <summary> for collapsible content
<datalist> for native autocomplete
<meter> for semantic measurement display
<output> for dynamic calculation results
<mark> for semantic highlighting
<time> for semantic dates and times
<figure> and <figcaption> for semantic image captions

These elements reduce dependency on JavaScript, improve accessibility, and make your HTML more semantic and meaningful.

They're not perfect for every use case - building Lingo.dev oftentimes requires more customization or browser support than they can provide. But they're worth considering before reaching for a third-party solution.

What other HTML elements have you found useful in your projects? Let me know in the comments!

Useful links:

Lingo.dev on Twitter/X - dev + fun;
GitHub repo - give it a star :)
Discord - users told we need a Discord, so we created one 👀

Creating Modal Windows with Pure CSS: No JavaScript Required

Max Prilutskiy — Sat, 17 May 2025 02:29:43 +0000

Wait, you can build modal windows without JavaScript? Yep, that's CSS secretly laughing at JavaScript behind its back. At Lingo.dev, we love diving into weird engineering rabbit holes that make other devs do a double-take.

Most developers wouldn't even think twice before reaching for a JavaScript library when they need a modal. But what if I told you there's this bizarre, oddball alternative hiding in plain sight? Pure CSS can pull off some surprisingly sneaky tricks that'll make you question everything you thought you knew about frontend development.

In this tutorial, we'll explore how to create fully functional modal windows using nothing but HTML and CSS. You can use it for fun, or in production. We'll be pushing CSS to do things it probably wasn't designed for, and that's exactly what makes this approach so deliciously unusual.

So, let's dive in!

Understanding the Modal Window Challenge

Modal windows are those overlay elements that pop up on top of your main content, usually demanding some kind of interaction before you can get back to what you were doing. You've seen them everywhere – login forms, image galleries, notifications, those annoying "SUBSCRIBE TO OUR NEWSLETTER" popups (though let's build less annoying ones, shall we?).

Traditionally, modals need JavaScript for three main things:

Showing the modal when triggered
Hiding the modal when dismissed
Managing focus and keyboard interactions

So here's our challenge: how do we handle these state changes without JavaScript?

The answer comes from two clever CSS techniques that leverage built-in browser behaviors to create interactivity: the :target pseudo-class and what's affectionately known as the "checkbox hack."

The CSS Building Blocks

Before we start coding, let's get our heads around the core CSS concepts that make JavaScript-free modals possible.

The :target Pseudo-class

The :target pseudo-class is triggered when an element's ID matches the URL's hash fragment. In plain English? If your URL ends with #modal, any element with id="modal" will match the :target selector.

This gives us a way to change styles based on navigation state, which is perfect for showing and hiding modals. When someone clicks a link pointing to #modal, the browser navigates to that fragment, and we can use CSS to make the modal visible.

/* Hidden by default */
.modal {
  opacity: 0;
  pointer-events: none;
}

/* Visible when targeted */
.modal:target {
  opacity: 1;
  pointer-events: auto;
}

The Checkbox Hack

The checkbox hack uses a hidden checkbox input and the :checked pseudo-class to toggle states. By connecting a label to the checkbox, we can create clickable elements that toggle the checkbox's state without JavaScript.

/* Hidden by default */
.modal {
  opacity: 0;
  pointer-events: none;
}

/* Visible when checkbox is checked */
.modal-checkbox:checked ~ .modal {
  opacity: 1;
  pointer-events: auto;
}

Essential CSS Properties

Both techniques rely on several key CSS properties:

Position: fixed - This takes the modal out of the document flow and positions it relative to the viewport, allowing it to overlay the entire page.
Opacity & pointer-events - These control visibility and interaction. Setting pointer-events: none prevents the hidden modal from blocking clicks on elements beneath it.
z-index - Ensures the modal appears above other content.
Transitions - Adds smooth animations when showing and hiding the modal.

Now that we understand the building blocks, let's implement our first modal.

Building a Basic CSS Modal with :target

The :target approach is the simplest way to create a CSS-only modal. It requires minimal HTML and CSS, making it perfect for quick implementations.

Here's how it works:

We create a link that points to the modal's ID
When clicked, the browser navigates to that fragment
The :target selector applies styles to make the modal visible
Another link with an empty fragment (href="#") closes the modal

Let's build it step by step:

HTML Structure

<!-- Modal trigger button -->
<a href="#modal-example" class="modal-trigger">Open Modal</a>

<!-- Modal container -->
<div id="modal-example" class="modal">
    <!-- Backdrop for closing the modal when clicking outside -->
    <a href="#" class="modal-backdrop"></a>

    <!-- Modal content -->
    <div class="modal-content">
        <h2>Welcome to the Modal!</h2>
        <p>This modal window is created using only HTML and CSS!</p>
        <a href="#" class="modal-close">Close Modal</a>
    </div>
</div>

CSS Implementation

/* Modal container - hidden by default */
.modal {
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    background-color: rgba(0, 0, 0, 0.6);
    opacity: 0;
    pointer-events: none;
    transition: opacity 0.3s ease;

    /* Center the modal content */
    display: flex;
    align-items: center;
    justify-content: center;
    z-index: 100;
}

/* When the modal is targeted via URL hash, make it visible */
.modal:target {
    opacity: 1;
    pointer-events: auto;
}

/* Modal content box */
.modal-content {
    background-color: white;
    padding: 2rem;
    border-radius: 6px;
    width: 90%;
    max-width: 500px;
    max-height: 90vh;
    overflow-y: auto;
    box-shadow: 0 5px 30px rgba(0, 0, 0, 0.2);
}

/* Backdrop close link - covers the entire screen */
.modal-backdrop {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    cursor: default;
    z-index: -1; /* Place behind modal content */
}

Complete Working Example

For a fully functional implementation of this approach, check out our first example. This example includes:

A clean, minimal design
Smooth fade-in/out transitions
The ability to close the modal by clicking outside it
Responsive behavior for all screen sizes

This implementation creates a modal that:

Appears when you click the "Open Modal" link
Can be closed by clicking the close button or anywhere outside the modal
Animates smoothly with a fade effect
Is centered on the screen with a semi-transparent backdrop

The beauty of this approach is its simplicity. With just a few lines of HTML and CSS, we've created a functional modal without a single line of JavaScript.

However, the :target method does have some limitations. The most notable is that it changes the URL by adding a hash fragment, which affects browser history. Each time you open and close the modal, a new entry is added to the browser's history, meaning users might need to click the back button multiple times to navigate away from the page.

For applications where this behavior is problematic, the checkbox hack offers an alternative.

The Checkbox Hack Alternative

The checkbox hack avoids URL changes by using a hidden checkbox input to track the modal's state. Here's how it works:

A hidden checkbox controls the modal's visibility
A label linked to the checkbox serves as the open button
Another label linked to the same checkbox serves as the close button
CSS selectors use the checkbox's :checked state to show or hide the modal

Let's implement this approach:

HTML Structure

<!-- Hidden checkbox for controlling modal state -->
<input type="checkbox" id="modal-toggle" class="modal-checkbox">

<!-- Modal trigger button (label for the checkbox) -->
<label for="modal-toggle" class="modal-trigger">Open Modal</label>

<!-- Modal container -->
<div class="modal">
    <!-- Modal content -->
    <div class="modal-content">
        <h2>Welcome to the Modal!</h2>
        <p>This modal window uses the checkbox hack!</p>

        <!-- Close button (another label for the same checkbox) -->
        <label for="modal-toggle" class="modal-close">Close Modal</label>
    </div>
</div>

CSS Implementation

/* Hide the checkbox input */
.modal-checkbox {
    display: none;
}

/* Modal container - hidden by default */
.modal {
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    background-color: rgba(0, 0, 0, 0.6);
    opacity: 0;
    pointer-events: none;
    transition: opacity 0.3s ease;

    /* Center the modal content */
    display: flex;
    align-items: center;
    justify-content: center;
    z-index: 100;
}

/* When the checkbox is checked, make the modal visible */
.modal-checkbox:checked ~ .modal {
    opacity: 1;
    pointer-events: auto;
}

Complete Working Example

For a fully functional implementation of the checkbox hack, check out our second example. This example includes:

A clean, modern design with a different color scheme
Scale animation for the modal content
No URL changes when opening/closing the modal
Responsive behavior for all screen sizes

The checkbox hack offers several advantages over the :target method:

No URL changes or browser history entries
More control over the modal's behavior
Ability to create more complex interactions

However, it does require more HTML elements and careful consideration for accessibility. Without proper ARIA attributes, screen readers might not understand the relationship between the checkbox and the modal.

Enhancing Your Modal with Animations

Now that we have the basic functionality working, let's add some visual polish with CSS animations. Animations make the modal feel more responsive and provide visual cues about what's happening.

Here's how to add a simple entrance animation to our checkbox modal:

/* Modal content box with animation */
.modal-content {
    background-color: white;
    padding: 2rem;
    border-radius: 6px;
    width: 90%;
    max-width: 500px;

    /* Initial state - scaled down */
    transform: scale(0.8);
    transition: transform 0.3s ease;
}

/* Animate to full size when visible */
.modal-checkbox:checked ~ .modal .modal-content {
    transform: scale(1);
}

This creates a subtle "pop" effect as the modal appears. You can get creative with different animation styles:

Slide-in Animation

.modal-content {
    /* Initial state - off-screen */
    transform: translateY(-50px);
    transition: transform 0.3s ease;
}

.modal-checkbox:checked ~ .modal .modal-content {
    transform: translateY(0);
}

Fade-and-scale Animation

.modal-content {
    /* Initial state - transparent and small */
    opacity: 0;
    transform: scale(0.9);
    transition: all 0.3s ease;
}

.modal-checkbox:checked ~ .modal .modal-content {
    opacity: 1;
    transform: scale(1);
}

Making Your Modal Responsive

For a truly polished modal, we need to ensure it works well on all device sizes. Here are some responsive design considerations:

/* Base styles for the modal content */
.modal-content {
    width: 90%;
    max-width: 500px;
    padding: 2rem;
}

/* Adjustments for small screens */
@media (max-width: 600px) {
    .modal-content {
        width: 95%;
        padding: 1.5rem;
    }

    /* Smaller text on mobile */
    .modal-content h2 {
        font-size: 1.5rem;
    }
}

These adjustments ensure the modal remains usable on mobile devices, where screen real estate is limited.

Accessibility Considerations

While CSS-only modals are impressive, they do have accessibility limitations compared to JavaScript implementations. Here are some ways to improve accessibility:

ARIA attributes - Add role="dialog" and aria-modal="true" to the modal container.
Focus management - This is challenging without JavaScript, but you can use the :focus-within pseudo-class to style the modal when it contains focused elements.
Keyboard navigation - Ensure all interactive elements are tabbable and that the modal can be closed with keyboard actions.

<div class="modal" role="dialog" aria-modal="true" aria-labelledby="modal-title">
    <div class="modal-content">
        <h2 id="modal-title">Accessible Modal Title</h2>
        <!-- Modal content -->
    </div>
</div>

Real-world Applications

CSS-only modals are unusual, however, they are perfect for several use cases:

Image galleries - Click a thumbnail to show a larger version in a modal.
Simple forms - Newsletter signups, contact forms, or login dialogs.
Notifications and alerts - Display important messages to users.
Content previews - Show a preview of content before navigating to a full page.

For more complex interactions, such as multi-step forms or modals that need to communicate with a server, you'll likely need JavaScript. But for many common use cases, CSS-only modals provide a lightweight, performant solution.

Browser Compatibility

The techniques we've covered work in all modern browsers. The :target pseudo-class has been supported since IE9, and the checkbox hack works in all browsers that support CSS3 selectors.

However, there are some edge cases to be aware of:

Mobile browsers might handle the :target selector differently, especially regarding the back button behavior.
Older browsers might not support some CSS features like flexbox or transitions.

Always test your modals across different browsers and devices to ensure consistent behavior.

Conclusion

Creating modal windows with pure CSS demonstrates the surprising power of modern CSS. It's pretty cool and unusual, that we can leverage the :target pseudo-class or the checkbox hack, to create interactive components that traditionally required JavaScript.

If you're open to using a bit of CSS, the benefits of this approach are clear:

Faster loading times (no JavaScript to download and parse)
Better reliability (works even when JavaScript fails)
Simpler maintenance (fewer moving parts)

While CSS-only modals do have limitations, particularly around complex interactions and accessibility, they're a valuable tool in any developer's toolkit. For many common use cases, they provide an elegant, lightweight solution that challenges our assumptions about what's possible with CSS alone.

Next time you need a simple modal, consider whether you really need JavaScript, or if CSS might be all you need. You might be surprised by how much you can accomplish with a few clever CSS tricks. ;)

Useful links:

Also:

Our dev memes on X

Llama 4: Breaking Down Meta's Latest Powerhouse Model

Max Prilutskiy — Sun, 06 Apr 2025 03:18:08 +0000

At lingo.dev, we're always on top of the latest models to ensure our translations are perfect. So when Meta released Llama 4, I immediately dug into what makes it special and how we developers can leverage its power without the infrastructure headaches.

What Makes Llama 4 a Game-Changer?

As a developer who's seen plenty of "revolutionary" AI models come and go, I approached Llama 4 with healthy skepticism. But after spending time with it, I'm genuinely impressed by several key innovations:

Mixture of Experts Architecture: Intelligence Without the Bloat

Llama 4 introduces a fascinating Mixture of Experts (MoE) architecture that's worth unpacking. The Llama 4 lineup includes two models:

Llama 4 Scout: 109B total parameters but only 17B active parameters with 16 experts
Llama 4 Maverick: A massive 400B total parameters with 17B active parameters and 128 experts

What's fascinating is how this architecture works. Unlike traditional monolithic models, MoE models consist of specialized neural networks (the "experts") with a "router" component that directs incoming tokens to the appropriate experts.

Here's what makes this impressive: when you ask Llama 4 to write code, it activates the coding experts while leaving the others dormant. This means you get specialized performance without the full computational load of a 109B parameter model. In practical terms: faster responses that remain highly intelligent.

Massive Context Window

Llama 4 Scout supports a context window of up to 10 million tokens - one of the first open models with this capability. While Cloudflare currently supports 131,000 tokens (still substantial), they're working to increase this limit.

For developers, this means:

Processing entire codebases for analysis
Summarizing multiple documents in one go
Maintaining longer, more coherent conversations with context
Building more sophisticated RAG (Retrieval Augmented Generation) systems

Native Multimodality with Early-Fusion

Unlike Llama 3.2, which used separate parameters for text and vision, Llama 4 uses an early-fusion architecture where all parameters natively understand both text and images.

This is a significant architectural improvement - previous multimodal approaches required chaining separate models together. With Llama 4, it's all integrated, making multimodal applications simpler to build and more coherent in execution.

Getting Started with Llama 4 on Cloudflare

The most exciting part for developers: you don't need to provision expensive GPU clusters or manage complex infrastructure. Cloudflare handles all that through their Workers AI platform.

Let's dive into implementation with three different approaches:

Approach 1: Using the REST API

For quick testing or language-agnostic applications:

curl --request POST \
  --url https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/meta/llama-4-scout \
  --header 'Authorization: Bearer {API_token}' \
  --header 'Content-Type: application/json' \
  --data '{
    "messages": [
      {
        "role": "system",
        "content": "You are a helpful AI assistant."
      },
      {
        "role": "user", 
        "content": "What makes Mixture of Experts models efficient?"
      }
    ]
  }'

You'll need to get your Account ID and API token first, which you can obtain from the Cloudflare dashboard under AI > Workers AI > Use REST API.

Approach 2: Using Workers & Wrangler

For a more integrated serverless approach, you can use Cloudflare Workers:

Create a new Worker project:

npm create cloudflare@latest

Add the AI binding to your wrangler.json:

{
  "name": "llama4-demo",
  "main": "src/index.js",
  "compatibility_date": "2023-10-30",
  "ai": {
    "binding": "AI"
  }
}

Implement the Worker in src/index.js:

export default {
  async fetch(request, env) {
    const response = await env.AI.run('@cf/meta/llama-4-scout', {
      messages: [
        { role: "system", content: "You are a helpful AI assistant." },
        { role: "user", content: "Explain MoE architecture in simple terms." }
      ]
    });

    return new Response(JSON.stringify(response), {
      headers: { 'content-type': 'application/json' }
    });
  }
};

Deploy with npx wrangler deploy

Approach 3: Building a RAG System

One of the most powerful applications of Llama 4 is building a Retrieval Augmented Generation system, which can leverage that massive context window:

export default {
  async fetch(request, env) {
    // Retrieve documents from your database
    const documents = await getRelevantDocuments(request);

    // Prepare prompt with retrieved documents
    const documentsText = documents.map(doc =&gt; doc.content).join("\n\n");

    const response = await env.AI.run('@cf/meta/llama-4-scout', {
      messages: [
        { role: "system", content: "You are a helpful AI assistant." },
        { role: "user", content: `Based on these documents:\n\n${documentsText}\n\nAnswer: What are the key insights?` }
      ]
    });

    return new Response(JSON.stringify(response), {
      headers: { 'content-type': 'application/json' }
    });
  }
};

For a complete RAG tutorial, check out Cloudflare's documentation on building RAG systems.

My Opinion

My natural skepticism led me to thoroughly test Llama 4 against its predecessors and alternatives. Here are my honest observations:

Performance vs. Resource Efficiency: The MoE architecture delivers on its promise. Response times are noticeably faster than comparable models, especially for specialized tasks where only a few experts activate.
Context Window Reality Check: While 10 million tokens is the theoretical limit, Cloudflare's current implementation supports 131,000 tokens. This is still impressive compared to many alternatives, but know the practical limitations.
Multimodal Capabilities: Early-fusion multimodality works surprisingly well. Image understanding is more coherent and contextually relevant than with previous approaches that bolted vision capabilities onto text models.
Open Source Benefits: Unlike closed models, you can run Llama 4 on your own infrastructure if needed, though Cloudflare's serverless approach removes much of this complexity.

Compared to Previous Models

Having worked extensively with Llama 3.1/3.2, the improvements in Llama 4 are substantial:

Architecture: The shift to MoE from a monolithic architecture is the most significant change, providing better performance with more efficient resource utilization.
Multimodality: Llama 3.2 had vision capabilities but used separate parameters. Llama 4's early-fusion approach provides more coherent multimodal reasoning.
Context Window: From 8K tokens in early Llama models to potentially 10M tokens is a quantum leap that enables entirely new application categories.

Building Production Applications

For those ready to build real applications with Llama 4, consider:

OpenAI API Compatibility: The openai-cf-workers-ai project provides OpenAI API compatibility, allowing you to use existing OpenAI SDK code with Llama 4.
Integration with Other Tools: Llama 4 integrates smoothly with tools like n8n for workflow automation and continue.dev for code assistance.
Vision Applications: For multimodal applications, you can follow similar patterns to the Llama 3.2 vision tutorial, adapting for Llama 4's unified architecture.

Conclusion

Llama 4 represents a genuine advancement in open-source AI model architecture, and Cloudflare's implementation makes it accessible without the usual infrastructure headaches. The MoE architecture combined with early-fusion multimodality creates a model that's not just more efficient, but qualitatively better for many applications.

As a developer who's seen many "revolutionary" models come and go, I'm genuinely impressed with what Meta and Cloudflare have delivered here. The serverless approach removes traditional barriers to advanced AI implementation, making these capabilities available to developers of all sizes.

Have you tried Llama 4 yet? What applications are you building with it? Share your experiences in the comments!

Resources:

About the Author

My name is Max, and I'm working on Lingo.dev. At Lingo.dev, we're building open-source libraries + cloud translation APIs, that enable dev teams ship web and mobile apps in tens of languages, with accurate translations, in minutes instead of weeks. Sign up on Lingo.dev, or follow me on X.

We just raised $4.2 to keep building our hackathon project!

Max Prilutskiy — Wed, 19 Feb 2025 16:02:21 +0000

Back in December 2023, our plane almost flew through an Icelandic volcano on the way to Cornell hackathon: we missed it by just days.

Back then, we had no idea we were about to build something that would change how developers ship multilingual products. We were just two engineers tired of waiting weeks for translations.

Our hackathon prototype was rough - a ChatGPT wrapper that could translate JSON files. But when other developers saw it, their eyes lit up. They had the same pain. We ended up winning in two categories.

Today, Lingo.dev turns translation work into automated pull requests:

Git-native UI localization with automated PRs and Human-in-the-loop
Open-source CLI for web/mobile teams
Real-time API for dynamic content
Context-aware AI that understands product terminology
Built-in support for 80+ languages

Just like Dependabot automated package updates, we're automating localization. What started as a weekend project is now loved by both solo hackers and enterprise teams shipping multilingual products.

The most rewarding part? Seeing developers' reactions when their apps start speaking new languages automatically. One founder told us we saved them months of manual work. Another team shipped their product in 12 new languages within days.

The internet is wild. You can just... build things! A weekend project can turn into infrastructure that helps developers reach users in every corner of the planet. Sometimes the scariest flights lead to the best destinations.

That's why we build. That's why we ship. And we're just getting started.

We're LIVE on ProductHunt today, please support!
https://www.producthunt.com/posts/lingodotdev

This is pretty cool!

Max Prilutskiy — Wed, 29 Jan 2025 15:56:36 +0000

Building Cross-Platform CI/CD Actions with Docker

Matej Lednický ・ Jan 29

#github #javascript #docker #typescript

We got 500 GitHub stars! 🤯 What's next?

Max Prilutskiy — Mon, 08 Apr 2024 05:38:37 +0000

"What if we built a tool that's just cool, useful, and fun to work on?" we thought to ourselves after our bootstrapped, profitable B2B side project was acquired.

"What if we build a compiler?.."

The problem

Here's a counterintuitive fact we learned: ~80% of the world doesn't speak English.

Does that mean most of the Internet users can't use the side-projects we build?

That's A LOT of people!

Shouldn't we be building multi-language apps by default, from day one, then?!

What if?

I18n always was a huge headache. Extracting text, managing JSON files, writing custom sync scripts, asking a native-speaking teammate to double-check the translations...

Over the past few years, I've built hundreds of React apps: both at work and for side projects. I used tens of i18n libraries out there (react-intl <3), but none of them was a perfect match.

But what if we could build an i18n tool that wouldn't require touching JSX at all, while also using specially purposed AI for translation, right during the build?

Wouldn't that be cool?

It's called Replexica

My co-author Veronica comes from the Data Science + AI background. I've been using React since its first release and have built a compiler for a made-up programming language in the past, for fun (don't ask 😅).

And we both love building stuff!

So, we built Replexica: an AI-powered i18n engine for React.

It comes in two parts:

Replexica Compiler - a plugin for React compiler.

Long story short - Replexica Compiler traverses the Abstract Syntax Tree (AST) of the React app and infers metadata + text that needs to be translated.

It can't do everything just yet, though with Next.js App Router it works well, and we aim to release the Pages Router support by the end of the month.
Replexica Cloud - an AI-powered engine in the cloud to perform translations.

The Cloud engine uses a combination of open-source + proprietary AI models. Think Llama + Google Vertex AI + GPT + Mixtral, wired together to translate the app, fully aware of the app's purpose and domain, and the more it's used, the better it gets.

The API spec is open, so anyone could build their own translation engine (self-hosting guide coming soon!).

Bonus

We made Replexica support legacy i18n approach too: you can setup Replexica to use your existing i18n JSON or YAML files, and it will manage them for you, on autopilot.

Now - on to the technical stuff.

Replexica Compiler 101

We thought it'd be really cool to show a quick TLDR of the first version of the compiler API.

Basically, it plugs into the React compilation process, and the rest of the React code remains untouched:

// next.config.mjs

// Import Replexica Compiler
import replexica from '@replexica/compiler';

// Configure Replexica Compiler
const replexicaConfig = {
  locale: {
    source: 'en',
    targets: ['es'],
  },
};

// Existing Next.js config
const nextConfig = {};

// Export the Next.js config
export default replexica.next(
  replexicaConfig,
  nextConfig,
);

That's it! (unless you use 'use client' components, if so - check out the docs).

We've been working on Replexica for the past several months, but some parts are still complex, and we're working on simplifying them. For example, the Next.js Pages Router is still in the works, and we're adding support for Remix and Create React App soon in May.

In terms of the Cloud, we're adding 2 more languages in April and hoping to add 10 more by the end of the year!

Progress

We've built the first version and showed it to several people. Most of them liked it, and some of them shared it with their friends. And some of them likely posted it elsewhere also...

... and now we're sitting on 500 GitHub stars! Adding 20-50 stars a day, and we're panicking a bit about what we should do next! 😅

For some, 500 stars might not seem like a big deal. React has 221,000 stars, for example.

But hey, for us, 500 is a lot – we thought we'd get 10!

What's next

What do we do next? You tell us!

At this point, we're excited to see where this project goes, and we're super hungry for feedback.

Right now, we're working on the Next.js Pages Router, and we're adding support for Remix and Create React App soon in May, as well as adding more languages to the Cloud.

We're also working on the docs!

Thank you! ❤️

And that's about it.

We're incredibly happy with the result. Our batteries are charged to the full with the community support, and we ready to ship more! 😎

We want to give every side-project a disproportionate advantage: to unlock instant i18n, hence much wider reach.

If you want to contribute, report a bug, or just hang out with us, drop by our new Discord channel to say hi.

... and don't forget to star Replexica 🌟 on GitHub! 😉

How We Reduced JS Deployment Time by x25 Times

Max Prilutskiy — Wed, 17 May 2023 09:19:44 +0000

Imagine slashing your CI/CD pipeline time from 26 minutes down to a mere 1 minute.

Sounds like a dream, right?

Well, I've been there and done that at Notionlytics. All it took was a series of performance optimizations and some creative thinking.

So, let's dive in and explore the techniques I used to achieve this remarkable improvement.

Switching Gears

Pnpm

First things first, I made two crucial infrastructure changes. I bid farewell to Yarn and embraced pnpm, the package manager known for its speed and efficiency. With its three-stage installation process, pnpm swiftly handled dependency resolution, directory structure calculation, and linking dependencies.

The outcome?

Significant improvements in installation times.

Turborepo

Moving on, I swapped NX with Turborepo for managing monorepos. Turborepo's caching tasks proved invaluable for storing results and logs of various scripts like build, test, and lint. Additionally, its parallel task execution significantly reduced build times.

NX is undoubtedly impressive, and truth be told—I became quite accustomed to it. Nevertheless, it's time to progress: Turborepo offers a simpler approach and feels much faster.

Cache Me If You Can

Pnpm

To maximize performance gains, I incorporated caching into our CI workflow.

By utilizing the actions/cache action action, we implemented a strategy to store and retrieve dependencies, preventing redundant installations.

Here's how it was done:

      - name: Configure pnpm cache
        id: pnpm-cache
        run: echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
      - uses: actions/cache@v3
        with:
          path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

Turborepo

Now for the exciting part: Turborepo caching. Firstly, the advantage lies in Turborepo's ability to remember the output after an initial build. Subsequent builds only rebuild what has changed.

But wait, there's more!

Turborepo also offers a Turborepo remote caching feature, allowing us to preserve build outputs between CI builds.

While Vercel serves as Turbo's default remote caching destination, I stumbled upon a remarkable find: setup-github-actions-caching-for-turbo - a GitHub Action that enables caching of build artifacts within GitHub Actions itself, without any additional cost!

Here's how to set it up:

      - name: Configure Turbo cache
        uses: dtinth/setup-github-actions-caching-for-turbo@v1

It's as simple as that. The setup is hassle-free, and it works seamlessly.

Deployments

Cloudflare Pages

Deployments are critical moments in the CI/CD pipeline, so I optimized this stage by transitioning from Vercel hosting to Cloudflare Pages.

Cloudflare Pages emerged as the clear winner due to its parallel deployments using the wrangler CLI, provision of forever-free static asset hosting, and lightning-fast file hashing.

One notable advantage is that the CLI used for deploying to Cloudflare automatically performs hash-checks on assets. This means that if you utilize code-splitting, only the changed chunks will be uploaded, resulting in faster deployments.

Semantic Release

To further streamline deployments, I introduced semantic-release. This tool automates commit tagging and tracks changes since the previous version. As a result, deployments now occur only when new tags are present, saving us valuable minutes.

The benchmark

So, let's talk numbers.

Initially, the monorepo comprising static Next.js sites, a React CRA app, and a Node.js API had a staggering CI/CD pipeline duration of 26 minutes and 49 seconds, regardless of the code changes. As the project grew, this time only increased.

However, after implementing all the performance optimizations, here are the results we achieved:

Without cache: 12 minutes and 6 seconds (a remarkable 50% reduction!)
With cache:
Node.js: 7 minutes and 1 second (still relatively slow due to building and pushing a Docker image)
React CRA app: 3 minutes and 22 seconds
Next.js app: 1 minute and 19 seconds
Infrastructure/docs/chore changes: just 1 minute and 2 seconds

I'd say those are some pretty good improvements: not only did we slash our CI/CD pipeline duration by more than half, but we now have a much faster response time for changes in any one part of the monorepo. We can now deliver features and bug fixes to production much faster, with much less stress.

Thanks for reading!

What are your thoughts on these outcomes? Any tips you want to share? Let's continue the conversation in the comments below.

P.S.: If you liked this - you might like some other things I've done recently:

AI-powered changelog updates on Slack, every Monday, with GitHub Actions

You'll never have to deal with outdated TODO comments again

Follow me on Twitter: @MaxPrilutskiy

DEV Community: Max Prilutskiy

Hidden Classes: The JavaScript performance secret that changed everything

What Are Hidden Classes, Really?

The Shape-Shifting Magic

Performance: The Numbers That Matter

Common Pitfalls That Murder Performance

The Delete Disaster

The Order Chaos

The Dynamic Property Trap

The Art of Monomorphic Code

Constructor Pattern

Object Pool Pattern

Array Processing Pattern

Bonus: Peeking Under the Hood with V8 Flags

The Performance Transformation

Conclusion

[Boost]

21 native browser APIs you might not have used before

Introducing Lingo.dev Compiler: Localize a React app without rewriting its code

AST

HMR

Performance

By the way

Frameworks

Bonus

Workflow

Next steps

Upcoming JavaScript Features You Should Know About

Pipeline Operator Improves Code Readability

How to Use It Today

With Babel (Generic Setup):

With Vite:

With Next.js:

With tsup:

With Remix (using Vite):

Pattern Matching Simplifies Complex Conditionals

How to Use It Today

With Babel (Generic Setup):

With Vite:

With Next.js:

With tsup:

Production Alternatives:

Temporal API Solves Date Handling Problems

How to Use It Today

With the Official Polyfill:

With Vite:

With Next.js:

With tsup:

Browser Support:

Resource Management Eliminates Memory Leaks

How to Use It Today

With Babel (Generic Setup):

With Vite:

With Next.js:

With tsup:

Making Objects Disposable:

Polyfill for Symbols:

Decorators Add Functionality Without Changing Core Logic

How to Use Decorators Today

With Babel (Generic Setup):

With Vite:

With Next.js:

With TypeScript:

With tsup:

Important Note:

Testing Your Configuration

Conclusion

Shocking Things You Can Do in JavaScript

Set operations that make lodash obsolete

Non-destructive array methods that respect immutability

Object grouping that transforms your data instantly

Text segmentation that actually understands language

Logical assignment operators that simplify common patterns

Top-level await that simplifies async module initialization

Private class features that enable true encapsulation

Atomics and SharedArrayBuffer for true parallelism

JavaScript continues to surprise

HTML5 Elements You Didn't Know You Need

1. The <dialog> Element: Native Modal Windows

2. The <details> and <summary> Elements: Native Accordions

1. The `<dialog>` Element: Native Modal Windows

2. The `<details>` and `<summary>` Elements: Native Accordions

3. The `<datalist>` Element: Native Autocomplete

4. The `<meter>` Element: Semantic Measurement Display

5. The `<output>` Element: Dynamic Calculation Results

6. The `<mark>` Element: Semantic Highlighting

7. The `<time>` Element: Semantic Dates and Times

8. The `<figure>` and `<figcaption>` Elements: Semantic Image Captions