DEV Community: Zeeshan

Rust for JavaScript Developers: The 2026 Migration Guide

Zeeshan — Tue, 08 Sep 2026 16:53:16 +0000

Rust for JavaScript Developers: The 2026 Migration Guide

Rust is everywhere in the JS ecosystem now — bundlers, compilers, linters, and the runtimes you deploy to are increasingly written in it. You do not need to abandon JavaScript to benefit. But learning Rust is easier if you map it onto concepts you already understand.

The mental model shift

JavaScript is dynamic: types live at runtime, and you can mutate anything. Rust is the opposite — types are checked at compile time, and correctness is enforced before your program runs. Think of it as TypeScript with the training wheels off and memory safety baked in.

Ownership instead of garbage collection

The biggest jump. JavaScript has a garbage collector; Rust does not. Instead, every value has one owner, and ownership can be moved. When you don't need a value, it is dropped automatically.

let s = String::from("hello");
let t = s;            // s is MOVED into t, s is now unusable
// println!("{}", s); // compile error: value borrowed/moved

It feels restrictive until you internalize it: "who owns this, and can I borrow it?" Most Rust errors during the learning phase are ownership errors, and the compiler tells you exactly what to do.

The amazing part: the compiler as mentor

The Rust compiler (rustc) is legendary for its error messages. It does not just say "error" — it explains the problem and suggests the fix. For a JavaScript developer, this turns the compiler into a pair programmer. The first week you'll fight it; by week two you'll trust it.

Borrowing: the currency of the language

fn print_len(s: &str) {           // borrow, don't own
    println!("{}", s.len());
}

&str is a borrow — read-only access without taking ownership. &mut is a mutable borrow — exclusive write access. The rules: either you can borrow immutably many times, or mutably once. This is what kills data races at compile time.

Structs and enums replace the JS toolkit

struct ≈ a typed object/class shape.
enum ≈ an object that is exactly one of several variants (like a discriminated union in TypeScript, but exhaustive — the compiler checks every case).
match ≈ switch, but exhaustive: the compiler forces you to handle every variant.

Error handling: `Result` instead of `try/catch`

JavaScript throws exceptions. Rust returns Result<T, E>. You process it with ? or match:

use std::fs;

fn read() -> Result<String, std::io::Error> {
    fs::read_to_string("config.toml")  // returns Result
}

The ? operator unwraps success or early-returns the error. It's explicit, and the type system tracks exactly what can fail.

When to actually use Rust

Performance-critical hot paths in bundlers, parsers, or APIs.
WebAssembly — compile one Rust module and run it in browser, edge, and server.
CLI tools — small, fast, single-binary utilities.
Safety-critical logic where a bug in a data race is unacceptable.

For the rest — UI, glue, quick prototypes — JavaScript/TypeScript is still the right tool. You are not choosing; you are adding a tool.

How to start

Install via rustup. Run cargo new hello.
Pick a small task you already know in JS (parse some data, write a CLI) and port it.
Read the ownership chapter of the Rust Book when you hit borrow errors.
Let the compiler mentor you — read every error message it prints.

You'll find the syntax familiar and the guarantees liberating. The friction is real, but it is upfront — and it buys you correctness and speed that JavaScript's runtime-checking simply cannot offer.

Serverless Is Over — Long Live Compute-at-the-Edge

Zeeshan — Tue, 08 Sep 2026 16:52:28 +0000

Serverless Is Over — Long Live Compute-at-the-Edge

"Serverless" was the most important deployment model of the last decade. It solved operations by hiding servers. But it created its own problems — cold starts, vendor lock-in, and a fixed set of regional origins. The industry quietly moved past it into something better: portable compute wherever the user is.

The serverless bargain

Serverless functions (AWS Lambda, Azure Functions) trade operational freedom for a runtime you don't manage. You get auto-scaling, pay-per-invocation, and zero infrastructure. The cost: cold starts, request-based limits, and code that lives in one vendor's event loop.

Where it broke down

Cold starts made inconsistent latency the norm, especially for dependencies-heavy runtimes (Python, Node with frameworks).
Lock-in — a Lambda handler is not portable without a shim.
Regional origins — a function deployed in one region adds network round-trips for users elsewhere.
Concurrency ceilings — the auto-scaling has hard limits that surprise high-traffic apps.

What replaced it: the edge runtime

