DEV Community: Zach

How AI changed the way I pick frameworks, and the two places React survived

Zach — Tue, 21 Jul 2026 00:51:32 +0000

That 130-file PR that shipped KeyEcho 1.0 contained a decision I never wrote about: the desktop app moved from Tauri 1 + Vue to Tauri 2 + SolidJS.

The same summer, upweb.dev moved from Nuxt 4 to SolidStart, and keyecho.app (SSR, five languages, Stripe checkout) was built on SolidStart from scratch. Three separate decisions, same answer every time.

Scope first. This post is about defaults for my personal projects. Near the end I'll cover two places where I still use React, one of which runs very well.

The criteria changed

Most of the code in my repos is AI-generated now. My job has shifted from writing code to reviewing it.

The old framework checklist put most of its weight on learning curve and developer experience. Both are worth zero now: the model writes five frameworks fluently and knows the rules of hooks better than most humans do. AI crushed the price of writing code. Two costs didn't move: the runtime bytes every user downloads, and the human hours spent reviewing. Pick your stack by the new prices.

Runtime cost lives in the architecture. No prompt removes it, so it decides the framework. Review bandwidth is finite, and AI throughput will grind down any consistency that is maintained by verbal agreement, so it decides the styling layer. I have seen more than one React codebase a few years into its life: two animation libraries, two carousel components, three styling systems, each introduced for a perfectly good reason on some ticket, and the sum is a mess nobody can clean up. AI did not invent that drift. It made it an order of magnitude faster.

React is no longer my default: size and performance

Let me discard the weak arguments first. Dependency arrays, stale closures, re-render storms: I am not going to relitigate any of it. The model knows the rules of hooks cold, eslint-plugin-react-hooks catches most slips, and React Compiler now handles memoization. The ergonomics debate no longer produces a winner.

What still produces a winner is the client. react-dom is roughly 40 kB compressed, a virtual DOM plus a reconciler, downloaded, parsed, and executed on every cold visit by every user. React Compiler can remove wasted re-renders. It cannot remove the runtime itself. Developers never feel this cost. Users on phones pay it constantly.

My projects are one person plus a fleet of agents. Hiring pools do not help me, and content sites barely touch the component-library ecosystem. Once the weights shift like that, React has no slot left in my personal stack.

The same app, written ten times

Loren Stewart ran an experiment last year: the same kanban app implemented in ten frameworks, identical features (drag and drop, comments, tags, server validation), then compared compressed JS on the board page.

Framework	Compressed JS
Next.js 16 (React 19)	176.1 kB
TanStack Start (React 19)	118.2 kB
Analog (Angular 20)	103.9 kB
Nuxt 4 (Vue 3)	74.7 kB
TanStack Start + Solid	60.4 kB
Qwik City	58.4 kB
SvelteKit (Svelte 5)	54.1 kB
SolidStart (SolidJS 1.9)	41.5 kB
Astro + HTMX	34.3 kB
Marko	28.8 kB

Two comparisons stand out. Same meta-framework, TanStack Start, with React swapped for Solid: 118.2 kB becomes 60.4 kB. Next.js against SolidStart: a 4.2x gap. His conclusion was that React's architectural cost is something no meta-framework can optimize away.

The boundaries, as always. All ten implementations had FCP between 35 and 71 ms, indistinguishable by feel. Real-site bottlenecks are usually images and video, and framework JS is a small share of total bytes. But the two costs behave differently: media optimization is ongoing labor for the life of the site, while framework weight is fixed forever at pnpm create. AI already flattened the cost of writing the code. For the same feature set, there is no reason to start four times heavier.

First-party numbers, same site, before and after. On Nuxt 4, upweb.dev scored 70/100/100/100 on mobile PageSpeed. I did round after round of tuning at the Cloudflare layer and the performance score would not move; the lab bottleneck kept pointing at JS weight. After the move to SolidStart: 99/100/100/100, simulated Moto G Power on slow 4G, FCP 1.5 s, LCP 1.8 s, CLS 0.006, TBT 0 ms. That zero TBT is where fine-grained reactivity pays off most: there is no virtual tree to reconcile on the main thread.

Squeeze the water out of this comparison before quoting it: Lighthouse lab data, a single-page session, a sample of one site, and the framework was not the only variable. People will remind you that lab scores are not real user experience, and they are right. RUM tells you how users are doing today; the lab tells you how much headroom the architecture leaves. Same domain, same CDN config, framework swapped, and the score went from 70 to 99. Free points. I took them.

Desktop follows the same logic: inside a Tauri WebView, every kilobyte shaved off the runtime comes back as cold-start time and memory.

I did look at Svelte, Vue, Qwik, and Marko

Svelte 5's runes are signals too, and SvelteKit's 54.1 kB is small enough. Vue's reactivity comes from the same family, and Nuxt's 74.7 kB is the best result among the big-three meta-frameworks. What ruled them out is the language layer.

.svelte and .vue are custom file formats. TypeScript is one region inside the file, and type checking runs through a bridge: svelte-language-tools on one side, Volar on the other. The bridge works fine day to day. The bill arrives when the toolchain moves. TypeScript 7.0 went GA on the 8th of this month, a native Go compiler, officially about 10x faster, with type-checking of the VS Code codebase dropping from 125.7 seconds to 10.6. JSX is plain TS, so a Solid project switches the day it ships, zero changes. The compiler API that Vue and Svelte template checking depends on has no stable version in 7.0. They wait for 7.1 in October. Every extra language layer is another place in the upgrade queue.

One more against Nuxt: streaming SSR is still locked behind the experimental ssrStreaming flag, while streaming in SolidStart is one of createHandler's three built-in rendering modes. No flag to flip.

Qwik's resumability solves huge, interaction-sparse landing pages, which my sites are not, and I did not want to carry its mental model. Marko's 28.8 kB is the smallest of the ten, but the ecosystem is too small a bet for two sites I plan to maintain for years.

Reactivity models have been converging. Vue refs, Svelte 5 runes, Angular and Preact signals, plus the TC39 Signals proposal, all point the same way. React is the lone exception, patching around it with a compiler. Signals, JSX, plain TS: ask for all three at once and Solid is what is left.

Astro is smaller than SolidStart. Why not Astro?

One row in that table deserves a straight answer: Astro + HTMX is 34.3 kB, 7 kB smaller than SolidStart. Both of my sites are content-heavy marketing sites. By byte logic alone, Astro wins.

Astro's model is content first, zero JS by default, interactivity added through islands. The catch is that when you write the interactive parts, each island hosts a component framework anyway, and the project now speaks two dialects: .astro templates for page structure, the island framework for behavior, state passed across the seam. And .astro is one more custom file format, so the upgrade-queue problem from the last section applies here too.

Neither site is actually static. keyecho.app runs Stripe checkout, a subscribe flow, and SSR in five languages, with sound-pack sales pages on the way. upweb.dev has quietly grown into a small system: double-opt-in subscriptions, posts and newsletter archives managed in Broadside, and on every publish a webhook hits the site, verifies its signature, dedupes replays, clears the server content cache, then purges Cloudflare by cache tag. New articles go live without a deploy. All of that lives in SolidStart API routes, and the interaction density only goes up from here. One component model covering both the static and the dynamic parts is worth 7 kB to me.

If your site is a pure blog or docs and changes three times a year, Astro is the better answer, not SolidStart. With a bigger team the best practice is to split outright: landing pages on Astro or SolidStart, and the console on its own subdomain with its own stack.

The ecosystem bill: TanStack covers the worst of it, components you grow yourself

SolidStart is not a silver bullet, and its biggest weakness is the ecosystem. Most things React has, Solid has an equivalent for, one maturity tier down and with fewer options. Part of that you tolerate. Part of it has workarounds.

