:::: MENU ::::

Un brin de veille #29

React 0.13 est officiellement stable , vous pouvez commencer à utiliser des classes ES6 pour vos composants.

A Lire

Suite de la série sur npm avec quelques trucs et astuces d’usage et de configuration

Javascript

Angularjs en 200 lignes de code

Les outils, librairies et concepts à connaitre si on débarde dans le monde du javascript ( ou si on se réveille après quelques années de stagnation )

Le problème de la  ( des ) version(s) de node.js

Les erreurs des linters javascript expliquées

Documenter son API node.js à partir des tests avec mocha et acquit

HTML / CSS

Découvrez comment automatiser le « style guide-driven » développement 

Comment utiliser l’API History d’HTML5

Introduction à l’API Fetch . J’en parle souvent mais je pense que c’est clairement l’avenir du xmlhttprequest , surtout que cette API commence à arriver dans les navigateurs ( sans flag à partir de Chrome 42 et firefox 39 )

A Voir

Une police en CSS…uniquement !

Outils / Libs

Une collection d’outils UI pour la CLI

Une modale légère et sans dépendances rmodal.js


4 Comments

  • Répondre Benjamin Cherion |

    Ce site est une vraie mine d’or niveau veille …
    Je le consulte régulièrement mais j’oublie toujours de liker ou commenter … aller hop sur linkedin !

    Merci !

  • Répondre Thomas Pons |

    Pas intimement convaincu à propos de fetch … Assez verbeux tout de même et surtout gros point noir on perd la progress task … Et si on regarde la spec une troisième promesse ne peut pas le faire … De plus c’est un nouvel objet global qui vint polluer le pauvre scope de la window (c’est un moulin chez lui XD). Sinon c’est dans l’ère du temps :) ! Je t’invites à regarder les nouveautés ES7 dans la continuité de celles d’ES6 (l’asynchrone devient si facile …).

    Mais ton point de vue sur fetch m’intéresse !

    • Répondre maxdow |

      C’est en effet dans l’air du temps ce coté « rendons l’asynchrone synchrone ». Je trouve que l’API Fetch, pour des requetes simples est justement plus simple que l’XHR actuel. Après je ne l’ai pas encore exploité en détail sur un vrai projet mais je pense l’utiliser si je dois faire un dev hors framework. Concernant les problématiques de progression il me semble que c’est en discussion, e problème c’est que les promises d’ecmascript ne proposent pas cette notion de progression ( comme dans Q par exemple). C’est encore trop tot pour remplacer l’XmlHttpRequest mais comme je dis je pense que c’est son avenir. Après c’est vrai que les fonctionnalités ES7 en complément des générateurs mettent l’asynchrone à plat sans introduire d’autres API ;)

So, what do you think ?