The edge era (Cloudflare Workers, Fastly Compute, Deno Deploy, Fly) moved execution to the network closest to the user. Two changes matter more than any feature list:

Portable Web-standard runtime. You write JavaScript/TypeScript (or any language compiled to Wasm) against the Web Request/Response APIs — the same everywhere.
Sub-millisecond cold starts. Tiny isolates without per-request function spin-up. Latency is measured from the nearest region, not the origin.

The result

An API served from a PoP in Tokyo answers a user in Tokyo without touching a US region.
You can deploy the same code to Cloudflare, Fastly, and your own Wasm runtime with one artifact.
No more "warm up a function" hacks — the platform starts fast by design.

Was "serverless" actually over?

Not dead — Lambda remains a workhorse for scheduled jobs, queues, and internal glue. But as the default for user-facing HTTP, it lost to the edge. The edge is what functions wanted to be: on-demand, auto-scaling, and now truly fast and portable.

Practical takeaways

For new user-facing services, start at the edge. The latencies and portability are strictly better for most workloads.
Keep long-running jobs and heavy batch work on a classic runtime — the edge isn't built for them.
Write against the Web-standard API surface so migration between providers is cheap.
Prefer portability over single-vendor convenience.

The cloud didn't disappear. It moved to where the users are, and it got much faster doing it.

TypeScript 5.7 and 5.8: What Developers Actually Need to Know

Zeeshan — Tue, 08 Sep 2026 16:45:17 +0000

TypeScript 5.7 and 5.8: What Developers Actually Need to Know

TypeScript releases ship every few months now. Some are foundational; others are niche. These two had both — and a few features that are easier to ignore than use.

The changes that matter

Disallow nullish-coalescing assignment (`??=`) errors

TypeScript 5.7 enforced stricter nullish-coalescing assignment. Code like x ??= x (assigning to itself) is now caught. The underlying reason is that ??= silently does nothing if x is not nullish — a common source of subtle bugs. This is a real quality-of-life improvement.

Improved inference in `return` type narrowing

TypeScript 5.7 improved type narrowing inside switch(true) and chained if blocks. Before, you had to manually cast types inside complex branching. Now the compiler tracks the narrowing across comparisons correctly. This reduced the number of as casts in real codebases significantly.

Typed `import.meta.env` and `import.meta.resolve`

In 5.8, TypeScript gained typing for import.meta.env (Vite, Deno) and import.meta.resolve. The ecosystem already relied on these — now the types are native instead of requiring manual declare blocks in .d.ts files.

Decorators metadata and type import fixes

A small but critical fix: type-only imports used inside decorator metadata were previously erased incorrectly. The 5.7 fix makes decorator metadata production-safe, which matters for NestJS and similar frameworks.

What didn't change much

`enum` semantics

Despite years of community debate, TypeScript enums are still transpiled as JavaScript objects. No new semantic changes. Use as const if you want stricter behavior.

`strictNullChecks` performance

No significant improvement. The strictness is worth the cost, but the cost hasn't gone down.

JSX and React types

Nothing changed in 5.7 or 5.8 about JSX typing. The ecosystem moved to React 19 types separately.

What to do

Run npx tsc --version and upgrade. The migration from 5.6 to 5.8 is usually zero-effort.
Remove as casts that are now inferred correctly (search for as string, as number in your codebase).
Clean up manual declare const import.meta.env in .d.ts files — TypeScript handles it now.
Test any NestJS or decorator-heavy code before deploying; the metadata fix may change runtime behavior.

The practical takeaway

TypeScript releases are getting more incremental and more mature. The big architectural shifts happened years ago; what's left is tightening inference, fixing edge cases, and aligning with how the ecosystem actually uses the language. Upgrade, run your tests, and enjoy fewer as casts.

The State of CSS in 2026: What Actually Changed

Zeeshan — Tue, 08 Sep 2026 16:43:04 +0000

The State of CSS in 2026: What Actually Changed

CSS went through a period where every browser shipped different experimental features. That era is effectively over. The features that stuck changed how we write stylesheets — and the ones that didn't taught useful lessons.

What shipped and actually matters

Nesting (native)

.card { background: white; }
.card h2 { margin: 0; }

became:

.card {
  background: white;
  & h2 { margin: 0; }
}

Native nesting eliminates the reason many teams reached for Sass. The syntax is simpler, there is no build step, and the cascade still works normally.

