Pas lu, mais ce sera utile pour plus tard.

one [idea] that I’m calling “just call clone (or alias)”. This proposal specializes the clone and alias methods so that, in a new edition, the compiler will (1) remove redundant or unnecessary calls (with a lint); and (2) automatically capture clones or aliases in move closures where needed.

Domain-Specific Languages are small languages designed to focus on a specific aspect of a software system. We deal with DSLs every day: SQL can be considered a DSL, LaTeX is a DSL, AWK is a DSL, Kubernetes’ YAMLs are a DSL.

The Token-Oriented Object Notation is optimized to have fewer tokens to parse for LLMs.

A domain-specific language is by definition smaller in scope than a general-purpose language, so it should be easier to design and implement; moreover, if the language is designed well, it should lead to a more efficient usage of the context window.

If we can abstract away parts of our domain into a higher-level language, we can effectively use the LLM to

1. generate the implementation of a DSL
2. generate documentation and examples for such our DSL
3. point the LLM to docs and examples and prompt it to generate more code using our DSL

So, instead of trying to come up with a general-purpose language for LLMs, we define a tiny DSL for each specific subsystem we mean to realize.

Examples

1. Piano
2. Business Rule

About maintenance: the author claims they can be automated with LLMs.

The cost of defining an external DSL (own language with syntax and parser) is reduced compared to internal DSL (in a generic programming language). Also not a problem with LLMs.

In recent years, there has been something of a “winter” in DSL design and development due to the high maintenance costs and the tooling expectations from end users. This blog post explored the syntactic dimension of “token-efficiency” in DSL design: I invite you to explore more of this space, including semantics; I, for one, will welcome more crazy DSL implementations!

A new API that aims to improve the history API

The author uses a service worker in wasm to render HTML. The service worker syncs the data with the server.

Note fetch requests can be intercepted with the ... fetch event in service workers

The service worker used here is written in Go. Note the "localfirst" approach runs only after the service worker is loaded. The initial page is loaded as simple HTML because of SSR. That's the advantage of WASM: the code runs on the client and the server.

(following https://shaarli.lyokolux.space/shaare/CosnyQ)

There are obvious for me, but they are good.

I see some are totally useless for Rust in comparison. Both have different targets though. It is moreover awesome to see 100x improvements.

How CSS simplify scrollable images with

display: flex;
overflow-x: auto;
overscroll-behavior-inline: contain;
scroll-snap-type: inline mandatory;
scroll-behavior: smooth;

// On the images
scroll-snap-align: center;
 contain: size;
  place-self: stretch;
  object-fit: cover;

Tips and tricks for view transition

In my opinion, the best cases for implementing view transitions are as a way to draw attention to an element, convey movement, and help users remain in context.

Add it to all pages to apply a default cross fade transition.

@view-transition {
    navigation: auto;
}

Then mark similar content with the view-transition-name css property.

Custom view transitions can be made with ::view-transition-old, ::view-transition-new, ::view-transition-image-pair.
Full page transition can be done by marking :root.
These transitions should be set only when the media query prefers-reduced-motion is set to no-preference.

Not read yet.

Nice!

• Indexing into a vector: prefer better pattern matching or raw array with index safety instead
• Lazy use of Default: initialize all fields instead
• Avoid fragile trait implementations that pass silently on changes
• From traits must be infaillible, use TryFrom if any error can occur. Make it explicit.
• Avoid non-exchaustive matches (with _ =>)
• Use decriptive names for unused variables with the _ placeholder.
• Avoid temporary mutability and make it explicit instead: let mut data = ....; .... ; let data = data
• Defensively handle constructors with #[non_exhaustive], so creating an raw instance of a struct should be prohibited outside constructor functions.
• Use #[must_use] to avoid unused instance of the struct.
• Avoid boolean parameters and in case of need, prefer enums.
• Use Clippy lints:
  • clippy::indexing_slicing
  • clippy::fallible_impl_from
  • clippy::wildcard_enum_match_arm
  • clippy::unneeded_field_pattern
  • clippy::fn_params_execussive_bools

Use cases for inherit(). They can be good but I don't see a need currently

There are great animations of ease-in, ease-in-out, ease, spring and bounce. The latest two can not be animated with Bézier curves as other common animations.

To get spring and bounce effects, the linear() function can be used. The linear() function takes a set of numbers, with 0 representing the starting value and 1 representing the final value.

Easing wizard or the Linear() Easing Generator can help.

JSON module imports became baseline: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with:

import data from './data.json' with { type: 'json' };

and lazy-load it with:

const { default: data } = await import('./data.json', {
  with: { type: 'json' },
});

It makes sense to use JSON module imports for local static JSON resources where you need all/most of the data within. Particularly since bundlers can understand JSON imports, and bundle the object with other modules. That isn't possible with fetch(), unless you use some pretty hacky plugins.

Generally, I try to turn any "fetch-and-process" logic into a Vite/Rollup plugin, so it happens at build time rather than runtime.