Postuler que la publicité est un business « honnête » revient à dire que ces milliards d’euros ne seraient pas dépensés sans elle. Et donc revient à démontrer que la publicité appauvrit la population d’une manière démentielle en entrainant une surconsommation qui détruit littéralement la planète.

Lorsque vous achetez des publicités chez un de ces géants, tout ce qu’ils vous offrent en échange sont… des chiffres qu’ils inventent.

Parce que ce sont des boîtes noires et que personne ne peut vérifier le nombre d'affichage, etc...

Le géant Procter&Gamble a d’ailleurs annoncé avoir coupé complètement tous ses budgets publicitaires pour les réseaux sociaux et n’avoir perçu absolument aucune différence dans les ventes.

Avec mes 2500 followers sur Facebook, j’avais découvert à l’époque que chaque message touchait en moyenne 1%, mais que, en payant, je pouvais monter à 5% voire 10% de « ma communauté ». Facebook me faisait croire que j’atteignais un public alors qu’en réalité, je devais payer pour contacter moins de gens que si je leur avais conseillé de s’abonner par mail ou RSS.

En fait, de manière générale, tout fournisseur qui prétend vous vendre l’observation de métriques décidées par lui, mesurées par lui et optimisées par lui est par essence un escroc.

Briser l’incroyable puissance de ces monopoles morbides ne passe pas par l’utilisation d’alternatives ou de succédanés, mais par la réalisation profonde que nous n’avons tout simplement pas besoin d’eux.

Clever and efficient

There is an alternative to the SPA model: a new model with HTML only. It uses modern DOM-swapping interactivity libraries like Hotwire, HTMX, and Unpoly and... something that returns HTML as backend :)

Since version 7.0 has Ruby on Rails Hotwire backed-in!

1. SSR and Jamstack

2. Active Memory Caching

In summary, if you want to increase the performance of your application, you can use server caches to speed up your APIs, but if you want to persist your app state, you should use the local storage cache.

3. Data Event Sourcing

Useful for real-time applications. Connections are made with Websockets.

4.a Prefetching

Pros: Prefetching waits until the browser’s network is idle and is no longer in use and will stop when you trigger usage by clicking a link or triggering a lazy loading function.
Pros: Prefetching caches data within the browser, making page transitions faster when redirecting to a link.

4.b Lazy Loading

Lazy loading can only help you delay downloading resources and doesn’t make your resources smaller and more cost-efficient.

5. Resumability

Essentially, Resumability uses the server to do the heavy lifting and then gives the client a minimal amount of JavaScript to execute via serialization.