Container queries

Instead of "if the viewport is narrow, change the layout," you write "if the container is narrow, change the layout." This solved a real architectural problem that media queries never addressed.

`:has()`

The "parent selector" that developers asked for since 1998. :has(.empty) { } styles a container only when it contains an empty element. Simple, obvious, powerful.

Cascade layers (`@layer`)

Explicit control over specificity without !important wars. Define layers, import third-party styles into a low-priority layer, and your component styles win predictably.

What shipped but mostly didn't matter

Anchor positioning: technically impressive, almost no one uses it for real UIs.
View transitions API (CSS part): great for slideshows and single-page apps; the CSS surface is narrow.
@scope: the idea is right, but standard class scoping already covers most real needs.

What the tooling shift looked like

The bigger change isn't a feature — it's that the design-system ecosystem converged on:

component-level styles with container queries
layer-organized third-party imports
:has() for conditional styling
native nesting for organization

Most utility-first frameworks adopted these patterns. Most teams stopped fighting the cascade.

What to do if your CSS feels outdated

Replace your Sass nesting with native CSS nesting.
Convert "viewport breakpoints" to container queries wherever a component is reused at different sizes.
Use @layer to tame third-party stylesheet conflicts.
Replace JavaScript parent/child detection with :has().

The language is mature enough that the best code is shorter, clearer, and more portable than it was five years ago.

Zero-Knowledge Proofs Explained for Developers

Zeeshan — Tue, 08 Sep 2026 16:35:17 +0000

Zero-Knowledge Proofs Explained for Developers

Zero-knowledge (ZK) proofs were theoretical math for decades. Now they power privacy, scalability, and identity systems — and the tooling has caught up to the hype.

The core idea, in one sentence

A zero-knowledge proof lets you convince someone that a statement is true without revealing anything except the fact that it is true.

The classic example: prove you know a password without sending the password. More practically: prove your account balance exceeds a threshold without revealing the balance.

The three properties

Completeness — if the statement is true, an honest prover can convince the verifier.
Soundness — if it is false, no cheating prover can convince the verifier (beyond negligible chance).
Zero-knowledge — the verifier learns nothing beyond the truth of the statement.

Real use cases in 2026

Private finance

Prove a loan application meets income requirements without exposing income. Prove solvency on-chain without revealing positions.

Scalability (validity rollups)

A rollup computes thousands of transactions off-chain, then publishes one small proof that the state transition is correct. The main chain verifies the proof instead of replaying everything. This is how cheap, fast layer-2s work today.

Identity and credentials

Prove you are over 18, a licensed professional, or a member of an organization — without revealing your ID or birthdate.

AI / ML integrity

Prove that a given model output was produced by a specific model on specific inputs, without revealing the model or the inputs.

What developers need to understand

The proving problem vs. the verification problem. Proving is computationally expensive (seconds to minutes for real workloads). Verification is cheap (milliseconds). Architecture decisions flow from this asymmetry.
Trusted setup vs. transparent systems. Some schemes need a one-time "ceremony" generating a trusted parameter; newer systems remove it entirely.
Proofs compose. You can fold, aggregate, and combine proofs, which is why the whole validium/rollup design space opened up.

The honest complexity

ZK is not magic, and it is not free. The tradeoffs are proving time, proof size, and the expressiveness of what you can prove. The field has moved from "can it be done?" to "how fast and how cheap can we make it?" — a sign the tech has crossed into real engineering territory.

Where to start

Begin with a small circom or arkworks circuit proving something trivial (like "I know a hash preimage"), watch the proving time and proof size, and then read how a validity rollup reuses that workflow at scale. The concepts are simpler than the marketing suggests — the math is hard, but the developer flow is now surprisingly accessible.

WebAssembly in 2026: Why It's Suddenly Everywhere

Zeeshan — Tue, 08 Sep 2026 16:35:08 +0000

WebAssembly in 2026: Why It's Suddenly Everywhere

WebAssembly (Wasm) started as a way to run C++ in the browser. It has become a general-purpose runtime for the entire backend — and it is now genuinely difficult to avoid.

What WebAssembly actually is

Wasm is a bytecode format with a sandboxed execution model. It runs a compiled, statically-typed program inside a memory-safe, capability-limited sandbox. Originally built into browsers, the same binary format now runs on servers, edge networks, blockchains, and embedded devices.