The workaround with the widest coverage is TanStack. Router, Query, Form, Table, Virtual: every package is a core plus adapters, and Solid gets first-class ones. I run the Solid version of TanStack Start in production at difflore.dev: solid-router, solid-query, and oRPC, a full backend with auth, a database, and AI calls, and no missing parts so far. That one vendor crosses off the heaviest items on the list.

The larger trend helps too: infrastructure is going framework-agnostic. Vite, Nitro, Drizzle, Zod, oRPC, better-auth do not care what renders your UI, and headless UI has moved from React-only toward state-machine cores with adapters for everyone. The framework-exclusive share of the ecosystem is shrinking. The flip side deserves saying out loud: every convenience you take from a React-only library raises the wall you would have to climb to ever leave. An ecosystem is an asset and a shackle at the same time.

The gap that remains is the polished component library. On the React side the standard is shadcn/ui; Solid has community ports, at a fraction of the traction. This does not slow me down, and shadcn itself demonstrates why: it ships no npm package. It copies component source into your repo, turning components from a dependency into your own code. Definitions like that are exactly what AI produces fast. One component, written twice, a React version and a Solid version, is minutes of work. None of my current interfaces use a prebuilt library: both sites are hand-written components on top of tokens, the React admin uses Base UI, the Solid side uses Kobalte, all headless primitives with the look and behavior defined by me. AI solved the output problem. What it did not solve is how to design a component API, where state should live, and how tokens get enforced. That skill transfers between React and Solid completely, and the shallower the component-library moat gets, the more it is worth practicing.

Styling: utility classes lost the default slot

The current state first, so this does not read like a takedown: KeyEcho desktop shipped 1.0 on UnoCSS, still runs it today, and I have no plan to rip it out. That UI is small and fixed, there is no design file to match, and the panels rarely change once settled, so utility classes have little room to go wrong there. Admin platforms and marketing sites are a different shape: pages keep multiplying, styles track redesigns, and there is a design language to defend. The two failure modes below belong to that second shape.

Utility classes fail in AI hands at two points.

The first is token drift, and Tailwind and UnoCSS are equally exposed. The project has its own design tokens, and the model still reaches for the default scale in its training memory, or drops in an arbitrary value. gap-3 and gap-[12px] look nearly identical in review, and today they render exactly the same. The difference is that the second one has left the token system, so the next scale change misses it. Every line is legal, and the design system forks a little more with each PR. I have watched this happen more than once. Tailwind v4's @theme cleans up token definitions; arbitrary values remain forever legal.

The second is size. Atomic CSS rests on class reuse: the stylesheet is supposed to stop growing with page count. Enough arbitrary values and that premise collapses. Every w-[347px] is a single-use rule, the stylesheet grows with the PR count, and so do the class strings in the HTML. A constraint model this permissive compiles everything, and the cost gets billed somewhere else.

vanilla-extract turns tokens into TypeScript exports. Styles live in .css.ts files, colors have to be imported from the theme, a misspelled variable is a type error, and a hex value invented from memory does not survive type checking. The theme contract on upweb.dev defines 16 tokens with createThemeContract; light and dark must each assign every key, and one missing dark value fails the build. The rule no longer depends on anyone's memory, or on whether the model read the docs. The output is plain CSS with zero runtime, split by route: a visitor downloads only the styles the current page uses, never a site-wide sheet.

The oldest complaint about CSS-in-TS is naming. AI flipped that one: the model does the naming, I only review, and a named block reads faster than a thirty-character utility string.

The rest of the CSS field

Zero runtime is the floor, which clears the runtime approaches immediately. styled-components and Emotion generate styles in the browser and need extra serialization for SSR, and styled-components is officially in maintenance mode. CSS Modules are zero-runtime, but tokens are string conventions the type system cannot see, so the theme contract is enforced by hoping.

Panda CSS and StyleX are in vanilla-extract's lane: typed, compile-time.

Panda loses on operational shape. It codegens an entire styled-system output directory that must be regenerated whenever tokens change, and the call sites look like a runtime library while behaving like build-time static extraction, so any dynamic object shape (computed keys, spread from a function) gets silently dropped from the stylesheet. Too much pipeline for a content site.

StyleX has nothing wrong with it as a design, and defineVars enforces tokens well, but it is stuck on ecosystem status: two community Vite plugins died in sequence, the official unplugin integration arrived late, and there is no established path in SolidStart. For infrastructure I only pick what the current build chain treats as a first-class citizen. vanilla-extract's official vite-plugin has been stable for years and drops into any Vite-based framework.

Where React still runs

A heavily interactive product I work on at my day job runs React 19 with React Compiler on TanStack Start, and runs well. A team's weight table is different from a solo one: the heavyweight components, editors above all, are written in React, so changing runtimes means a rewrite plus a full regression pass, and QA hours cost more than any framework difference. That alone settled the runtime. At the meta-framework layer they picked TanStack Start over Next.js for equally practical reasons: the product barely touches RSC, so Next.js's architectural complexity buys nothing there, and the Vite toolchain plus fully typed routing came along for free. Loren's table prices that choice at 58 kB: React 19 either way, 118.2 against 176.1, a third of the bytes.

Broadside's admin is a different story. It also runs React with TanStack Start, for a less flattering reason: I needed the platform running and had no time to switch stacks. The plan is to move it onto TanStack Start's Solid adapter, the same combination as difflore.dev: keep the ecosystem, swap the runtime.

Broadside is my self-hosted newsletter platform: an MCP server is built in, an agent drafts, models watch the numbers, and I review and press send. Once it is cleaned up I am open-sourcing it. Separate post then.

Five rules from three decisions

Pick frameworks by client-side bytes. AI erased learning curves from the weight table. Runtime cost lives in the architecture, and no prompt removes it.
A constraint only counts if the compiler enforces it. A rule that fails silently does not exist at AI throughput. Docs get diluted over a long session; type errors do not.
Every extra language layer is another place in the upgrade queue. TS 7 this month: JSX switched on day one, template DSLs wait until October.
Prefer framework-agnostic ecosystems, and grow your own component layer. A single-framework library's convenience and its lock-in come from the same place. Headless primitives plus your own tokens: AI supplies the volume, you supply the rules.
Change the default, do not relitigate the past. UnoCSS still runs the desktop app, and the day-job React product runs fine. New defaults apply to line one of new repos.

upweb.dev and keyecho.app both run on SolidStart + vanilla-extract today. The next repo I open will probably start there too, until some project's shape changes the answer again.

How I made a Rust hot path 27x faster, and the AI fix I refused to merge

Zach — Tue, 14 Jul 2026 16:38:47 +0000

Two years ago I open-sourced KeyEcho, a small desktop app that plays a mechanical-keyboard sound the instant you press a key. It got 800+ stars. Then I shipped v0.0.5 in July 2024 and went quiet.

The issues never stopped. People asked for sound packs, reported platform bugs, and kept using a thing I had stopped maintaining. This month I came back and shipped 1.0 in a single PR: 130 files, 11,405 lines added and 9,292 removed. The core of it was a rebuild of the audio hot path. The cached-lookup microbenchmark went from 1184.07 ns/op with 66.84 KiB copied per key to 43.50 ns/op with zero sample bytes copied. That is 27x on the average slice and 38x on the largest.

I built it with an AI agent writing a lot of the code. This post is how the rework works, why Rust made that safe to do fast, and the one change the agent suggested that looked clean and would have quietly broken a feature.

The hot path

KeyEcho's latency-sensitive path is short. A global keyboard hook fires on every key event. The first key-down of each press is pushed into a bounded queue. An audio thread pulls from the queue, maps the key to a slice of the selected sound pack, and plays it locally.

