• [^] # Re: Javascript, everyday ...

    Posté par (site web personnel) . En réponse au journal 'UnJSq' v0.1.0. Évalué à 2.

    En fait, avec UnJSq, certaines opérations auraient plutôt un rendu coté client (même si rien ne s'oppose à ce que ce soit coté serveur), et, pour certaines autres, le rendu serait plutôt hybride. On ne va donc pas choisir UnJSq en fonction de ce critère. D'ailleurs, pour moi, cette histoire de rendu, c'est de la cuisine interne, dont le développeur devrait ne pas avoir à se préoccuper, sauf cas particuliers.

    Pour en revenir aux frameworks JavaScript, je ne les ai évidemment pas tous étudiés. Ils sont bien trop nombreux. Mais, de ce que j'en ai vu, ils ont tous leur logique propre, même s'ils ont certains concepts en commun, qu'il est nécessaire d'assimiler. En outre, comme c'est des frameworks, cela signifie qu'ils prennent le contrôle de l'application.

    UnJSq n'est pas un framework, c'est une bibliothèque, qui s'utilise comme n'importe quelle autre quelle autre bibliothèque Node.js et, du coup, le développeur garde le contrôle de l'application. Le principe de base de UnJSq, c'est que, pour chaque évènement pour lequel une action est déclarée, le développeur indique simplement les modifications à opérer sur le DOM. On voit que l'on reste là sur des concepts simples et intuitifs pour peu que l'on comprenne un tant soit peu le fonctionnement des navigateurs web...

    Zelbinium: pour la génération qui crée, pas celle qui scrolle...