The key property is determinism and isolation: a Wasm module cannot access the host system unless the host explicitly grants it an interface.

Where it matters in 2026

In the browser

Video editors, design tools, PDF viewers, and language runtimes (Python, Rust, Go compiled to Wasm) run at near-native speed. The browser gap — apps that feel like desktop software — is largely closed by Wasm.

At the edge

Edge functions (Cloudflare Workers, Fastly Compute, Fly Machines) execute Wasm modules close to the user with sub-millisecond cold starts. Polyglot functions written in any language compile to a single portable artifact.

As the universal backend

Wasi (the WebAssembly System Interface) standardized files, sockets, and clocks. Server-side Wasm gives you one compile target that runs identically across providers — a genuinely portable cloud.

In blockchains

Smart-contract chains use Wasm because it is deterministic and auditable. The same module that runs off-chain in a test runs on-chain in the ledger.

The developer experience today

Write in Rust, Go, C, C++, AssemblyScript, or even Python. Compile to a .wasm file with one target. Ship the same artifact to browser, edge, and server. Tooling (wasm-tools, wasmtime, wasi-sdk) is stable and documented.

What changed recently

Component model: standardized interfaces so modules can share types and call each other safely.
Garbage collection (GC) support means managed languages like Java, Dart, Kotlin run without hacks.
Multi-value returns, tail calls, and wider SIMD closed the "Wasm is slower than native" gap.
Server-side Wasm runtimes hit production-grade stability in memory management and concurrency.

Why it matters for engineers

Skill in Wasm is a durable investment. The model — compile once, run anywhere, sandboxed by default — is the direction the whole industry is moving. Whether you target browsers, edge compute, or ledger runtimes, the same mental model applies.

Where to start

Take a small Rust or Go program and compile it to Wasm.
Run it locally with wasmtime run.
Deploy the identical artifact to an edge worker.
Then try it in the browser with a quick fetch module.

You will quickly notice what the whole industry noticed: one artifact, no host coupling, and a sandbox that makes security easier, not harder.

Solana Deep Dive: Can It Compete With Ethereum in 2026?

Zeeshan — Tue, 08 Sep 2026 16:29:00 +0000

Solana Deep Dive: Can It Compete With Ethereum in 2026?

Solana promised Ethereum-level functionality at Web-scale speed. Years later, how does it actually compare?

What Solana does differently

Solana uses a proof-of-history consensus design plus a single global state to reach high throughput without sharding. Transactions finalize in under a second in most conditions, and fees typically cost fractions of a cent.

Ethereum takes the opposite approach: a giant, battle-tested settlement layer where security and decentralization trump raw speed. Layer-2 rollups carry most activity, leaving the base chain as a finality and security anchor.

The honest numbers

Throughput: Solana's peak is far higher than Ethereum's base layer, but L2s narrow the gap.
Fees: Solana is cheaper for high-frequency trading and consumer apps; Ethereum L2s are cheap for most users too.
Uptime: Solana has had visible outage incidents; Ethereum's base layer is famously hardened.

Where Solana wins in 2026

DeFi trading and market-making need low latency — Solana is a clear winner there.
Consumer-facing apps with millions of micro-transactions fit Solana's model.
The developer toolchain (Anchor, the JS API) has matured significantly.

Where Ethereum still wins

Institutional trust: its track record and security make it the default "serious" chain.
Network effects: the largest developer community, tooling, and existing deployed code.
Rollup ecosystem: a rich L2 landscape that scales without touching base-layer consensus.

So who should care?

A trader or consumer-app builder should evaluate Solana seriously — speed and cost matter.
A protocol looking for permanence and familiarity usually still chooses Ethereum.

The pragmatic take

You do not need to choose a single winner. Solana and Ethereum solve different problems and coexist. Chain maximalism is a spectator sport; builders use what fits the product. Understanding both — their fees, latency, tooling, and failure modes — beats betting on either.

Altcoins Explained: Which Crypto Projects Actually Have Use Cases in 2026?

Zeeshan — Tue, 08 Sep 2026 16:27:56 +0000

Altcoins Explained: Which Crypto Projects Actually Have Use Cases in 2026?

Thousands of cryptocurrencies compete for attention, but only a fraction drive real usage. This guide separates signal from noise.

What is an altcoin, really?