Because the path is short, anything left inside it is paid on every keystroke: any decode work, any allocation, any sample copy, any lock. The whole game is getting those out of the per-key path.

v0.0.5 was already fast

Credit where it is due. v0.0.5 was a light, quick thing: Tauri + Rust, small builds, low memory; native keyboard listening I wrote by hand against each platform's API, with almost no unsafe; lossless WAV audio with no decompression step; and it already cached decoded audio in an LRU, so hitting the same key twice did not decode twice. It ran for two years and a few hundred people used it. It was not slow software.

But "already fast" and "no headroom left" are two different things. Even on a cache hit, each key press still copied the samples (66.84 KiB in the benchmark) and went through a global mutex shared with pack switching and volume changes. A cache miss still decoded on the spot. What 1.0 removed is exactly those: that copy, that lock, and the fact that cache misses happen at all.

The rebuild

The rebuild came down to four moves.

Predecode once, when a pack is selected. A sound pack is a folder with a sound.ogg and a config.json. The config maps each key to a slice of the audio: key -> [start_ms, duration_ms]. When you select a pack, every slice is decoded up front, one time. Nothing decodes during a keystroke.

Deduplicate identical slices. Many keys point at the same slice, so decoding per key would decode the same audio many times. The builder keys a map on the (start_ms, duration_ms) pair, decodes each unique slice once, and shares it:

// Decode each unique slice once; identical slices share one buffer.
let mut slice_sources: HashMap<[u64; 2], AudioSource> = HashMap::new();
let mut key_sources: HashMap<Key, AudioSource> = HashMap::new();

for (key, slice) in defines {
    let source = slice_sources
        .entry(slice)
        .or_insert_with(|| {
            let [start_ms, duration_ms] = slice;
            let samples = decode(start_ms, duration_ms); // Vec<f32>, once
            AudioSource::new(Arc::from(samples), channels, sample_rate)
        })
        .clone(); // Arc clone, not a sample copy
    key_sources.insert(key, source);
}

Zero-copy playback. Decoded samples live in an Arc<[f32]>. A key lookup returns a clone of that Arc, which is a reference-count bump, not a sample copy. The per-key cost went to zero bytes copied.

Drop the global mutex. The old path guarded the current sound and the volume with a mutex. The new playback handle holds the current sound in an ArcSwapOption<KeySound> and the volume in an AtomicU32 (via f32::to_bits). Looking up a key is a lock-free load:

struct PlaybackSoundpack {
    current_sound: Arc<ArcSwapOption<KeySound>>,
    volume_bits: Arc<AtomicU32>,
}

fn source_for_key(&self, key: Key) -> Option<(AudioSource, f32)> {
    let sound = self.current_sound.load();          // lock-free
    let source = sound.as_ref()?.key_source(key)?;  // map get + Arc clone
    let volume = f32::from_bits(self.volume_bits.load(Ordering::Relaxed));
    Some((source, volume))
}

Predecoding trades work up front for RAM, so it needs two guardrails. Key events go through a bounded queue, so a burst applies backpressure instead of growing memory without limit. And a pack has to fit a decoded-sample budget of 10 MiB: before it loads, the app estimates decoded size from the unique slice durations and refuses anything larger. Predecoding is only safe when it is bounded.

The numbers

Release-build microbenchmarks of the lookup path:

Path	v0.0.5	v1.0	Change
Cached lookup, average slice	1184.07 ns/op; 66.84 KiB copied	43.50 ns/op; 0 bytes copied	27.2x faster
Cached lookup, largest slice	1638.57 ns/op; 98.88 KiB copied	43.10 ns/op; 0 bytes copied	38.0x faster
Press/release gate	58.82 ns/tap; 2 messages	54.69 ns/tap; 1 message	half the messages

These are microbenchmarks of the lookup path, not end-to-end speaker latency, which depends on your OS and hardware. The method and memory budgets are in docs/performance.md, and the benchmarks ship in the repo. Run pnpm run bench:audio if you do not believe me.

Why Rust made this safe to do fast

I leaned on the agent for most of this diff. The reason that felt safe is the compiler.

The borrow checker and the type system are the first reviewer for AI-generated code. Most wrong code does not survive cargo check. Moving shared audio buffers to Arc<[f32]> and removing the mutex are exactly the changes where a mistake is an aliasing or a Send/Sync error, and Rust rejects those at compile time, before they reach a human review or a user. The more of the diff an agent writes, the more that guardrail is worth.

What the agent actually did

Not "it wrote the app." The useful work was narrower and, honestly, more valuable.

Migration assistant. Tauri 1 to 2 touches config, permissions, the updater, and every plugin boundary. A partner that has read all the migration docs saves real hours.
Hot-path auditor. It went through the old playback path with me line by line and drove the predecode, shared-buffer, no-mutex rework above.
Backlog triage. I had it read every open issue and sort by what belonged in 1.0. One of them was a 10-month-old request from someone who had offered to pay for a specific sound. Replying to it after 1.0 turned into the project's first paying customer. The backlog was demand I had stopped reading.
Benchmark and docs discipline. It kept the performance notes conclusion-first, reproducible, and honest about what the numbers do and do not measure.

I rarely gave step-by-step orders. I gave goals ("get sample copies in the key path to zero", "sort the backlog by what belongs in 1.0") and reviewed at the checkpoints. The speedups themselves come from the rework: predecoding, shared buffers, the dropped mutex, the bounded queue. The agent is what made finding, doing, and verifying that whole loop fast enough to actually happen.

The change that looked clean and wasn't

This is the one I want you to steal.

CI for the Linux armv7 build failed under QEMU: libgit2 could not fetch a git dependency. The agent's fix was clean. Drop the git pin on the audio crate and use the crates.io release instead. CI went green.

I rejected it. That pin exists for a reason that is written nowhere in the code. It holds cpal at 0.18, which ships the default-device rerouting (and its DeviceChanged notification) that makes the sound follow you when you unplug headphones or switch to a Bluetooth speaker. Reverting to the crates.io version silently downgrades cpal to 0.17.3 and drops device-following. Two user issues, #41 and #20, were about exactly that behavior. No test covered "unplug the device and the sound follows," so nothing would have caught the regression except knowing why the pin was there.

The real fix was to vendor the dependencies with cargo vendor and build offline inside QEMU. The pin never moved.

Two lessons I now treat as rules:

Write the "why" next to every pin, hack, and magic number, in a comment or the project's AI rules file. Your agent has no memory of the incident that put it there. It is a talented engineer with zero context on your project.
Never accept a dependency version change you did not ask for, even when CI is green. A green pipeline proves the tests pass. It does not prove the tests cover what you are about to lose.

What I cut

The armv7 build ran about two hours under emulation, and there was no clear user for 32-bit ARM Linux. I dropped it from 1.0.

An agent has no sense of sunk cost or opportunity cost. It will keep optimizing a build target forever if you let it. It can get arbitrarily close to "done." Deciding to stop is a human job.

How the work was structured

Two smaller notes from shipping this.

Before release I ran an AI review pass inside git worktrees, so several agents could scan the code and propose fixes in parallel without touching the main tree. Each agent's output was a proposal, merged only after review. Exploration parallelizes cleanly. The synthesis still has to happen in one head, because each agent only sees its own slice.

The models are also starting to specialize. Claude Fable feels like an engineer who thinks outside the box and keeps surfacing angles I had missed. GPT-5.6 is the best executor I have used: hand it a decided plan and the code comes back close to perfect. It felt like running a two-person team where one thinks, one builds, and I decide and sign off.

What 1.0 is

Still free, still open source. AGPL-3.0, small native installers, no account, no analytics. Rebuilt on Tauri 2 + SolidJS. Signed Windows builds and notarized macOS builds, which cut down unsigned-app warnings and antivirus false positives. Linux packages for x64 and ARM64.

