Le framework pour application Tauri prend de plus en plus de maturité pour remplacer notamment Electron.
Concrètement le backend de l'application est à écrire en Rust et le frontend peut être en Javascript (React, Vue, Angular, etc).
Les deux vont communiquer via une API RPC:
// (Rust) Tauri command
#[tauri::command]
fn return_string(word: String) -> String{
return word
}
// (Javascript) Command invocation
const result = await invoke("return_string", {
word: "This is the argument"
});J'espère sincèrement que ça prendra car les application Electron sont vraiment trop lourdes avec des appli comme Slack qui sont régulièrement à ~15-20% du CPU même en idle (!!).
Un autre runtime Javascript côté serveur concurrent à Node.js.
C'est assez intéressant car Bun est développé from scratch (en Zig), et il n'est pas basé sur le moteur Javascript v8 de Chrome mais sur JavascriptCore, celui de Safari.
Dans les promesses de Bun:
- Plus rapide et moins de mémoire consommé que Node.js
- Transpiler et bundler intégré
- Compatible avec l'écosystème (node_modules et NPM)
Le projet est encore en cours de développement (voir ce qu'il manque) et donc pas encore recommandé pour de la production.
Un jeu pour apprendre à utiliser Git !
Ce qui est génial c'est de pouvoir visualiser l'évolution des structures internes à chaque commande 😄
Un autre excellent site pour apprendre Git visuellement: https://learngitbranching.js.org/
Et un autre site pédagogique visuel en mode bac à sable: https://git-school.github.io/visualizing-git/
Ce sont ceux que j'utilisais lorsque je donnais des cours mais aujourd'hui je conseillerais d'utiliser Oh My Git plutôt :-)
Une autre tentative de framework fullstack mais cette fois en utilisant un langage de haut niveau pour décrire une application.
Le "compilateur" Wasp (plutôt un générateur) va ensuite générer le code backend (Node.js), frontend (React) et le modèle de données (Prisma ORM).
C'est intéressant comme démarche mais à priori je vois deux limitations importantes:
- introduction d'un nouveau langage dans la stack (qui plus est un langage peu mature)
- manque de personnalisation du code généré (pour aller au delà du CRUD quoi)
Ça ressemble à ça le WASP:
// file: main.wasp
app TodoApp {
title: "Todo App"
}
route RootRoute { path: "/", to: MainPage }
page MainPage {
component: import Main from "@ext/pages/Main.js" // Importing React component.
}
query getTasks {
fn: import { getTasks } from "@ext/queries.js", // Importing NodeJS code.
entities: [Task]
}
entity Task {=psl
id Int @id @default(autoincrement())
description String
isDone Boolean @default(false)
psl=}
Des exercices pour progresser avec l'utilisation des types en TypeScript !
Grâce aux corrections c'est aussi une très bonne source d'informations pour résoudre des problèmes de définition de types 🔥
Les Service Workers ne vont pas magiquement améliorer les performances d'une application notamment car l'envoi de données entre les processus (postMessage) est relativement lente comme tous les autres mécanismes d'Inter Process Communication (IPC)
En général pour faire des calculs intensifs il est préférable de le faire durant le temps restant après que le navigateur ait terminé le rendu d'une frame de la page Web avec requestIdleCallback
Un meta article qui résume pleins de choses sur les Service Workers des navigateurs.
Très bon explication sur les différences entre les Map et les POJO en Javascript.
En substance:
- utilisez les POJO lorsque le nombre de clé est connu d'avance et en tant que Data Transfer Object (DTO)
- utilisez les
Mappour tout ce qui s'apparente à un cache RAM et nécessite des insertions/deletions arbitraires
Lorsqu'elle sont bien utilisées, les Map auront une meilleure performance, utilisent moins de RAM et offre une meilleure API plus complète POJO (e.g. Map.clear) au prix d'une perte en DX (e.g. initialisation, spread operator)
Un article très complet sur le fonctionnement des lexer / parser de v8 (Chrome, Node.js) et SpiderMonkey (Firefox)
On comprend notamment que v8 se "plie" aux conventions des outils de minification du code ou encore que le point virgule est bien nécessaire ;-)
Un article très complet sur l'utilisation de AbortController pour annuler des requêtes réseau en cours notamment.
Je ne savais pas qu'il était aussi possible d'arrêter un listener de cette manière ! C'est pratique car il n'y a pas besoin de garder une référence sur la callback.
const controller = new AbortController();
const { signal } = controller;
window.addEventListener('resize', () => doSomething(), { signal });
// later
controller.abort();Un runtime Javascript (comme v8 qui est utilisé dans Chrome et Node.js) qui utilise seulement 8.5 Ko d'espace disque et minimum 34 octets de RAM!
Le but est d'utiliser du Javascript dans des micro contrôleurs qui pour la plupart ont 64 Ko de disque et 2 Ko de RAM.
L'auteur défend son projet avec notamment l'argument du single thread de javascript qui consomme moins de ressources que le multi thread.
On peut aussi ajouter qu'il est nettement plus simple et maintenable d'écrire du JS à mémoire managé que du C.
Un framework CRUD "fullstack": le code pour manipuler le CRUD des modèles est le même en front et en back.
Sinon c'est basé sur Express avec des classiques règles de validations.
En gros ça expose une API pour du CRUD à la manière d'un backend clé en main qui peut être manipulé dans du frontend ou un autre backend
Un framework pour développer des extensions navigateur !
La chercheuse résume son travail dans la vidéo de 10 minutes à la fin de l'article.
Elle a développé un concept de "linguistics smell" pour parler de l'épineux problème du naming qui accroît la complexité du code.
2 conseils simples:
- avoir des noms qui respectent leurs promesses (
isValidest un booléen,customerscontiens plusieurs éléments, etc) - se mettre d'accord sur une structure (les dates se terminent par
at, les quantifieurs sont à la fin, pas d'abreviation, etc)
Un article très intéressant sur le fonctionnement interne de v8 (le moteur JS de Node.js et Chrome) qui explique la représentation interne des différents types.
Si le sujet vous intéresse, j'avais compilé des ressources sur le fonctionnement des moteurs Javascript (et particulièrement v8) ici 👉 https://github.com/Aschen/understand-js-runtimes
Excellent article sur les erreurs les plus communes faites par les équipes de dev.
La plus importante pour moi est aussi celle que j'ai mis le plus longtemps à apprendre: écrire du code clair, pas du code intelligent
L'auteur parle surtout de sécurité mais il fait aussi des retours généraux sur la qualité du code, la dynamique des équipes, les différences entre langages / frameworks
Comment évaluer la complexité d'un logiciel ?
- nombre de lignes de code
- structure du code (boucles, conditions, indentation)
- couplage entre les modules
Utilisation d'un rate limiter pour éviter de se prendre des 429 quand on fait appel à une API externe
Une utilisation de la metaprogrammation en Javascript pour ajouter des simili propriétés sur n'importe quoi, même les nombres par exemple.
1[to(8)] // [1, 2, 3, 4, 5, 6, 7, 8]
const hex = Metho.add(
Number.prototype,
function() { return this.toString(16) }
)
console.log(65535[hex]) // 'ffff'