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.
Pour Lenny
Pour Chlouchloutte et Lenny... Votre avis ?
Les sources JavaScript exécutées par le navigateur sont souvent différentes des sources originales crées par un développeur. Les source map servent au debugger