You can try it without downloading anything: open keyecho.app and type, and you will hear it in the browser. The benchmarks and method are in the repo.

I write a weekly build log about shipping real production systems with AI agents, honest numbers only. Subscribe at upweb.dev.

The Differences Between "export default xx" and "export {xx as default}"

Zach — Tue, 21 Oct 2025 03:57:14 +0000

Originally published in my newsletter.

The Basics of JavaScript Modules

Modules are self-contained pieces of code that can be imported and used in other modules. They help developers keep code organized, maintainable, and easy to understand.

To work with modules, you need to understand the import and export syntax. Here’s a quick recap:

import: Used to import named exports or default exports from other modules.
export: Used to export values, functions, or classes from a module, making them available for other modules to import.

There are two types of exports:

Named exports: You can have multiple named exports in a module. They are explicitly imported using their names.
Default exports: Each module can have only one default export. They are imported without specifying a name.

The Behavior of export { xxx as default }

In JavaScript, imports are live bindings, or references, rather than values. This means that when you import a variable from another module, you’re importing a reference to that variable, not a copy of its value.

Consider the following example:

// math.js
let value = 1;

setTimeout(() => {
  value = 888;
}, 500);

export { value as default };
// app.js
import value from './math.js';

setTimeout(() => {
  console.log(value); // ?
}, 1000);

In this case, guess what value is printed?

The answer is 888 not 1. This is because export exports references.

The Behavior of export default xxx

The export default syntax is used to export a default value from a module. However, when you use export default value, the current value is exported, not a live reference.

// math.js
let value = 1;

setTimeout(() => {
  value = 888;
}, 500);

export default value;
// app.js
import value from './math.js';

setTimeout(() => {
  console.log(value); // 1
}, 1000);

In this case, when the value variable in math.js changes, the value variable in app.js does not change. This is because value holds the current value at import time, not a live reference.

Export Reference Data Types

As you can see, we exported primitive data types earlier, but what if we exported reference data types?

// math.js
const value = {
  current: 1,
};

setTimeout(() => {
  value.current = 888;
}, 500);

export default value;
// OR
// export { value as default };
// app.js
import value from './math.js';

setTimeout(() => {
  console.log(value.current);
}, 1000);

As you can see, there is no difference between export default xxx and export { xxx as default } when dealing with reference data types. It can be understood that they are always reference types in JavaScript, and they will not be deeply copied when exported.

Best Practices and Recommendations

While both export default xxx and export { xxx as default } can be used to export default values, but their behavior differs in certain scenarios. Here are some recommendations to help you choose the right syntax:

Use export default xxx when you want to export a value, such as a string, or number, and you don't need live bindings.
Use export { xxx as default } when you need live binding, especially when the exported value may change over time (not recommended).
For reference data types, either syntax can be used, since they always export a reference.
A related suggestion: For code readability and maintainability, it is recommended to use named exports instead of default exports, here is why.

Conclusion

The differences between export default xxx and export { xxx as default } in JavaScript may appear subtle, but they can have an impact on your code's behavior. Hope this article is helpful to you.

If you find this helpful, please consider subscribing to my newsletter for more insights on web development. Thank you for reading!

How does HTTPS work

Zach — Tue, 21 Oct 2025 03:39:22 +0000

Originally published in my newsletter.

Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was originally designed for communication between web browsers and web servers, but with later development, its application is not limited here, the mature software and hardware environment makes it the infrastructure of the Internet. I believe you must have been exposed to it, it is just like water or air in software development, it’s all too common.

But as programmers, we may ignore a lot of key information because of its commonness, resulting in some problems in daily work development and do not know how to solve them. Then this article will introduce you to one of the key pieces of information — HTTPS.

Why HTTPS?

Why does it appear? What problem does it appear to solve?

To answer the above questions, we need to first analyze the characteristics of HTTP.

The characteristics of HTTP are simple, flexible, and easy to extend, but at the same time it is stateless (you can use Cookie technology to achieve “stateful”), and it is transmitted in clear text, which means that its data is completely visible and easy to be eavesdropped or forgery.

At the same time, HTTP is widely used, so scenarios with high-security requirements such as online payment require corresponding security measures, so HTTPS appeared.

What is HTTPS?

The RFC document of HTTPS has very little content. It specifies a new protocol name “HTTPS” and the default port number is 443, which is to insert a “security layer” between TCP and HTTP.

This security layer, as the name implies, encrypts the data sent and decrypts the data received so that the middleman cannot steal the information. Then as long as you understand this security layer, you also understand HTTPS.

SSL is the Secure Sockets Layer, which is at layer 6 (Presentation) in the OSI model. It was invented by Netscape in 1994. There are two versions, v2 and v3, and v1 was never disclosed because of its flaws.

When SSL developed to v3, it proved itself to be a very good secure communication protocol, so the Internet Engineering Group IETF renamed it TLS (Transport Layer Security) in 1999, and officially standardized, the version number from 1.0 is recalculated, so TLS1.0 is actually SSL 3.1.

At present, TLS has developed three versions, namely 1.1 in 2006, 1.2 in 2008, and 1.3 in 2018, and each new version is continuously enhancing security and performance. The most widely used TLS 1.2 at present, so let’s unravel the secrets of TLS 1.2!

HTTPS (TLS 1.2) secret

Let me explain the above image first:

Handshake phase:

The client generates a client-random and then passes the symmetric cipher suites and asymmetric cipher suites it supports to the server.
After the server receives it, it will select the encryption algorithm to use from the encryption suite, generate a server-random and pass the certificate of the service to the client.
After the client receives it, it will first verify the certificate. If the certificate is valid, it will generate a pre-master random number, encrypt it with the public key in the certificate and the selected asymmetric encryption algorithm , and then pass it to the server. It will also come with a Client finished confirmation message.
The server receives the encrypted pre-master and can decrypt it using the private key. A confirmation message of the Server finished will then be passed to the Client.

Transfer stage:

After the handshake phase, both ends already have client-random, server-random, and pre-master. Mix them to generate the final master secret, and use the previously selected symmetric encryption algorithm to encrypt and decrypt the required transmitted data.

God, is it so troublesome that I just want to send data? I thought the same thing when I first saw it.

Let’s be patient and take a closer look, it’s actually not that difficult.

What are symmetric encryption and asymmetric encryption?

Let’s first explain the symmetric encryption and asymmetric encryption mentioned above.

Symmetric encryption means that the same key is used for encryption and decryption. Asymmetric encryption has two keys, A and B. If you use the A key to encrypt, you can only use the B key to decrypt; conversely, If you want the B key to encrypt, you can only use the A key to decrypt.

In the handshake phase of HTTPS, we use asymmetric encryption, why? Suppose we use symmetric encryption:

As can be seen from the above figure, the client-random and service-random and symmetric encryption suites passed in are in clear text, which leads to the fact that if a hacker gets the data, they can generate the same key, which can be cracked data.

If we use asymmetric encryption, the pre-master encrypted by the client can only decrypt the key stored by the server.

What is a CA certificate?

Because once the hacker uses DNS hijacking and replaces the IP address that the user wants to access with the hacker’s IP address, the request will be sent directly to the hacker’s service. He implements the public key and private key on his service, and the client completely does not know!

So we need the CA (Certificate Authority) certificate authority to help us prove that this service is the service we want to access!

How to check the validity of the CA certificate?

The client will verify according to the following process:

