Metal3d

TypeScript c’est le pied, mais pas “from scratch”. On aime ce que propose Vue, Angular ou encore React en mode “dev” (live reload, HMR, etc…) - alors comment on fait sans framework ? Et bien parlons de “Parcel” qui vient de sortir en version 2 et qui déchire de la licorne (et on parlera aussi de Vite ou SnowPack).

J’en ai parlé il y peu de temps en Go mais je sais que beaucoup d’entre vous utilise Javascript. Et justement, l’utilisation de closure en JS est très intéressante. On va voir dans ce billet que bien souvent on devrait réfléchir avec ce pattern que ce soit avec du JS pur ou avec Angular.

Angular2 est en phase “beta” depuis maintenant quelques semaines et je pense qu’il est temps de parler de mon expérimentation sur le sujet. Je ne vais pas vous proposer une documentation mais plutôt un genre de “howto” de mon point de vue.

NodeJS, JQuery, Mootools, HTML5… le javascript s’est imposé. Mais un sujet encore mal compris par beaucoup de développeurs JS me saute aux yeux. Depuis que je développe Knotter et que j’ai l’occasion d’en discuter, la tendance se creuse: beaucoup n’ont pas bien assimilé le concept de closure. Alors faisons un point sur les closures JS.

Il fut un temps pas si lointain où créer un site web entrait dans une logique saine de construction de pages. Chaque contenu était bien défini et les applications étaient un jeu de question-réponses entre le client et le serveur. Je me souviens que le plus dur était de passer la validation xhtml et de ne pas passer par des tableaux pour toute la mise en page. HTML5 est arrivé et tout à coup, c’est comme si tout le monde se foutait de l’accessibilité…

Et bien on y est. Je me suis lancé un défis il y a quelques semaines et il est réalisé en quelques temps. Knotter, mon microframework NodeJS passe en version 0.1.1. Et comme je pense que personne ne le connais, je vais vous le présenter avec des exemples à l’appui. Knotter, c’est simple un framework NodeJS basé sur un principe prototypé simple, rapide et malléable.