An altcoin is any cryptocurrency other than Bitcoin. The term covers everything from payment networks (Litecoin, Monero) to smart-contract platforms (Ethereum, Solana) to tokens that exist mainly as speculative vehicles.

The three questions to ask

Who pays for this? Real projects have paying users — developers, enterprises, or consumers. Check if revenue flows in.
What problem does it solve? A chain that is "fast and cheap" solves nothing on its own. Who needs speed, and for what?
Does the community survive a bear market? Developer activity is a leading indicator. Empty GitHub repos signal trouble.

The categories that matter in 2026

Smart-contract platforms

Ethereum remains the settlement layer for most decentralized finance. Solana offers high throughput and low fees for consumer apps. Each competes on developer experience and actual usage, not marketing.

Stablecoins

Stablecoins like USDC are the workhorse of crypto payments — they move billions daily as a settlement rail. They are less "speculative" and more infrastructure.

Utility tokens

The honest utility tokens are those whose fee revenue is shared with holders. Everything else is governance theater.

Meme coins

Tokens without a use case are the most volatile — and the most likely to go to zero. Treat them as entertainment, not investment.

Risk checklist before buying anything

[ ] Is the code open source and still maintained?
[ ] Are large holders transparent?
[ ] Does the burn/supply schedule make sense?
[ ] Would you still hold if the token went quiet for a year?

The bottom line

Altcoins are a lottery ticket for most people and infrastructure for a few. If you cannot articulate who pays for the network and why, you are speculating — not investing. The safest position in crypto remains understanding stablecoins and one or two smart-contract platforms deeply before touching anything else.

Stablecoins Explained: A Practical Guide for 2026

Zeeshan — Tue, 08 Sep 2026 16:02:31 +0000

Stablecoins Explained: A Practical Guide for 2026

Stablecoins have become the backbone of crypto. They are used for cross-border payments, DeFi, and as a dollar-equivalent in countries with unstable currencies. But not all stablecoins are the same, and understanding the differences matters.

What Is a Stablecoin?

A stablecoin is a cryptocurrency designed to maintain a stable value relative to a reference asset — usually the US dollar. It allows moving dollars on a blockchain without the price volatility of Bitcoin or Ethereum.

The Major Players in 2026

USDC (Circle)

Backed 1:1 by short-term US Treasuries and cash
Published monthly attestations (audited by Deloitte)
Strong regulatory posture, used widely in institutional DeFi

USDT (Tether)

The largest stablecoin by market cap
Backing is more opaque — quarterly attestations but not a full audit
Dominant in Asia and on centralized exchanges

DAI / USDS (MakerDAO)

Decentralized and over-collateralized
Backed by a mix of crypto assets in smart contracts
More complex but less dependent on a single issuer

New Entrants

Protocol-native stablecoins (GHO, crvUSD, PYUSD) are growing
They use different mechanics but follow the same principle: maintain a peg through collateral or algorithm

The Risks Nobody Talks About

Reserve risk. A "fully backed" claim is only as good as the audit and the jurisdiction of the reserves.
Depegging risk. USDC briefly depegged during the SVB crisis. Even the best stablecoin is not risk-free.
Smart contract risk. Decentralized stablecoins can have exploits. Always assess the protocol's audit history.
Regulatory risk. New laws in the US or EU could restrict certain stablecoins.

Practical Advice

Hold stablecoins in a wallet you control, not just on an exchange.
Diversify across two issuers if holding significant amounts.
Use USDC for transparency, USDT for trading on Asian exchanges, DAI for DeFi.
Never park your entire net worth in any single stablecoin.

The Bottom Line

Stablecoins are essential infrastructure for the crypto economy. Choose based on transparency, auditability, and use case — not just market cap. Diversify, understand the risks, and treat them as what they are: useful but imperfect instruments.

This is educational content, not financial advice. Always do your own research.

Are AI Crypto Trading Bots Worth It in 2026? An Honest Breakdown

Zeeshan — Tue, 08 Sep 2026 16:02:26 +0000

Are AI Crypto Trading Bots Worth It in 2026? An Honest Breakdown

Every new crypto cycle brings a fresh wave of "AI trading bot" hype. By 2026 the marketing is louder than ever: fully autonomous agents, zero-effort passive income, "set it and forget it." But the reality is more nuanced. Here is the honest breakdown from someone running multiple automated strategies.