Check if the certificate has expired
Check if revoked by CA
Check whether the certificate is issued by the CA authority. We will use the original certificate information to calculate the message digest, use the CA public key to decrypt the digital signature in the certificate, and then compare the message digest with the digital signature.
Prove the legitimacy of the CA organization. The CA certification chain is a tree structure, and the root CA certificate is found step by step. The root CA certificate (self-signed certificate) is built into the system. The requirements are very strict. If the root CA certificate is valid, it also proves that the certificate is valid. But if malware injects an illegitimate root CA certificate into a user’s system, there’s no way around it.

Why is the transmission phase symmetric encryption?

This is because the symmetric encryption algorithm usually uses bit operations, and the asymmetric encryption is mainly the calculation of some large number multiplications in RSA, so the efficiency of asymmetric encryption is very low, which will seriously affect the transmission speed and make the user experience very poor. And the master secret we generated in the handshake phase is secure enough, so we can use symmetric encryption in the transfer phase.

If you find this helpful, please consider subscribing to my newsletter for more insights on web development. Thank you for reading!

Ditch Git Checkout: Use Git Switch and Git Restore Instead

Zach — Mon, 14 Oct 2024 02:45:48 +0000

If you use Git in your daily work, git checkout is a common command. It's often used to switch branches, and if you look at the documentation, you can see the phrase "switch branches or restore working tree files". But UNIX should be Do One Thing and Do It Well. This was confusing, so Git 2.23 brought a pair of commands to replace it.

Before introducing how it works, we need to briefly understand its associated Git concepts.

Working copy (working tree file): It refers to the file in the repository that appears on the hard disk.
Index (staging area or cache): it refers to you have git add-ed, or, what would be committed if you were to run git commit.
HEAD: It refers to the “current” or “active” branch, when we need to check out a branch (referring to your attempt to match the branch with what is in the working copy), only one can be checked out at a time.

git checkout can checkout a branch or create a new branch and checkout into it:

# Switched to branch 'test'
$ git checkout test

# Switched to a new branch 'test'
$ git checkout -b test

# Switch back to the previous branch
$ git checkout -

# Switched to a commit
$ git checkout master~1

And git switch is used to take over branch related, so it can also do:

# Switched to branch 'test'
$ git switch test

# Switched to a new branch 'test'
$ git switch -c test

# Switch back to the previous branch
$ git switch -

# Switched to a commit
$ git switch -d master~1

And as we said at the beginning, git checkout can also restore working tree files. This part of the feature is taken over by git restore.

In the past, we could use git checkout -- main.c to restore the working tree file from the index, the syntax was git checkout [treeish] -- <filename>, where treeish could be specified as the source. Simple examples:

# Restoring the working tree from the index
$ git checkout -- ./main.c

# Restoring index content from HEAD
$ git reset -- ./main.c

# Restoring the working tree and index from HEAD
$ git checkout HEAD -- ./main.c

Note that when restoring index content from HEAD, we can only use git reset, and git checkout has no corresponding option.

Show with a graph:

git restore makes it easier to determine which files will be restored, and where they will be restored. The following options specify the restore location:

-W
--worktree
-S
--staged

By default, -W and --worktree will restore the working tree from the index, the same as if no options were specified (like git restore -- ./main.c ). Whereas -S and --staged will restore the index contents from HEAD. When passing both, the index and working tree will be restored from HEAD.

For instance:

# Restoring the working tree from the index
$ git restore -- ./main.c
# Equivalent to
$ git restore --worktree -- ./main.c

# Restoring index content from HEAD
$ git restore --staged -- ./main.c

# Restoring the working tree and index from HEAD
$ git restore --staged --worktree ./main.c

Show with a graph:

The above-mentioned is the default, if we want to restore from a different commit, we can use the --source option. E.g:

# Restore `./main.c` in the working tree with the last commit
$ git restore -s HEAD^ -- ./main.c
# Equivalent to
$ git restore --source=HEAD^ -- ./main.c

Another useful git restore case might be restoring a mishandled file. E.g:

# Incorrectly deleted files
$ rm -f ./main.c

# Quickly restore main.c from index
$ git restore ./main.c

For batch recovery:

# Restore all C source files to match the version in the index
$ git restore '*.c'

# Restore all files in the current directory
$ git restore .

# Restore all working tree files with top pathspec magic
$ git restore :/

Conclusion

The features of git checkout are clearly separated: git switch is used to switch branches, while git restore is used to restore working tree files. They provide more explicit semantics, in line with the UNIX philosophy.

Both commands were proposed in 2019, and as of now, they are experimental. There may be changes, but usually not by much, so you can use them now, they are easier to understand and less confusing.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

The Secrets of JavaScript Object Property Order

Zach — Mon, 14 Oct 2024 02:44:09 +0000

Someone asked me recently, are JavaScript object properties necessarily unordered and unpredictable?

Developers with early exposure to JavaScript might answer that Object.keys() or for...in returns an unpredictable order of object properties. But is that still the case?

As you might expect, there are now rules to follow.

Starting with ECMAScript 2020, Object.keys, for...in, Object.getOwnPropertyNames, and Reflect.ownKeys all follow the same order of specification. They are:

1. Own properties are array indexes, in ascending numeric index order

An array index is a String-valued property key that is a canonical numeric String. And a canonical numeric String is a String representation of a number that would be produced by ToString, or the string "-0". So for instance, "012" is not a canonical numeric String, but "12" is.

2. Other own String properties, in ascending chronological order of property creation

The above code adds the knowledge point of the event loop. Because setTimeout is an asynchronous macro task, the c property has not been added to obj when console.log is output.

3. Own Symbol properties, in ascending chronological order of property creation

The Symbol property is the same as the String property, in ascending chronological order of property creation. But the Object.keys, for...in, Object.getOwnPropertyNames methods cannot get the object's Symbol properties, Reflect.ownKeys and Object.getOwnPropertySymbols can.

Conclusion

When an object’s property keys are a combination of the above types, the object’s non-negative integer keys (enumerable and non-enumerable) are first added to the array in ascending order, then String keys are added in insertion order. Finally, Symbol keys are added in insertion order.

But if you strongly depend on the insertion order, then Map guarantees that for you.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

Understanding the infer Keyword in TypeScript

Zach — Fri, 27 Sep 2024 14:58:34 +0000

TypeScript, a statically-typed superset of JavaScript, has gained massive popularity in the tech community due to its ability to catch errors early and improve code readability. One of TypeScript’s powerful features is the infer keyword, which allows developers to write more expressive and dynamic types.

The Infer Keyword

Introduced in TypeScript 2.8, the infer keyword is used within conditional types to create temporary type variables. These type variables can then be used to infer types within a true or false branch of a conditional type. The infer keyword enables developers to write more dynamic and expressive types, as it allows TypeScript to determine a specific type based on the context in which it's used.

To better understand how infer works, let's take a look at the basic syntax of a conditional type:

type MyConditionalType<T> = T extends SomeType ? TrueType : FalseType;

In this example, T is a generic type parameter, and SomeType represents a type that T is being compared to. If T extends SomeType, the type of MyConditionalType<T> will be TrueType. If not, it will be FalseType.

Now, let’s introduce the infer keyword into the mix:

type MyInferredType<T> = T extends SomeType<infer U> ? U : FalseType;

Here, we use the infer keyword to create a temporary type variable U within the true branch of the conditional type. If T extends SomeType, TypeScript will try to infer the type of U based on the type of T.

Examples

ReturnType

ReturnType is a utility type that extracts the return type of a function. It's a perfect example of how the infer keyword can be used to create dynamic types. Here's the definition of ReturnType:

type ReturnType<T extends (...args: any[]) => any> = T extends (...args: any[]) => infer R ? R : any;

In this definition, T is a function type that takes any number of arguments and returns any type. Using the infer keyword, we create a temporary type variable R to represent the return type of the function. If T is a function, TypeScript infers the return type and assigns it to R.

Let’s see ReturnType in action:

function greet(name: string): string {
  return `Hello, ${name}!`;
}

