Discussion :

[jacdeh]

Python pour le serveur, Transcrypt pour le navigateur.
C'est par j'aime utiliser la même langue sur le client et le serveur.
Et de préférence pas de JavaScript...

[Invité]

Python pour le serveur, Transcrypt pour le navigateur.
C'est par j'aime utiliser la même langue sur le client et le serveur.

C'est dommage... Ce projet (Transcrypt) n'avait pas l'air mal, mais on dirait qu'il impose javascript activé pour pouvoir charger, vu que je n'ai qu'une belle page blanche à l'accès au lien !

Du coup, baah plus qu'à oublier cet outil...

[jacdeh]

La page est écrite en Transcrypt, et cela génère du JavaScript, donc malheureusement ...

[alama32]

Adobe Muse parce que wysiwyg, je pense que l’avenir est à ce genre de programme, sinon, AS3, Java (que j'apprend).. Phyton (à voir).. Mais perso, ras le bol de ces changements continuels. et aucune de ces grosse société qui soit foutue de créer un langage simple et un vrai compilo Xplatefromes.

[Aizen64]

NodeJS répond bien à certains cas d'utilisation mais ça reste quand même limitant de ne pas pouvoir donner du traitement lourd, ça limite son utilisation.

Un gain de perf colossal ? La pupart de mes méthodes se résument à : valider de la donnée, une requête SQL, un traitement, et une insertion en BDD. Node peut lancer des choses en parallèle sauf qui va bien devoir attendre le retour de requête pour continuer son traitement, gain de perfs ? Non.

Après effectivement, pour certaines tâches, ça reste utile.

L'écosystème JS ? instable. Même des outils comme Webpack utilisé par FB et cie peuvent parfaitement avoir un comportement buggé après une MAJ. Donc au jour d'aujourd'hui l'écosystème JS ne m'inspire par du tout confiance et c'est pas le million de libs sur npm qui me rassure.

Récap :
- PHP : langage dégeulasse avec un écosystème mature,
- JS : langage dégeu aussi, juste, on est oubligé de se le tapper en front, qu'on l'aime ou non, il est incontournable,
- Java/C# : frameworks bien structurés, le hic de Microsoft est que .NET Core a encore du chemin avant d'être considéré comme stable, l'ORM ne fait pas forcément bien son travail dépendant de la base par exemple. Par contre ces 2 plateformes sont stables, fortement typés et ont des bases solides,
- Ruby : langage bien pensé et structuré mais perfs catastrophiques et avec une communauté très fermée, mets pas 4 espaces en indentation ou du camelCase en nom de variable sinon la "Communauté Ruby" va te dire une phrase de gourou : "La Communauté Ruby A Dit Que ...." [ masturbation collective sur le langage ]
- Python : propre, obligé d'indenter son code correctement ce qui n'est pas un mal

Allez mettons nous d'accord sur une chose, ce qui compte le plus, c'est pas tant le langage mais la rigueur du dev et les outils/structure de code utilisés qui comptent. Dans tous les cas, ils se piquent tous des idées. Django/Twig, Laravel est aussi basé sur Symfony etc... avec des dépendances en chaine.

Libsodium au quotidien en PHP ça change quoi ?

[Spartacusply]

Node peut lancer des choses en parallèle sauf qui va bien devoir attendre le retour de requête pour continuer son traitement, gain de perfs ? Non.

A partir du moment où tu as deux traitement qui peuvent se lancer simultanément (deux inserts, deux selects, un upload de deux fichiers, le résultat de l'un ne dépendant pas du résultat de l'autre..., me dis pas que ça t'arrive jamais), cela peut-être fait en parallèle avec Node et est forcément exécuté plus rapidement que n'importe quel langage synchrone. Si tous les résultats dépendent les uns des autres alors oui en effet tu n'auras aucun gain (de ce point de vue là en tout cas).

Libsodium au quotidien en PHP ça change quoi ?

"Au quotidien" c'est un bien grand mot mais en gros il y a moins de paramètre dans la fonction d'encryptage ce qui certifie de manière beaucoup plus certaine la qualité du cryptage produit.

[Invité]

A partir du moment où tu as deux traitement qui peuvent se lancer simultanément (deux inserts, deux selects, un upload de deux fichiers, le résultat de l'un ne dépendant pas du résultat de l'autre..., me dis pas que ça t'arrive jamais), cela peut-être fait en parallèle avec Node et est forcément exécuté plus rapidement que n'importe quel langage synchrone. Si tous les résultats dépendent les uns des autres alors oui en effet tu n'auras aucun gain (de ce point de vue là en tout cas).

Sauf qu'un langage synchrone n'a pas qu'un seul process. Apache spawn autant de processes que nécessaire et NGINX a une process pool limitée mais très rapide pour desservir des requêtes, par exemple.

"Au quotidien" c'est un bien grand mot mais en gros il y a moins de paramètre dans la fonction d'encryptage ce qui certifie de manière beaucoup plus certaine la qualité du cryptage produit.

Chiffrement*

https://chiffrer.info/

[Spartacusply]

Sauf qu'un langage synchrone n'a pas qu'un seul process. Apache spawn autant de processes que nécessaire et NGINX a une process pool limitée mais très rapide pour desservir des requêtes, par exemple.

Évidemment c'était par requête que j'entendais mes propos. Le serveur fait toujours son taf au niveau du dispatching des requêtes, ça ne change rien à ce niveau là.

Chiffrement*

https://chiffrer.info/

Oui pardon je sais. Enfin disons plutôt que je sais que je ne sais jamais, je confonds toujours entre les deux

Très sympa ce petit site chiffrer.info au passage...