A captcha with proof of work (~2s). This can definitely be better for every user as they do nothing. It's free software, privacy-friendly, and it doesn't use IP addresses (so users won't suffer what reCaptcha or CloudFlare impose).

They have a GitHub organization: https://github.com/mCaptcha

A way to avoid to pull with a request at regular intervals:

• the user subscribe to events similar to JS Events
• the server send them at its pace

Stats are there for the year 2022, and updated yearly. A mine of resources.

I find it hard too :/

Rule of thumbs:

1. Show errors immediately if issues are severe
2. Late validation is almost always better
3. Validate empty fields only on submit
4. Reward early, punish late: if a user edits an erroneous field, we should be validating immediately, removing the error message and confirming that the mistake has been fixed as soon as possible (reward early). However, if the input was valid already and it is being edited, it’s probably better to wait until the user moves to the next input field and flag the errors then (punish late).
5. Validate after a copy-paste
6. Allow users to override inline validation
7. Just in time validation
8. For short forms, consider validation on submit only. For complex forms, use the task list pattern

These statements of architectural principle explain the thinking behind the specifications. These are personal notes by Tim Berners-Lee: they are not endorsed by W3C on anyone else. They are aimed at the technical community, to explain reasons, provide a framework to provide consistency for future developments, and avoid repetition of discussions once resolved.

Examples of original icon hover effects 👍

Examples of original button effects 👍

Examples of original link effects 👍

Two circular navigation demos

A demo of 3 types of navigation menu with sublebels:

1. Overlapping levels
2. Covering levels
3. Overlapping levels with backlinks

J'utiliserais actuellement plus Astro, mais à voir

Improved list designs. It's refreshing.

Retrieve the background and text colors of a page, its typography (Font, Style, Size, Leading, Colour), and image dimensions. The idea is great 👍‍

This tool can be improved with more data about the page #idea #project

It's hard to debate about the best technologies. So here are a summary of the arguments of the author.

Main Argument: React isn't great at anything except being popular.

• React is good.
• React laid down the groundwork for other web frameworks. Vue 3 and React hooks, Svelte's conventions from React, Nuxt from Next, ... The component based-model owes much to React-
• React’s greatness is more in what it meant at the time than what it currently is today, absent that context
• React has aged. And I don't think most people—particularly those using it regularly—realize how much or how poorly. → when you live in the React world, you only see improvements. It shields you from React's velocity compared to other frameworks.
• React doesn’t do anything better than other frameworks.

On a greenfield project, how do you make the call on the front-end framework you'll use for the next several years? Things to consider:

• Performance → Vue, Svelte, Solid, Inferno and a host of others generally provide markedly better performance than React.
• Learning curve → JSX allows HTML into a JS function. The only thing worse than using JSX with React is not using JSX with React. Many things other front-end frameworks handle for you or make trivially easy require manual intervention or significant boilerplate. React is built for Facebook, others frameworks for the world.
• Bundle size: not the smallest
• Scalability: React doesn’t have anything special here; it just has the most examples.
• Community and support: does not mean a better choice. A big community can be a downside, too, especially in the case of a so-called “unopinionated” framework such as React. It can mean too many packages to choose from, and too many different, competing opinions that you’ll have to decide between and take a stance on.
• Financial backing: Vue is one of the most successful and well-funded open-source projects in history. [Through examples] backing is not an issue among major front-end frameworks
• Developer experience: React placed behind both Solid and Svelte in terms of satisfaction in this year’s State of JS Survey results. React also placed behind Svelte, Solid and Vue in terms of interest React's satisfaction and interest have been declining steadily for years, while its usage has flatlined.
• Hireability: This is the one area where React definitively comes out ahead. If you need to hire a dev who knows your thing already, React is clearly the choice.
• vs Competitors: But bear in mind that choice also gives you absolutely no tech advantage over your competitors. They’re all (mostly) using React, too.

Why react stays on top?
Because we don’t always value the strongest choice as much as we value consensus.
One other thought here: it’s possible we’re already moving past React, but we just can’t see it at a high level yet.

• Versatile: we use the web for many things
• Decentralized: there is no one single arbiter
• Resilient: the development is hostile as there is a lot to consider such as multiple browsers, network condition, input modes, and third-party scripts,...
• Responsive: there is a responsive design on the web
• Adaptable: range of form factors, device capabilities, and specialized browsing modes.
• Accessible or at least can be accessible: It represents a rare space where a disabled individual may operate free from the immense amount of bias, misunderstanding, and outright hate that is pervasive throughout much of society.
• Inexpensive: the fact remains that you can achieve an incredible amount of functionality with a small amount of code. There is ~$40 for internet-ready smartphones.
• Diverse: the list of browsers is huge. This diversity encourages innovation.
• Standardized: with the w3c. It is well documented with the Mozilla Developer Network, StackOverflow, and blogs, ... Plus 20 years old web pages are still usable today.
• Open: the standardization and consensus are transparent. it helps to disincentive more abstract threats like adversarial interoperability. OSS FTW.

Create Beautiful Fullscreen Scrolling Websites

fullPage.js is designed to be easy to use and customize. It includes tens of examples, great documentation, and both community and personal support.

The project is useful websites similar to slides or demos.