What a Trading Bot Actually Does

At its core, a crypto trading bot automates a strategy. It watches market data, applies a set of rules, and executes trades faster than a human. That is it. The "AI" layer sits on top — pattern recognition, sentiment analysis, risk management.

What Actually Works

Disciplined, rules-based strategies. Bots shine when they remove emotion. A stop-loss or take-profit that a bot enforces is one you actually follow.
Market making and arbitrage. These are quant plays where speed genuinely matters. Bots are the only way to do them.
24/7 markets. Crypto never closes. Bots manage positions while you sleep.

What Is Overhyped

"Guaranteed returns" claims. No legitimate bot guarantees profit. If it does, it is a scam.
Predicting the future. No model predicts prices with certainty. Good bots manage risk, not predict.
Passive income with no monitoring. Every strategy needs oversight. A bot amplifies your strategy; it does not replace your judgment.

Avoiding the Traps

Check the team behind the bot. Anonymous developers with huge returns? Run.
Never hand over withdrawal permissions. A bot should trade with what you fund, not have full control of your wallet.
Start small. Paper-trade first, then allocate capital you can afford to lose.

The Bottom Line

Trading bots are tools, not money printers. Used with a clear strategy and proper risk management, they can add consistency. Approached as "jab the button and get rich," they will cost you. The most profitable traders in 2026 are not the ones with the fanciest bots — they are the ones with the best risk discipline.

This is educational content, not financial advice. Always do your own research.

DEV Community: Zeeshan

Rust for JavaScript Developers: The 2026 Migration Guide

Rust for JavaScript Developers: The 2026 Migration Guide

The mental model shift

Ownership instead of garbage collection

The amazing part: the compiler as mentor

Borrowing: the currency of the language

Structs and enums replace the JS toolkit

Error handling: Result instead of try/catch

When to actually use Rust

How to start

Serverless Is Over — Long Live Compute-at-the-Edge

Serverless Is Over — Long Live Compute-at-the-Edge

The serverless bargain

Where it broke down

What replaced it: the edge runtime

The result

Was "serverless" actually over?

Practical takeaways

TypeScript 5.7 and 5.8: What Developers Actually Need to Know

TypeScript 5.7 and 5.8: What Developers Actually Need to Know

The changes that matter

Disallow nullish-coalescing assignment (??=) errors

Improved inference in return type narrowing

Typed import.meta.env and import.meta.resolve

Decorators metadata and type import fixes

What didn't change much

enum semantics

strictNullChecks performance

JSX and React types

What to do

The practical takeaway

The State of CSS in 2026: What Actually Changed

The State of CSS in 2026: What Actually Changed

What shipped and actually matters

Nesting (native)

Container queries

:has()

Cascade layers (@layer)

What shipped but mostly didn't matter

What the tooling shift looked like

What to do if your CSS feels outdated

Zero-Knowledge Proofs Explained for Developers

Zero-Knowledge Proofs Explained for Developers

The core idea, in one sentence

The three properties

Real use cases in 2026

Private finance

Scalability (validity rollups)

Identity and credentials

AI / ML integrity

What developers need to understand

The honest complexity

Where to start

WebAssembly in 2026: Why It's Suddenly Everywhere

WebAssembly in 2026: Why It's Suddenly Everywhere

What WebAssembly actually is

Where it matters in 2026

In the browser

At the edge

As the universal backend

In blockchains

The developer experience today

What changed recently

Why it matters for engineers

Where to start

Solana Deep Dive: Can It Compete With Ethereum in 2026?

Solana Deep Dive: Can It Compete With Ethereum in 2026?

What Solana does differently

The honest numbers

Where Solana wins in 2026

Where Ethereum still wins

So who should care?

The pragmatic take

Altcoins Explained: Which Crypto Projects Actually Have Use Cases in 2026?

Altcoins Explained: Which Crypto Projects Actually Have Use Cases in 2026?

What is an altcoin, really?

The three questions to ask

The categories that matter in 2026

Smart-contract platforms

Error handling: `Result` instead of `try/catch`

Disallow nullish-coalescing assignment (`??=`) errors

Improved inference in `return` type narrowing

Typed `import.meta.env` and `import.meta.resolve`

`enum` semantics

`strictNullChecks` performance

`:has()`

Cascade layers (`@layer`)