Wrapping every string to a newtype ensure the string can be extended as wished and at least differenciated from normal strings without meaning

::selection ans ::backdrop does not inherit from root. So :root does not guarantee the CSS variable. The html selector does not solve this.

There is currently no global context in CSS, but root is the best workaround currently.

This is going to catch a lot of people off-guard because I, like many others, expect CSS Custom properties defined on :root to just be available everywhere.

The following discussion is there https://github.com/w3c/csswg-drafts/issues/6641

To prevent a custom behavior on Safari Mobile

Another well written guide for Zod.

Cache-Control can set multiple directives:

• public and private
• max-age defines the amount of time until which the client can consider the response "fresh"
• must-revalidate indicates the HTTP cache should not reuse stale responses when they aer disconnected from the origin server
• no-store disable the cache for the request
• no-cache means ‘do not serve a copy from cache until you’ve revalidated it with the server and the server said you can use the cached copy’. no-cache will always hit the network as it has to revalidate with the server before it can release the browser’s cached copy. It will always hit at least an HTTP header response
• must-revalidate needs an associated max-age directive at which time the browser will revalidate.
• immutable avoid revalidation
• stale-while-revalidate provides is a grace period (defined by us in seconds) in which the browser is permitted to use an out of date (stale) asset while we’re checking for a newer version.
• stale-if-error provides a grace period if the server returns a 5xx error
• I overlooked s-maxage, proxy-revalidate, no-transform (useless for HTTPS) for proxies

Cache Busting strategies:

• no cache busting (dangerous) - style.css
• query string (does not work with proxies, i.e. Cloudflare) - style.css?v=1.2.14
• fingerprint - style.ae3f66.css

Fingerprinting is the best and allow the use of the immutable directive.
Not there is a new Clear-Site-Data: cache in case of need. Browser support is limited.

The post provide examples: Online Banking Page, Live Train Timetable Page, FAQs Page, Static JS (or CSS) App Bundle

These four ways are footguns, but they can be easily spotted in the codebase.

But over time, I think I discovered a better way: a script in my $PATH.

Benefits of scripts over aliases:

• No reloading; changes are picked up immediatly
• Choice of programming language
• Complex logic can be implemented
• More portable between shells

Aliases have certain benefits:

• special syntax (cd.. for cd .. with space)
• completion
• conditional definition
• easier to bypass with unalias
• brevity: it's a one liner
• performance: alias are 100x faster.

getsong make sense and so many useful scripts.

• copy and pasta
• mkcd
• tempe
• trash
• mksh
• serveit starts a static file server
• getsong
• getpod to download something from a podcast player
• getsubs
• wifi off, wifi on and wifi toggle
• url "my_url" parses a URL into its parts.
• markdownquote to add > before every line
• u+ 2025 to get the unicode caracter associated
• snippets to run some snippets
• some REPL launchers for Clojure, Deno, Php, Python and SQLite
• hoy prints the current date in ISO format
• timer
• ocr to extract text from an image
• removeexif to delete EXIF data from images
• emoji fuzzy finder helper https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/emoji

and more Process management scripts

The heap is a performance killer in Rust. One woraround is to swap to a more efficient memory allocator such as jemalloc.

In Cargo.toml:

[dependencies]
mimalloc = "0.1"

In main.rs:

#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

The best performance optimisation is to avoid the heap. There is the heapless create for that. "The only thing to know is that the size of heapless types and collections needs to be known at compile-time."

Lifetime annotations are needed to tell the compiler that we are manipulating some kind of long-lived reference and let it assert that we are not going to screw ourselves

The only downside is that smart pointers, in Rust, are a little bit verbose (but still way less ugly than lifetime annotations). [They add some runtime overhead.]

When to use lifetimes annotations?

When performance really matters or when your code will be used in no_std environments.

I don't know. It seems to be overkill for the use. Instead of words, some functions get a capital letter.

It is currently experimental, but could be amazing because it parse a string of HTML safely and then insert it into the DOM

It uses GSAP

For MacOS only
-webkit-font-smoothing: antialiased;

A great CSS reset

A work to use rust build as PHP extension

It's not available in Firefox yet.

Note: "The key insight is that loading massive files into memory all at once is rarely a good idea, even when technically possible."

1. Read the whole file and call it a day with fs.readFile
2. Read by byte chunks with file handles and buffers
3. (preferred) Use stream

The streams handle the bytes and UTF-8 encoding automatically. Each state can be defined with a callback: error, data, end.
Use appropriate buffer sizes for streams. Default is 64kB. The highWaterMark can adjust it though.

When to use streams: large files, real time data processing, memory is limited, composability, unknown file sizes.
When to use file handles: precise control.
When to use fs/promises: known small files. readFileSync() and writeFileSync() are acceptable for cli tools and scripts, but forbidden for web servers and concurrent apps.

Prefer Promise.all or Promise.allSettled to leverage concurrency.

Handle specific errors. Always. await handle.close() or stream.on('error', () => stream.destroy()). Another solution is await pipeline(source, transform, destinationl)