type GreetReturnType = ReturnType<typeof greet>; // GreetReturnType is inferred as 'string'

Here, ReturnType is used to infer the return type of the greet function, which is string.

Parameters

Another useful utility type that leverages the infer keyword is Parameters. This type extracts the parameter types of a function as a tuple. The definition of Parameters is as follows:

type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never;

In this example, we create a temporary type variable P to represent the parameter types of the function. If T is a function, TypeScript infers the parameter types and assigns them to P as a tuple.

Let’s look at an example using Parameters:

function add(a: number, b: number): number {
  return a + b;
}

type AddParameters = Parameters<typeof add>; // AddParameters is inferred as [number, number]

Here, Parameters is used to infer the parameter types of the add function, which is a tuple [number, number].

PromiseType

The PromiseType utility type can be used to extract the type that a Promise resolves to. This is particularly useful when dealing with asynchronous functions. Here's the definition of PromiseType:

type PromiseType<T extends Promise<any>> = T extends Promise<infer U> ? U : never;

In this example, we create a temporary type variable U to represent the type that the Promise resolves to. If T is a Promise, TypeScript infers the resolved type and assigns it to U. Here’s an example:

async function fetchData(): Promise<string> {
  return "Fetched data";
}

type FetchedDataType = PromiseType<ReturnType<typeof fetchData>>; // FetchedDataType is inferred as 'string'

In this case, PromiseType is used to infer the type that the fetchData function's promise resolves to, which is string.

UnboxArray

The UnboxArray utility type can be used to extract the type of the elements within an array. Here's the definition of UnboxArray:

type UnboxArray<T extends Array<any>> = T extends Array<infer U> ? U : never;

In this example, we create a temporary type variable U to represent the type of the elements within the array. If T is an array, TypeScript infers the element type and assigns it to U. For instance:

type MyArray = number[];

type ElementType = UnboxArray<MyArray>; // ElementType is inferred as 'number'

Here, UnboxArray is used to infer the type of elements within the MyArray type, which is number.

Limitations

While the infer keyword is incredibly powerful, it has some limitations:

It can only be used within conditional types.
It’s not always possible for TypeScript to infer the correct type, especially when dealing with complex or recursive types. In such cases, developers may need to provide additional type annotations or refactor their types to help TypeScript infer the correct type.

Conclusion

By understanding and leveraging the power of infer, you can create more flexible TypeScript projects. Start considering incorporating the infer keyword into your toolkit today.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

How Server-Sent Events (SSE) Work

Zach — Fri, 27 Sep 2024 14:47:11 +0000

SSE (Server Sent Events) is not widely used in the world of web development, this article will take a deep dive into what SSE is, how it works, and how it can benefit your application.

What is SSE?

SSE is a simple and efficient way to send real-time updates from a server to a client over an HTTP connection. It is a part of the HTML5 specification and is supported by all modern web browsers. SSE is based on a unidirectional data flow, where the server sends messages to the client, but the client cannot send messages back to the server.

SSE uses a text-based format known as “Server-Sent Events” to send data to the client. The data is sent as a series of events, each of which contains a message and an optional event type. The event type is used to distinguish between different types of messages and allows the client to handle them differently.

How does SSE work?

The SSE protocol works by establishing a persistent HTTP connection between the server and the client. This connection is kept open for as long as the client wants to receive updates from the server. When the server has new data to send, it sends an HTTP response with a special MIME type “text/event-stream”.

The response contains a series of events, each of which is separated by a new line character (“\n”). Each event has the following format:

event: [event type]\n
data: [message]\n\n

The “event” field is optional and is used to provide a name for the event. The “data” field contains the actual message being sent. The two newline characters at the end of each event are used to signal the end of the event.

Here’s an example of a simple SSE response:

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: message
data: Hello, world!

event: message
data: This is a test message.

event: customEvent
data: {"foo": "bar", "baz": 123}

In this example, we’re sending three events to the client. The first two events have the event type “message” and contain simple text messages. The third event has the event type “customEvent” and contains a JSON object as its message.

When the client receives an SSE response, it uses the data to update its user interface. This can be done using JavaScript to manipulate the DOM, for example.

Implementing SSE

Implementing SSE in your application is relatively straightforward. Here’s an example of how to implement SSE using Node.js and the Express framework:

const express = require('express');
const app = express();

// Set up SSE endpoint
app.get('/events', (req, res) => {
  // Set headers
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  // Send initial event
  res.write('data: Connected\n\n');
  // Set interval to send periodic events
  const intervalId = setInterval(() => {
    res.write('data: Hello, world!\n\n');
  }, 1000);
  // Clean up on connection close
  req.on('close', () => {
    clearInterval(intervalId);
  });
});

// Start server
app.listen(3000, () => {
  console.log('Server started on port 3000');
});

In this example, we’re setting up an SSE endpoint at “/events”. We’re setting the necessary headers for SSE and sending an initial event to the client to confirm that the connection has been established.

We’re then setting up an interval to send periodic events to the client every second. Finally, we’re cleaning up the interval when the connection is closed by the client.

On the client side, we can use the following JavaScript code to listen for SSE events:

const source = new EventSource('/events');

source.addEventListener('message', (event) => {
  console.log(event.data);
});
source.addEventListener('error', (event) => {
  console.error('Error:', event);
});

In this example, we’re creating a new EventSource object and passing in the URL of our SSE endpoint. We’re then listening for the “message” event and logging the data to the console. We’re also listening for the “error” event in case there are any connection issues.

Note that the EventSource path on the front end can only be used by GET requests, if you want to use POST and other HTTP methods, you need to parse the response data yourself.

If you want a native Node.js implementation, here’s one

Use cases for SSE

SSE can be used in a wide range of applications that require real-time updates. Here are a few examples:

Social media platforms: SSE can be used to provide real-time updates for social media platforms, such as notifications of new messages, comments, or likes.
Financial applications: SSE can be used to provide real-time updates for financial applications, such as stock prices, currency exchange rates, or news.
Online gaming: SSE can be used to provide real-time updates for online gaming applications, such as notifications of game events, scores, or rankings.

Benefits of using SSE

There are several benefits to using SSE over other real-time communication methods such as polling or WebSockets:

Efficiency

SSE uses a persistent HTTP connection, which means that the overhead of establishing and maintaining the connection is much lower than with other methods. This makes SSE more efficient and less resource-intensive, which is especially important when dealing with large numbers of clients.

Simplicity

SSE is a simple protocol that is easy to understand and implement. It does not require any special libraries or frameworks and can be implemented using standard web technologies such as JavaScript and HTTP.

Reliability

SSE is a reliable protocol that provides automatic reconnection in case of a network interruption. This ensures that the client will continue to receive updates even if the connection is temporarily lost.

Conclusion

Server-Sent Events (SSE) are a simple and efficient way to send real-time updates from a server to a client over an HTTP connection. It is a part of the HTML5 specification and is supported by all modern web browsers. SSE uses a unidirectional data flow, where the server sends messages to the client, but the client cannot send messages back to the server. This saves you from constantly polling the server for events, which not only improves performance but also reduces complexity.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

Ditch dotenv: Node.js Now Natively Supports .env File Loading

Zach — Sun, 22 Sep 2024 08:07:16 +0000

One of the staples of environment management in Node.js has been the use of the dotenv package, which facilitates the loading of environment variables from a .env file. However, recent updates in Node.js have introduced built-in capabilities that may reduce or eliminate the need for external packages like dotenv for managing environment variables.

Native `.env` File Handling

Starting from version 20.6.0, Node.js allows the use of the --env-file flag when executing scripts. This flag specifies a path to an .env file that Node.js will read before running the specified script. This approach streamlines the process of setting environment variables, making it more integrated and less reliant on third-party packages.

