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=}

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

Très bon article sur les Design System et leurs limites:

• trop de couplage entre composants et logique métier spécifique (data fetching, state, etc)
• manque de documentation à jour (le plus vieux problème des développeurs)

J'aime aussi la distinction qu'ils font entre front-frontend qui s'occupe principalement de l'UI via le design system justement et le back-frontend qui est plus dans la récupération des données et la gestion du state.

Quelques astuces pour réduire la taille de son bundle frontend

L'auteur parle de l'utilisation des WebComponents et autres API standard du web plutôt que des framework complexes de type React

Excellent article qui résume la complexité sous jacente du développement frontend face à une demande "simple"