La vidéo fait 17 min, je l'ai regardée en x1,25 sans problème en zappant les 2 premières minutes. Bref un onboarding sur Svelte en 10 min pour ceux qui ont déjà fait pas mal de front.
Top !
Discussion fictive entre un développeur PHP des années 2000 qui doit faire du front en 2016 après quelques années de pause.
Très drôle :D
Dernièrement je regardais les nouveautés en termes de frameworks CSS et globalement il y la liste suivante :
- Bootstrap
- Bulma
- Tailwind
- Foundation
- Skeleton
- Pure
- Tachyons
J'avais beaucoup d'espoir dans Tailwind qui adopte une approche par contraintes, dans le sens où il permet, sur chaque composant, d'appliquer des classes du type "à droite, vertical, graissé, etc" et c'est la combinaison de ces classes qui définira le rendu définitif du composant #SexySur20
A l'opposé, il y a Bulma où des composants déjà prêts existent et où les classes sont du type "burger-menu".
Sauf que je viens de m'apercevoir que Tailwind repose sur la mouvance JS bullshit dont la Comitstrip suivante matérialise parfaitement l'hérésie des fashions victims qui servissent dans l'industrie depuis un moment déjà :
Bref, il ne reste plus que Pure et Bulma comme frameworks CSS qui soient de vrais frameworks CSS paramétrables et simples. Certains me demanderont pourquoi j'insiste le fait d'avoir des CSS purs et durs et l'argument est simple : les SPA/PWA, j'en suis revenue !
Argumentons quand même. Selon moi, à moins que votre site implique au moins deux critères parmi les suivants (si ce n'est pas trois) :
- Du streaming de TRÈS gros fichiers (genre youtube)
- Des temps de surf qui se comptent en heureS (m'voyez le 'S') voire en jours
- Des actions ultra complexes (genre éditeur de photo en ligne)
- Le besoin de déporter des calculs côté clients si lourds qu'aucune infra sur terre ne tiendrait la charge si tout était centralisé côté serveur (ou alors à un coût équivalent à celui de ChatGPT)
- Le besoin de travailler en mode hors connexion
=> alors les SPA/PWA sont une mauvaise idée.
Du coup, la seule manière de pouvoir coder un design system qui fonctionne à la fois dans des MPA (ie. terme à la mode pour dire "pages générées côté serveur" comme Papy faisait avant en PHP) mais aussi dans des SPA/PWA, c'est d'avoir un framework CSS indépendant de tout JS et qui soit téléchargé en tant que fichier CSS et non JS.
Bref, je vais zoomer sur Pure histoire de voir ce qu'il est devenu - et peut-être Cardinal aussi - mais dans le fond, je pense garder Bulma d'autant que son développement aurait récemment repris :P
Un article qui montre comment invoquer du JS depuis du code Kotlin qui sera transpilé en JS ensuite.
Je cherche à supprimer TypeScript du code de mes SPA pour n'avoir que du Kotlin côté back, du Kotlin transpilé/compilé vers du JS ou vers WASM côté front et du DSL en Kotlin via Ktorm pour le SQL.
Bref un langage pour les contrôler tous.
Comment charger du code WASM dans un navigateur ?
// This is our recommended way of loading WebAssembly.
(async () => {
const fetchPromise = fetch('fibonacci.wasm');
const { instance } = await WebAssembly.instantiateStreaming(fetchPromise);
const result = instance.exports.fibonacci(42);
console.log(result);
})();
Je cherche depuis plusieurs mois un successeur à Aurelia (puisque Aurelia 2 n'avance plus et qu'il me donne l'impression d'être un projet zombie).
Je suis tombée ce soir sur Mikado, qui est un moteur de template HTML côté client.
Il est ultra rapide (équivalent à du Vannilla JS) et ne pèse que 3 Ko. Il s'appuie massivement sur les fonctionnalités connues et diffusées du web (balise tempate, id, etc), d'où sa vitesse, mais apporte le confort qu'il faut.
Si je parviens à structurer mon code avec, il remplacera Aurelia, Angular et React chez moi.
Un tuto clair et rapide sur les modules en JS. Pour toi @Animal :D
Je cite :
Le nouveau format de verrouillage des paquets déverrouillera la possibilité de faire des constructions reproductibles de manière déterministe et comprend tout ce dont npm aura besoin pour construire entièrement l'arbore des paquets. Avant que les fichiers yarn.lock de npm 7 ne soient ignorés, la CLI peut maintenant utiliser yarn.lock comme source de métadonnées de paquets et de conseils de résolution.
Imaginez que l'outil standard de construction des fronts en JS (l'outil de build si vous préférez) vient seulement de fournir la fonctionnalité de garantir un build reproductible...
Comment vous dire... Ça fait 7 ans, tous les fronts "pros" s'appuyaient dessus et nous sommes fin 2020...
Mon client m'a demandé de lui faire part de différents frameworks de test End-to-End qui marcheraient bien avec des SPA. Ici Nightwatch dont le seul défaut est de ne pas gérer nativement le Gherkin (même s'il est possible de lui greffer une bidouille).
Un exemple :
Réduire la taille de son bundle JS en supprimant les dépendances inutilisées. Fonctionne pour Vue.js mais doit aussi fonctionner pour Aurelia.
Et encore une fois, ce lien est remonté par Kalvn.
C'est... Tellement... Ça !!!
Les auteurs de CommitStrip sont de vrais génies.
Tout est dans le titre
Toutes les tendances du JS en 2018. Le site classe tout, de TypeScript à ClojureScript en passant par Vue et Angular, Jest, Jasmine, Mocha. Bref tout ! Même la répartition des salaires par technos (*___*).
@Kalvn si un jour tu me lis, sache que je t'adore ! Tu sors régulièrement des liens incroyables et tu es en passe de devenir l'un de mes shaarlistes préférés :D
Le lien d'origine.
Un outil en ligne très sympa permettant de déminifier des fichiers JS / CSS / HTML minifiés.
Très pratique !
Edit 2 : bon aurelia-bundler ne peut fonctionner qu'avec JSPM qui dépend de SystemJS. Or la liste des dépendances de JSPM se trouvent dans un fichier s'appelant config.js... M'voilà. J'abandonne et je reste sur le build Aurelia/Webpack.
Ça me saoule car j'espérais vraiment mettre en place un build plus simple, voire de créer un plugin Aurelia pour Brunch mais c'est trop long, trop de choses à maîtriser, trop de trucs qui changes tout le temps, trop de hypsters s'imaginant fournir la nouvelle techno de demain et qui préfèrent ne pas apporter leur soutien à un projet existant (car ils recherchent la gloire et non l'émancipation du système tout marchand). Le problème avec JS, ce sont les gens qui codent en JS pour JS.
Edit : après avoir testé, le tuto ne fonctionne pas (comme quasiment tous les tutos avec Aurelia). J'ai l'impression que le aurelia-bundler ne fonctionne qu'avec JSPM. Mon problème avec ça ? C'est que j'ai déjà un gestionnaire de paquet intégré à mon outil de build et que ce gestionnaire s'appelle NPM ! D'autant que JSPM est un utilitaire qui n'a jamais décollé et ça n'est pas près d'arriver !
Plus j'utilise Aurelia et plus que je trouve ce framework est merdicimale juste à cause du build ! L'utilitaire au aka aurelia-cli passe son temps à réinventer la roue et à tout faire pour surcharger la conf standard d'outils connus, documentés et maîtrisés comme le sont Gulp, NPM. Pourquoi faut-il que les développeurs d'Aurelia utilisent toujours la dernière techno-hype merdique qui n'a pas encore eu le temps de percer, c'est chiant à la fin ! Si encore ils s'étaient appuyés sur Brunch pour réutiliser quelque chose d'existant et de simple plutôt que de tout refaire à leur sauce en mode hypster-à-la-noix.
Le plus terrible c'est que la communauté derrière le framework Aurelia revendique qu'il est l'un des frameworks les plus respectueux des standards... Mais dès qu'il s'agit du build, ils sont encore pire qu'Angular c'est vous dire à quel point le niveau de médiocrité est ineffable.
Bref, je continue mes investigations en espérant comprendre par moi-même comment fonctionne le aurelia-bundler et surtout à quoi sert ce foutu fichier config.js (je pressens qu'il a un lien avec JSPM, auquel cas je sens que je vais hurler car je fais tout mon possible pour avoir un build 100% Gulp + NPM et rien d'autre).
Comment utiliser l'API du aurelia-bundler directement dans Gulp et s'éviter Webpack ?
Je me permets d'ajouter un truc qui me frustre avec Aurelia : c'est un framework à la Spring ou à la JEE qui se prétend modulaire mais où chaque élément de la couche supérieure va tirer un élément de la couche inférieure.
Essayez de remplacer la DI de Spring, Aurelia ou Angular par une autre pour voir. C'est juste impossible, car le couplage entre les modules y est total ! #DesignDeNoob
Mais en vérité cette "erreur de design" arrange bien son fabriquant puisqu'il rend le développeur captif du framework et lui évite d'aller prendre une lib chez la concurrence. #PorteOuverteVersLesAutres
Ma décision pour 2019, trouver des micro-frameworks, indépendants, interchangeables et légers, pour le front, à l'image de ce que sont Sparkjava (web serveur REST), ActiveJDBC (ORM), Feather-java (DI) ou encore Jsoniter (conversion entity-json) pour le back sur JVM.
Une lib pour manipuler les dates et les calendriers en JS.
Comment mettre en cache des fichiers statiques avec Nginx
Comme pour l'autre lib, vérifier que celle-ci gère la mise en forme
Convertir un div HTML en PDF.
Pour Lenny
The magical disappearing UI framework.
Le principe de Svelte me plaît beaucoup : vous codez votre GUI et il n'y a pas de framework, juste du code transpilé par Svelte.
Dit autrement, avec Aurelia ou Angular, nous avons besoin, au moment du run, de télécharger 250Ko à 950Ko de sources qui appartiennent au framework, ensuite seulement nous pouvons afficher notre SPA.
Svelte n'est pas un framework mais un transpiler qui va modifier votre code pour qu'il s'exécute directement, sans lib en pré-requis.
C'est plus léger à télécharger et cela évite l'overhead au run. En tant que DevOps, j'ajouterais que cela doit rendre la regénération de la SPA plus rapide avec un Gulp watcher + BrowserSync puisque moins d'étapes et moins de code à traiter.