Journal 'UnJSq' v0.1.0

Posté par Claude SIMON (site web personnel) le 05 janvier 2018 à 20:49. Licence CC By‑SA.

Étiquettes :

jan.

2018

(Oui, je sais, mais ce n'est pas le nom définitif…)

UnJSq est un paquet pour Node.js qui permet de prendre en charge la partie frontend d'une application web.

Contrairement aux bibliothèques de type CGI, c'est-à-dire qui nécessitent que la page web soit rechargée à chaque requête, UnJSq permet de ne modifier que les parties du DOM qui le nécessitent.

Il s'agit là de la première version de cette bibliothèque, mais elle est néanmoins fonctionnelle. Vous trouverez des liens vers une démonstration en ligne, les sources de cette démonstration et de UnJSq, la procédure d'installation, ainsi qu'une, euh…, documentation à cette adresse : http://q37.info/UnJSq/.

M'y connaissant que peu en Node.js en particulier et en JavaScript en général, les retours sont les bienvenus, notamment sur les améliorations à apporter…

# Javascript, everyday ...

Posté par Faya le 06 janvier 2018 à 03:02. Évalué à 10.
Soit je n'ai rien compris, soit tu viens de créer un 4242e framework front-end javascript pour faire des Single Page App (ne pas recharger à chaque requête). Par exemple, quel est l'avantage par rapport à VueJS ?

Si j'ai mal compris, milles excuses. Sinon …
C'est impressionnant la rapidité à laquelle ces ""programmes"" se multiplient. Il semblerait que ça ait commencé à se calmer en 2017 mais il n'y a pas si longtemps, il était impossible de savoir que choisir (autre que du Vanilla JS) pour démarrer un projet : il sortait une nouveauté chaque jour ! Sans parler de la quantité astronomique de librairies tirées par la moindre installation sous Node (à tel point qu'il suffit que l'une d'entre elle plante, pour planter la moitié du Web )
- [^] # Re: Javascript, everyday ...
  
  Posté par Claude SIMON (site web personnel) le 06 janvier 2018 à 08:28. Évalué à 3.
  Je vais m'appuyer sur un exemple concret, à savoir http://vuejs.org/v2/guide/#Handling-User-Input.
  
  Avec UnJSq, pour avoir l'équivalent, on va créer un fichier XSL, appelons-le Main.xsl, avec le contenu suivant :
```
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" 
  xmlns="http://www.w3.org/1999/xhtml" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html" encoding="UTF-8"/>
  <xsl:template match="/">
    <div>
      <input type="textbox" id="Message" value="Hello UnJSq!"/>
      <button data-xdh-onevent="Reverse">Reverse Message</button>
    </div>
  </xsl:template>
</xsl:stylesheet>
```
  On va ensuite créer un fichier Javascript, appelons-le main.js, avec le contenu suivant :
```
const unjsq = require('unjsq');

function newSession() {
    return new unjsq.DOM();
}

function acConnect(dom, id) {
    dom.setLayout("", new unjsq.Tree(), "Main.xsl");
}

function acReverse(dom, id) {
    dom.getContent("Message",
        (result) => dom.setContent("Message", result.split('').reverse().join(''))
    );
}

function main() {
    unjsq.register([
        ["Connect", acConnect], // À l'action 'Connect' on va affecter la fonction 'acConnect(...)'.
        ["Reverse", acReverse], // À l'action 'Reverse' on va affecter la fonction 'acReverse(...)'.
    ]);

    /* Ici, on lance le serveur, en déclarant 'NewSession'
    comme la fonction à lancer à chaque nouvelle session,
    'reverse', le répertoire dans lequel sont stockés
    tous les fichiers relatifs à cette 'application',
    et 'Connect', l'action à lancer suite à la connexion
    de l'utilisateur (qui va afficher la première page). */
    unjsq.launch(newSession, "reverse", "Connect");

}

main();
```
  On place ces deux fichiers dans un répertoire nommé reverse, on lance le tout avec node reverse/main.js, après avoir installé UnJSq, et on observe le résultat en ouvrant un navigateur web à l'adresse http://localhost:8080/.
  
  La grosse différence, c'est que le code Javascript qui va effectuer l'action associée au bouton est, non pas exécuté par le navigateur comme c'est le cas avec Vue.js, mais par node. Bon, pour un truc aussi simple, on aura aussi vite fait de mettre un onclick="..." sur le bouton (ça vaut aussi pour Vue.js), mais, l'avantage avec UnJSq, c'est que le développeur node n'est pas obligé de jongler entre node pour le backend, et un de ces framework Javascript pour le frontend : il peut tout faire avec node.
  
  Pour nous émanciper des géants du numérique : Zelbinium !
  - [^] # Re: Javascript, everyday ...
    
    Posté par galactikboulay le 06 janvier 2018 à 11:35. Évalué à 1.
    
    Merci, ça m'a convaincu de rester sur VueJS.
    - [^] # Re: Javascript, everyday ...
      
      Posté par Claude SIMON (site web personnel) le 06 janvier 2018 à 12:32. Évalué à 1.
      
      C'est clair que UnJSq n'est pas fait pour le développeur frontend. Le gars qui utilise VueJS ou consort, il ne va pas utiliser UnJSq, et donc se mettre à node, pour faire du frontend s'il n'est pas déjà sous node par ailleurs.
      
      UnJSq est fait pour le développeur backend sous node qui veut faire du frontend tout en restant sous node. Le but de UnJSq est d'offrir à ce genre de développeur la possibilité de faire du frontend sans avoir à recourir à un framework JavaScript…
      
      Pour nous émanciper des géants du numérique : Zelbinium !
      - [^] # Re: Javascript, everyday ...
        
        Posté par Fabrice Devaux le 06 janvier 2018 à 13:33. Évalué à 3.
        
        J'ai rien bité.
        (Pas de ta faute, je suis développeur système, vos trucs de web ça me dépasse totalement.)
        
        [^] # Re: Javascript, everyday ...
        
        Posté par Claude SIMON (site web personnel) le 06 janvier 2018 à 19:16. Évalué à 2.
        
        Moi-même, je suis développeur C++, donc, à priori, pas vraiment porté sur le web. Mais des clients m'ont demandé d'ajouter une interface web à certains logiciels que je leur avais développé. Comme je n'avais pas envie de me coltiner JavaScript ou consorts, ni les frameworks afférents, j'ai écrit un ensemble de bibliothèques pour pouvoir faire du développement web uniquement en C++, mais pas à la sauce CGI, comme cela existait déjà. UnJSq n'est qu'un wrapper faisant le lien entre Node.js et ces bibliothèques C++…
        
        Pour nous émanciper des géants du numérique : Zelbinium !
        
        [^] # Re: Javascript, everyday ...
        
        Posté par cppuser le 06 janvier 2018 à 19:20. Évalué à 1.
        
        Grosso-modo
        
        FrontEnd=l'affichage, la gestion IHM
        BackEnd=la logique de fonctionnement de l'application
        
        Mais le BackEnd peut aussi gérer l'envoi du HTML+CSS vers le client, ou le FrontEnd (donc du Javascript côté client, sur le navigateur donc) peut demander via la Javascript les données au serveur et ensuite faire l'affichage.
        L'avantage du FrontEnd est de faire travailler le client et moins le serveur qui n'envoie et ne reçoit que les données nécessaires.
        J'ai bon :-) ?
      - [^] # Re: Javascript, everyday ...
        
        Posté par Faya le 07 janvier 2018 à 00:50. Évalué à 3.
        
        le développeur backend sous node qui veut faire du frontend tout en restant sous node.
        
        VueJS Server-Side Rendering : https://ssr.vuejs.org/fr/
        J'avoue ne l'avoir pas testé mais faire backend et frontend sous Node, c'est déjà possible (Express, React,…) Par contre tu dis plus bas que tu voulais faire un wrapper pour ton code C++ donc là je vois mieux l'intérêt.
        
        [^] # Re: Javascript, everyday ...
        
        Posté par Claude SIMON (site web personnel) le 07 janvier 2018 à 10:21. É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…
        
        Pour nous émanciper des géants du numérique : Zelbinium !
      - [^] # Re: Javascript, everyday ...
        
        Posté par Tonton Th (Mastodon) le 07 janvier 2018 à 01:53. Évalué à 2.
        
        mon parser doit pouvoir comprendre.
- [^] # Re: Javascript, everyday ...
  
  Posté par Tonton Th (Mastodon) le 07 janvier 2018 à 01:49. Évalué à 5.
  
  (à tel point qu'il suffit que l'une d'entre elle plante, pour planter la moitié du Web )
  
  Saison 2 : https://github.com/npm/registry/issues/255
  - [^] # Re: Javascript, everyday ...
    
    Posté par Faya le 07 janvier 2018 à 03:06. Évalué à 4.
    
    Et comme pour la fois précédente (leftpad) , il y a des projets qui ne fonctionnent plus à cause d'un "package" comprenant une unique ligne :
    https://github.com/floatdrop/pinkie-promise/blob/master/index.js
  - [^] # Re: Javascript, everyday ...
    
    Posté par galactikboulay le 07 janvier 2018 à 16:04. Évalué à 4.
    
    Ce qui est quand même hallucinant, c'est que les gus de NPM n'ont a priori même pas pris la peine de voir ce qui se fait ailleurs: côté Java avec Maven, la suppression ou la modification d'un artifact de production (pas marqué SNAPSHOT) ne sont normalement pas autorisées, justement pour éviter ce genre de situations.
    Si quelqu'un pousse un artifact bogué sur Central, la seule solution est de pousser une nouvelle version.
# Webtoolkit et dégradation progressive

Posté par Jean-Baptiste Mayer le 07 janvier 2018 à 17:24. Évalué à 2.

Je reste toujours sur l'excellent Webtoolkit ( https://www.webtoolkit.eu/wt ) et son pendant Java (https:// www.webtoolkit.eu/jwt ) qui permettent de développer le frontend et le backend comme si c'était une application desktop, application simple page si le navigateur le supporte, multi-page automatique sinon.

Le tout sans écrire une ligne de Javascript.
- [^] # Re: Webtoolkit et dégradation progressive
  
  Posté par cppuser le 08 janvier 2018 à 16:17. Évalué à 2.
  
  Bonjour,
  sauf erreur il y a un inconvénient notable. C'est que tout est traité côté serveur, les évènement sont envoyés sur le serveur qui fait ensuite les modifications sur le DOM, alors que les modifications pourraient (et devraient) logiquement être faîtes côté client et non pas côté serveur.
  Ils auraient du faire une génération de code javascript côté client via du C++.
  C'est pour moi un peu dommage même si je suis développeur C++.
  Bonne fin de journée
# v0.1.1

Posté par Claude SIMON (site web personnel) le 10 janvier 2018 à 15:49. Évalué à 1.

Pour ceux pour qui l'installation sous macOS échouait, j'ai publié une version 0.1.1 qui devrait corriger le problème…

Pour nous émanciper des géants du numérique : Zelbinium !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.