See their events https://html.energy/events.html

What bad patterns are encouraged by design in Rust?

• complicated types
• complicated macro
• premature optimizations with lifetimes among others

Let's create a project and benchmark it :D

tl;dr: the issue isn’t the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.

The experience shows that atomic css files is not optimal.

If the files I was importing were larger, it might make sense. As tiny, modular files? Not so much!
The complete library concatenated and gzipped is less than a single HTTP request. It’s just over 25-percent of the transfer size of sending modular gzipped files instead.

There are many methods that break performance and accessibility such as dynamic css classes and div and span soup.

Topics adressed from the outline:

1. It’s not just bad HTML – it’s meaningless markup
2. Semantic rot wrecks performance
   1. Big DOMs are slow to render
   2. Complex trees cause layout thrashing
   3. Redundant CSS increases recalculation cost
   4. Autogenerated classes break caching and targeting
   5. Animations and the compositing catastrophe (with properties triggering the layout engine)
   6. Autogenerated classes break caching and targeting
3. Semantic tags can provide layout hints
4. (AI) Agents are the new users and they care about structure
5. Structure is resilience, isn't optional

Likewise, content-visibility: auto is one of the most underrated tools in the modern CSS arsenal. It lets the browser skip rendering elements
that aren’t visible on-screen – effectively “virtualising” them. That’s huge for long pages, feeds, or infinite scroll components.

and I didn't know about the contain CSS property.

contain: layout; tells the browser it doesn’t need to recalculate layout outside the element.
will-change: transform; hints that a compositing layer is needed.
isolation: isolate; and contain: paint; can help prevent visual spillover and force GPU layers.

@view-transition {
  navigation: auto;
}

::view-transition-old(root),
::view-transition-new(root) {
  animation: fade 0.3s ease both;
}

@keyframes fade {
  from { opacity: 0; }
  to   { opacity: 1; }
}

To animate a thumbnail between two pages, the <img src=""> tag can be set to view-transition-name: product-image;

This is a microcosm of a much bigger theme: browsers are evolving to reward simplicity and resilience. They’re building for the kind of web we should have been embracing all along. And SPAs are increasingly the odd ones out.

SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.

and I agree, SPAs are overkill for 95%-99% of the websites.

How a rewrite in Rust is beneficial to read many files? Because it avoids allocation.

Note the program was written once in JS then in Rust.

Différent ways to handle errors in Rust.

In favor of the clap crate that allows delevopers to build quickly in Rust.

Structurally speaking, then, a paragraph is a group of related inline elements. In this case, inline words, but it could also include any of the items described as “phrasing content"

<hgroup> issu the tag to use for heading with multiple inline content.

Ok but why o_O

Still interesting, but I already have few use cases for container queries. Maybe because I am too dependent of design that uses screen sizes.

The naive Rust implémentation is 10 times faster than the python one.
It remains 6 times faster than the optimized one.

The Python has a collections.Counter class that is approximately as fast as the naive Rust version.

There are 3 error or exception handling: unchecked exceptions (JS), Checked Exceptions (Go) or an integrated type (Result in Rust) that handle one case or the other.

Explicit is always better.
One thing with an integrated type, is the normal case and the other case. That's a great type to handle more than errors: a lookup of a key in a map, opening a file with a name for which there is no file is normal business. Maybe I will find more.

And for quality software, its function must be so blatantly obvious that everybody thinks: wow, this is trivial code, even a monkey could've programmed this.

All I see so far is this will need more computation or battery drain for this.

The library is available at https://github.com/Specy/liquid-glass

• Call Stack
• Primitive Types
• Value Types and Reference Types
• Explicit, Nominal, Structuring and Duck Typing },
• == vs === vs typeof
• Function Scope, Block Scope and Lexical Scope
• Expression vs Statement
• IIFE, Modules and Namespaces
• Message Queue and Event Loop
• setTimeout, setInterval and requestAnimationFrame
• JavaScript Engines
• Bitwise Operators, Type Arrays and Array Buffers
• DOM and Layout Trees
• Factories and Classes
• this, call, apply and bind
• new, Constructor, instanceof and Instances
• Prototype Inheritance and Prototype Chain
• Object.create and Object.assign
• map, reduce, filter
• Pure Functions, Side Effects, State Mutation and Event Propagation
• Closures
• High Order Functions
• Recursion
• Collections and Generators
• Promises
• async/await
• Data Structures
• Expensive Operation and Big O Notation
• Algorithms
• Inheritance, Polymorphism and Code Reuse
• Design Patterns
• Partial Applications, Currying, Compose and Pipe
• Clean Code

A demo of a vue component built with Liquid Glass Design (iOS 26)

It does not work on my Raspberry Pi yet for atuin
I get a:

atuin: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.39' not found (required by atuin)

A hello world binary works fine though.

1. rustup target add armv7-unknown-linux-gnueabihf
2. sudo apt-get install gcc-arm-linux-gnueabihf libgcc-13-dev-armhf-cross
3. In ~/.cargo/config.toml:

   [target.armv7-unknown-linux-gnueabihf]
   linker = "arm-linux-gnueabihf-gcc"

4. cargo build --target=-armv7-unknown-linux-gnueabihf --target-dir=$(pwd)
5. Upload the binary in armv7-unknown-linux-gnueabihf/debug directory to the raspberry pi and run it.

After a first successful installation, only 4. and 5. are required.