Consider a scenario where you have the following environment configuration:

# .env file
NODE_OPTIONS='--title="Sample Node App"'
USER_NAME='John Doe'

To run a Node.js script using this configuration, you would use:

node --env-file=.env your-script.js

Inside your-script.js, accessing these variables can be done as follows:

console.log(process.title); // Outputs: Sample Node App
console.log(`Hello, ${process.env.USER_NAME}`); // Outputs: Hello, John Doe

Simplified Loading with `process.loadEnvFile()`

Building upon the initial support, Node.js version 21.7.0 introduced the process.loadEnvFile() method. This function simplifies the loading of environment variables by incorporating them into the runtime process without the need for command-line flags.

You can load the environment variables programmatically within your application as shown below:

process.loadEnvFile(); // Automatically loads `.env` from the current directory

// Or specify a path
process.loadEnvFile('./config/env_vars.env');

Parsing Environment Variables

In addition to loading environment variables, Node.js 21.7.0 introduced util.parseEnv(), a utility function that parses a string containing environment variable definitions into an object.

Here’s how you might use util.parseEnv():

const util = require('node:util');
const envVars = util.parseEnv('API_KEY=12345');
console.log(envVars.API_KEY); // Outputs: 12345

Support for Multi-line Values in `.env` Files

Another feature in Node.js 21.7.0 is the support for multi-line values in .env files:

CERTIFICATE="-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgIJAKC1hi9s2wfMM...
-----END CERTIFICATE-----"

You can now include such multi-line strings directly in your .env files, making management of complex configurations cleaner and more straightforward.

Conclusion

The native .env file support introduced in the latest Node.js allows your project to be set up faster and reduces dependencies on external packages such as dotenv.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

How to Create a Type to Retrieve All Keys of an Object in TypeScript

Zach — Mon, 16 Sep 2024 04:30:01 +0000

Typescript has a feature called keyof that can be used to obtain the keys of an object. However, the keyof operator only works for the first level of an object, and when we want to obtain all keys in a deep level, things get a bit more complicated. In this article, we will discuss how to implement a type that can obtain all keys in a deep level.

Overview of the Problem

To understand the problem we are trying to solve, let’s start with an example. Consider the following object:

const obj = {
  a: {
    b: 1,
    c: {
      d: 2,
      e: 3
    }
  },
  f: {
    g: 4
  }
}

If we want to obtain all the keys of this object, including the keys in the nested objects, we need a type that can recursively traverse the object and return all the keys. This can be a challenging task, especially for complex objects with multiple levels of nesting.

A Possible Solution

One approach to solving this problem is to use a recursive type definition. Typescript allows us to define recursive types using intersection types. An intersection type is a type that represents a value that has all the properties of all the types in the intersection.

We can define a recursive type that represents an object with a set of keys, where each key is either a primitive value or another object that also has a set of keys. Here’s how we can define this type:

type DeepKeys<T> = T extends object
  ? {
      [K in keyof T]-?: K extends string | number
        ? `${K}` | `${K}.${DeepKeys<T[K]>}`
        : never;
    }[keyof T]
  : never;

This type definition may seem a bit complex, so let’s break it down into smaller parts.

The type DeepKeys<T> is a conditional type that checks if the input type T is an object. If T is an object, we use a mapped type to create a new object with the same keys as T, but the values are the keys of the nested objects, represented as a string. If T is not an object, we return an empty string.

The mapped type uses the keyof operator to get the keys of the object, and then we use a conditional statement to check if each key is a string or number. If the key is a string or number, we concatenate it with a dot and the keys of the nested object, obtained recursively using DeepKeys<T[K]>. If the key is not a string or number, we return never, which means the key is not valid.

Using the Type

Now that we have defined the DeepKeys type, we can use it to get the keys of any object with nested objects. Here's an example of how we can use it:

const obj = {
  a: {
    b: 1,
    c: {
      d: 2,
      e: 3,
    },
  },
  f: {
    g: 4,
  },
  h: undefined,
};

type DeepKeys<T> = T extends object
  ? {
      [K in keyof T]-?: K extends string | number
        ? `${K}` | `${K}.${DeepKeys<T[K]>}`
        : never;
    }[keyof T]
  : never;

function getAllKeys<T extends object>(
  obj: T,
  prefix: string = '',
): DeepKeys<T>[] {
  return Object.entries(obj).reduce((result: string[], [key, value]) => {
    const newPrefix = prefix ? `${prefix}.${key}` : key;

    return result.concat([
      newPrefix,
      ...(typeof value === 'object' && value !== null
        ? getAllKeys(value, newPrefix)
        : []),
    ]);
  }, []) as DeepKeys<T>[];
}

const keys = getAllKeys(obj);
console.log(keys); // ["a" | "f" | "h" | "a.b" | "a.c" | "a.c.d" | "a.c.e" | "f.g"]

In this example, we define a function called getAllKeys that takes an object as an argument and returns an array of all the keys in the object. We use the Object.keys method to get the keys of the object, and then we cast the result to the DeepKeys type to ensure that we get all the keys, including the keys in the nested objects.

Limitations

While the DeepKeys type can be useful in many situations, it does have some limitations. One limitation is that it only works for objects with a finite depth. If we have an object with an infinite depth, such as an object that contains a reference to itself, the type definition will result in a stack overflow error.

Another limitation is that the resulting type can be very complex for objects with many levels of nesting, which can make it difficult to work with. In some cases, it may be necessary to use a simpler type definition or a different approach to get the keys of an object.

Conclusion

In this article, we have discussed how to implement a type that can obtain all the keys in an object, including the keys in the nested objects. We have used a recursive type definition to define the DeepKeys type, which allows us to recursively traverse the object and return all the keys. We have also provided an example of how to use the DeepKeys type to get the keys of an object.

While the DeepKeys type has some limitations, it can be a useful tool for working with objects with nested objects.

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

7 Lesser-Known HTML Attributes to Enhance User Experience

Zach — Wed, 11 Sep 2024 04:29:00 +0000

HTML is a powerful language for creating web pages, and while most developers are familiar with commonly used HTML attributes, there are several lesser-known attributes that can provide additional functionality and enhance the user experience.

1. The `enterkeyhint` Attribute for Virtual Keyboards

When designing web forms for mobile devices, it’s important to consider the virtual keyboards that users interact with. The enterkeyhint attribute is a global attribute that can be applied to form controls or elements with the contenteditable attribute set to true. It assists users by providing hints to the virtual keyboard about the intended action associated with the "Enter" key. This attribute accepts values such as enter, done, go, next, previous, search, and send, allowing you to customize the hint based on the specific context of your application.

<input type="text" enterkeyhint="done">

2. Attributes for Custom Ordered Lists

While working with ordered lists <ol>, you can utilize several lesser-known attributes to customize the behavior of the numbering. These attributes include:

The reversed attribute: It allows you to number the list items in reverse order, from high to low instead of the default low to high.
The start attribute: It defines the number from which the list should start.
The type attribute: It specifies whether to use numbers, letters, or Roman numerals for the list items.
The value attribute: It enables you to set a custom number for a specific list item.

<ol reversed>
  <li>List item...</li>
  <li>List item...</li>
  <li>List item...</li>
</ol>

<ol reversed start="20" type="1">
  <li>Typee: A Peep at Polynesian Life (1846)</li>
  <li>Omoo: A Narrative of Adventures in the South Seas (1847)</li>
  <li>Mardi: and aVoyage Thither (1849)</li>
  <li>Redburn: His First Voyage (1849)</li>
  <li value="100">White-Jacket; or, The World in a Man-of-War (1850)</li>
  <li>Moby-Dick; or, The Whale (1851)</li>
  <li>Pierre; or, The Ambiguities (1852)</li>
  <li>Isle of the Cross (1853 unpublished, and now lost)</li>
</ol>

3. The `decoding` Attribute for `<img>` Element

The decoding attribute allows you to provide a hint to the browser about how an image should be decoded. This attribute can be added to an <img> element and accepts three values: sync, async, and auto.

sync: Decode the image synchronously, which is the default behavior.
async: Decode the image asynchronously to avoid delaying the presentation of other content.
auto: Let the browser use its default decoding method.

<img src="/images/example.png" alt="Example" decoding="async">

By specifying the appropriate decoding behavior, you can optimize the loading and rendering of images on your web page.

4. The `loading` Attribute for `<iframe>` Element

Similar to lazy loading images, the loading attribute can be applied to <iframe> elements to control when the iframe's content should be loaded. By setting the loading attribute to lazy, you can defer the loading of the iframe until it's about to enter the viewport. This helps improve performance by reducing the initial page load time.

<iframe src="/page.html" width="300" height="250" loading="lazy"></iframe>

5. The `crossorigin` Attribute for Cross-Origin Resource Sharing (CORS)

When working with elements like <img>, <audio>, <video>, <script>, and <link>, you may come across the need for cross-origin resource sharing (CORS). The crossorigin attribute allows you to specify how the resource should be fetched in terms of CORS.

<img src="https://example.com/image.jpg" crossorigin="anonymous" alt="Example Image">

The attribute accepts two values: anonymous and use-credentials. Setting it to anonymous indicates that the resource should be fetched without including user credentials, while use-credentials indicates that the user credentials should be included.

6. The `disablepictureinpicture` Attribute for `<video>` Element

The disablepictureinpicture attribute can be applied to the <video> element to disable the Picture-in-Picture (PiP) feature. PiP allows videos to be displayed in a floating window, but if you want to prevent this behavior, you can simply add the attribute to the video element.

<video src="example.mp4" disablepictureinpicture controls></video>

7. The `integrity` Attribute for Scripts

To ensure that external scripts haven’t been tampered with, you can make use of the integrity attribute. This attribute allows you to provide a cryptographic hash value that the browser can use to verify the integrity of the script file before executing it.

<script src="script.js" integrity="sha256-Kx70Z9jzvYF0Eex8oO7w08=" crossorigin="anonymous"></script>

By including the integrity attribute with the appropriate hash value, you can add an extra layer of security to ensure the script's authenticity.

Conclusion

In this article, we have explored a collection of lesser-known HTML attributes that can enhance your web development projects. From improving user interactions to optimizing resource loading, these attributes provide valuable functionalities that may not be widely known or utilized.

If you find this helpful, please consider subscribing_for more useful articles and tools about web development. Thanks for reading!

Difference Between new Function() and new function() in JavaScript

Zach — Tue, 10 Sep 2024 13:42:14 +0000

JavaScript is indeed flexible, but it also brings some confusion. For example, you can use multiple ways to do the same thing, such as creating functions, objects, etc. So what is the difference between the two mentioned in the title?

new Function is another way to create a function, its syntax:

const func = new Function ([arg1, arg2, ...argN], functionBody);

A simple example:

const sum = new Function('a', 'b', 'return a + b');

sum(1 + 2); // 3

Well, this gives great flexibility. It’s not common, but there are some cases where it can be used. For example, we can use it when we need to dynamically compile a template into a function, which is what Vue.js does as far as I know. Besides that, it can also be used if we need to receive code strings from the server to create functions dynamically.

Let’s quickly talk about its features. See what the code below will output?

globalThis.a = 10;

function createFunction1() {
  const a = 20;
  return new Function('return a;');
}

function createFunction2() {
  const a = 20;
  function f() {
    return a;
  }
  return f;
}

const f1 = createFunction1();
console.log(f1()); // ?
const f2 = createFunction2();
console.log(f2()); // ?

The answer is 10 and 20. This is because new Function always creates functions in the global scope. Only global variables and their own local variables can be accessed when running them.

Whereas new function() is intended to create a new object and apply an anonymous function as a constructor. Such as the following example:

const a = new (function () {
  this.name = 1;
})();

console.log(a); // { name: 1 }

That’s it. Actually, every JavaScript function is a Function object, in other words, (function () {}).constructor === Function returns true.

An associated knowledge point is how to use new Function() to create an asynchronous function? MDN gave us the answer:

// Since `AsyncFunction` is not a global object, we need to get it manually:
const AsyncFunction = (async function () {}).constructor;

const fetchURL = new AsyncFunction('url', 'return await fetch(url);');

fetchURL('/')
  .then((res) => res.text())
  .then(console.log);

If you found this helpful, please consider subscribing to my newsletter for more useful articles and tools about web development. Thanks for reading!

DEV Community: Zach

How AI changed the way I pick frameworks, and the two places React survived

The criteria changed

React is no longer my default: size and performance

The same app, written ten times

I did look at Svelte, Vue, Qwik, and Marko

Astro is smaller than SolidStart. Why not Astro?

The ecosystem bill: TanStack covers the worst of it, components you grow yourself

Styling: utility classes lost the default slot

The rest of the CSS field

Where React still runs

Five rules from three decisions

How I made a Rust hot path 27x faster, and the AI fix I refused to merge

The hot path

v0.0.5 was already fast

The rebuild

The numbers

Why Rust made this safe to do fast

What the agent actually did

The change that looked clean and wasn't

What I cut

How the work was structured

What 1.0 is

The Differences Between "export default xx" and "export {xx as default}"

The Basics of JavaScript Modules

The Behavior of export { xxx as default }

The Behavior of export default xxx

Export Reference Data Types

Best Practices and Recommendations

Conclusion

How does HTTPS work

Why HTTPS?

What is HTTPS?

HTTPS (TLS 1.2) secret

What are symmetric encryption and asymmetric encryption?

What is a CA certificate?

How to check the validity of the CA certificate?

Why is the transmission phase symmetric encryption?

Ditch Git Checkout: Use Git Switch and Git Restore Instead

Conclusion

The Secrets of JavaScript Object Property Order

1. Own properties are array indexes, in ascending numeric index order

2. Other own String properties, in ascending chronological order of property creation

3. Own Symbol properties, in ascending chronological order of property creation

Conclusion

Understanding the infer Keyword in TypeScript

The Infer Keyword

Examples

ReturnType

Parameters

PromiseType

UnboxArray

Limitations

Conclusion

How Server-Sent Events (SSE) Work

What is SSE?

How does SSE work?

Implementing SSE

Use cases for SSE

Benefits of using SSE

Efficiency

Simplicity

Reliability

Conclusion

Ditch dotenv: Node.js Now Natively Supports .env File Loading

Native .env File Handling

Simplified Loading with process.loadEnvFile()

Parsing Environment Variables

Support for Multi-line Values in .env Files

Conclusion

How to Create a Type to Retrieve All Keys of an Object in TypeScript

Overview of the Problem

A Possible Solution

Using the Type

Limitations

Conclusion

7 Lesser-Known HTML Attributes to Enhance User Experience

1. The enterkeyhint Attribute for Virtual Keyboards

2. Attributes for Custom Ordered Lists

3. The decoding Attribute for <img> Element

Native `.env` File Handling

Simplified Loading with `process.loadEnvFile()`

Support for Multi-line Values in `.env` Files

1. The `enterkeyhint` Attribute for Virtual Keyboards

3. The `decoding` Attribute for `<img>` Element

4. The `loading` Attribute for `<iframe>` Element

5. The `crossorigin` Attribute for Cross-Origin Resource Sharing (CORS)

6. The `disablepictureinpicture` Attribute for `<video>` Element

7. The `integrity` Attribute for Scripts