Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui

Autant des solutions comme QT c’est vraiment des applications desktop mais c’est pas si simple de faire un truc qui marche partout à ce que j’ai compris, autant electron ça ressemble à une app web packagé avec son propre navigateur web, on peut parler d’application desktop mais la frontière devient flou, de plus bientôt on aura aussi les pwa

Citation:

---

Envoyé par Sodium

Attention, n'oublie pas de finir tes phrases sinon c'est difficile à ;)

---

ya pas de fin c'était une erreur de l'écriture intuitive.

Citation:

---

Envoyé par youtpout978

Autant des solutions comme QT c’est vraiment des applications desktop mais c’est pas si simple de faire un truc qui marche partout à ce que j’ai compris,

---

Qt vante beaucoup ses côtés cross-platform, responsive, etc, donc c'est un peu étonnant. Perso, je ne peux pas dire car je n'ai jamais fait d'appli mobile avec Qt mais si tu as des vraies infos à ce sujet, ça m'interesse.

Citation:

---

Envoyé par youtpout978

autant electron ça ressemble à une app web packagé avec son propre navigateur web, on peut parler d’application desktop mais la frontière devient flou,

---

Et alors ? A l'usage, tu programmes quand même du desktop avec. Atom et Visual Studio Code ne sont pas des appli web à ce que je sache. Et toutes les appli java ne sont pas des appli mobile parce qu'Android a aussi une JVM.

Citation:

---

Envoyé par youtpout978

de plus bientôt on aura aussi les pwa

---

Ah oui, les pwa... https://en.wikipedia.org/wiki/Public...Administration

Citation:

---

Envoyé par SimonDecoline

Ah oui, les pwa... https://en.wikipedia.org/wiki/Public...Administration

---

Progressive web apps, l’équipe en a une http://pwa.lequipe.fr

Electron n'est pas vraiment cross platform... disons que la cluf de ios ne le permet pas.
Electron embarque un chromium(ou pire une version customisee), donc oui le dev fait une appli web qui est ensuite 'interpretee' par electron, je m'y etais penche un moment, mais le bidule a l'air de faire un peu trop de trucs.

Concernant pwa: oui en theorie ca marche bien, et utilisier les webcoponents ca a l'air pas mal, reste que la phase d'architecture devient encore plus complexe a gerer.
Allez on va aussi parler de webassembly qui permet des trucs cools, mais qui demande un investissement certain.

En tous cas les gars: continuez, vous entretenez le popcorn (reprendre les gens sur leur conjugaison n'est pas tres sport c'est comme taper sur le physique) , car certains ici s'amusent beaucoup a vous lire.


Enfin pour retourner au sujet a apporter mon caillou a l'edifice, le soucis c'est pas JS, c'est plutot la demande toujours croissante en fonctionnalites, rapidite et ergonomie. Vu que JS est a peu pres la seule tech qui le permet alors on blame JS, jamais le business analyst ou chef de projet qui a pris cette decision.

C'est cross platform desktop ... puisque ce sont des application desktop :)

Citation:

---

Envoyé par mermich

Electron embarque un chromium(ou pire une version customisee), donc oui le dev fait une appli web qui est ensuite 'interpretee' par electron, je m'y etais penche un moment, mais le bidule a l'air de faire un peu trop de trucs.

---

Tout à fait. Et donc chromium lui-même est une appli web.

Du coup, il faudra que tu corriges quelques pages qui sont erronées, notamment enlever "server" dans la définition de web app : In computing, a web application or web app is a client–server computer program (https://en.wikipedia.org/wiki/Web_application)

Et ensuite il faudra que tu corriges tous les "desktop" erronés :
- Electron allows for the development of desktop GUI applications (https://en.wikipedia.org/wiki/Electr...are_framework))
- Build cross platform desktop apps (https://electronjs.org/)
- Atom is a desktop application built with HTML, JavaScript, CSS, and Node.js integration (https://atom.io/)
- Atom is a desktop application built using web technologies (https://en.wikipedia.org/wiki/Atom_(text_editor))
- Visual Studio Code is a lightweight but powerful source code editor which runs on your desktop (https://code.visualstudio.com/docs)
- Visual Studio Code is based on Electron, a framework which is used to deploy Node.js applications for the desktop (https://en.wikipedia.org/wiki/Visual_Studio_Code)
- Slack provides ... electron desktop clients (https://en.wikipedia.org/wiki/Slack_(software))

Et surtout merci; une erreur si répandue, on n'avait pas vu ça depuis Galilée.

Citation:

---

Envoyé par Sodium

C'est cross platform desktop ... puisque ce sont des application desktop :)

---

Non, c'est un nouveau concept : les applis web cross-platform...

En ce moment je joue à ça, visiblement codé en Canvas/JS, je suppose que c'est aussi une web-application :?

https://www.youtube.com/watch?v=zuN-5yxwogU

Je ne pense pas qu'en sois le JS soit derrière la lenteur et lourdeur des pages mais le mauvais usage de celui-ci l'est. Si pour une requête AJAX faut dix à vingt ligne, utiliser le jQuery, pour n'en citer que celle-ci, semble plus attrayant pour une majorité. Ou d'autres bibliothèques pour une ou deux animations sans compter les trackeurs etc.

Tiens d'ailleurs, quand on parle de web-application, on parle bien de web ... comme World wide web non ? Va falloir m'expliquer comment une application stand-alone offline qualifie à cette définition ...

La plus value de jQuery aujourd'hui est discutable.

Pour le JS, je n'ai jamais aimé ce langage. Rien que de créer ce que JS considère comme un objet me parait chelou. Pourtant sur tous les autres langages créer une classe et savoir l'instancier ne me pose pas de problème. Par ex, quel est le résultat d'un module.exports, comment il fonctionne, est-ce que je fait un import from ? Sans parler que quand on parle de modules JS tu as du commonJS, Asynchronus Module Definition etc... merde c'est complexe pour un seul et même langage non ?

Bordel Webpack 2 utilisait quasiment 100 % de mon CPU pour faire quoi ? Compiler du JS et CSS à la volée ?! Je lui demande pas de faire tourner un jeu 3D pointu là.

Alors oui certains outils JS resteront pour quelques temps, tel que Angular, Webpack mais avec quelle durée de vie sur des versions majeures ? 6 mois à un an ?

J'ai eu la discussion avec un collegue il y a quelques semaines et même lui reconnaissait que la communauté JS par dans tous les sens.

Il est où le framework complet backend en JS ? Express ? C'est un framework minimaliste. Ce n'est pas une critique d'Express, les frameworks comme celui ci peuvent très bien faire fonctionner un très gros projet, en revanche, il n'y a aucun framework backend JS qui soit au niveau d'une JVM ou d'yn framework comme Django et cie.

C'est une malédiction ce truc, mais je veux bien faire preuve d'ouverture d'esprit, si quelqu'un a de bonnes ressources pour faire de la POO en JS je l'écoute.

Citation:

---

Envoyé par Aizen64

C'est une malédiction ce truc, mais je veux bien faire preuve d'ouverture d'esprit, si quelqu'un a de bonnes ressources pour faire de la POO en JS je l'écoute.

---

J'ai demandé une vingtaine de fois des exemples de bons codes JS et n'ai jamais obtenu de réponse ;)

Citation:

---

Envoyé par Sodium

Tiens d'ailleurs, quand on parle de web-application, on parle bien de web ... comme World wide web non ? Va falloir m'expliquer comment une application stand-alone offline qualifie à cette définition ...

---

C'est marrant je suis en train d'écrire un papier là dessus car cette question n'est pas aussi anodine qu'elle n'y paraît.

La définition usuelle du web c'est tout ce qui tourne dans un navigateur, or de nos jours on exploite les technologies utilisées pour le web sur d'autres supports. Le mobile via des technos comme React Native out Ionic, et même le desktop via Electron qui a vraiment explosé ces 2 dernières années.

Du coup les projets ayant pour ambition d'être multiplateformes sont architecturés de sorte à ne maintenir qu'une codebase avec le minimum de code spécifique nécessaire aux plateformes "non-web".

On peut débattre de l'aspect bien/mal de cette évolution, force est de constater que c'est là et que c'est économiquement intéressant pour les entreprises de suivre ce modèle.

Je n'ai pas de conclusion pour le moment mais je tenais à souligner que les lignes entre web et non-web s'amenuisent.

Citation:

---

Envoyé par Aizen64

Rien que de créer ce que JS considère comme un objet me parait chelou.

---

L'approche à base de prototypes est juste moins répandue que l'approche à base de classes. Mais si elle existe dans plusieurs langages (JavaScript, Lua, Perl 6...) c'est peut-être qu'elle a tout de même un intérêt.

Citation:

---

Envoyé par Aizen64

Il est où le framework complet backend en JS ?

---

sails.js ?

Citation:

---

Envoyé par Aizen64

C'est une malédiction ce truc, mais je veux bien faire preuve d'ouverture d'esprit, si quelqu'un a de bonnes ressources pour faire de la POO en JS je l'écoute.

---

Ca doit peut-être être possible car, rien que chez O’Reilly, il y a au moins 4 livres qui abordent le sujet :
- Beautiful JavaScript: Leading Programmers Explain How They Think
- JavaScript: The Good Parts
- Learning JavaScript Design Patterns
- Functional JavaScript

Citation:

---

Ca doit peut-être être possible car, rien que chez O’Reilly, il y a au moins 4 livres qui abordent le sujet :
- Beautiful JavaScript: Leading Programmers Explain How They Think
- JavaScript: The Good Parts
- Learning JavaScript Design Patterns
- Functional JavaScript

---

J'ai jeté un oeil à pas mal de ces ouvrages. Ils expliquent en effet comment comprendre et utiliser au mieux les particularités de JavaScript.
Le problème est que les particularités de JavaScript font que même un code objectivement bien écrits reste difficilement lisible.
Apprendre à bien coder avec JavaScript, c'est un peu comme apprendre à bien construire une maison avec des allumettes : il y a certainement moyen de faire un truc qui tienne debout, mais un entrepreneur sérieux préférera employer des briques.

Franchement 15 jours sans lire sodium ça fait pas de mal

Citation:

---

Envoyé par SimonDecoline

Tout à fait. Et donc chromium lui-même est une appli web.

Du coup, il faudra que tu corriges quelques pages qui sont erronées, notamment enlever "server" dans la définition de web app : In computing, a web application or web app is a client–server computer program (https://en.wikipedia.org/wiki/Web_application)

Et ensuite il faudra que tu corriges tous les "desktop" erronés :
[...]

---

Ce que tu écris Simon est risible et témoigne de ton ignorance dans ce domaine si vaste de l'informatique en réseau. En réseau existe la notion de services, et pour servir ces services existe la notion de serveur, soit server ou daemon en anglais. Ainsi un processus serveur finit souvent par un "d" comme httpd ou ftpd, ntpd...
En parallèle, ces services sont consommés par des clients, c'est ce qui fait la paire "client/server" évoquée.
Rien n'exclue que client et serveur soit sur la même machine, IP propose la notion de loopback (127.0.0.1 en IPv4) pour consommer les services en local (localhost qui en général pointe vers l'IP précitée).

Tout cela répond à un modèle très ancien auquel se conforme TCP/IP et donc dans lequel fonctionnent des protocoles comme http.

Ce modèle est ici : https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI

Lisez, apprenez, révisez... la base est là et va vous éclairer.

Au demeurant vous avez avec Node tous les outils pour créer des services, tous ces noms pouvant se terminer en "d". Les exemples de base de Node montre comment créer un httpd minimaliste.

Le problème que vous avez les gars, c'est que vous faites des applications sans réellement comprendre tout ce qui sous-tend ces applications. L'histoire de l'Internet, de l'hypertext, des navigateurs, du JS tout ça ça vous dépasse.
Et de la même façon les modèles et architectures qui sous-tendent ces concepts.
On a bien avec Electron un outil qui permet de construire un ou plusieurs daemons et construire un client pour consommer les services de ces daemons.
En jetant un oeil vite fait, VSCode écoute le port TCP 8373 sur ma machine par exemple. On peut donc imaginer qu'il y sert quelque chose.

Voilà on est loin de ces applications desktop telles que vous les imaginez. Par contre chromium est bien une application (desktop si vous voulez) au sens où vous l'entendez, comme les navigateurs le sont.

Voilà pour Galilée... Et les saintes écritures.

Citation:

---

Envoyé par SimonDecoline

L'approche à base de prototypes est juste moins répandue que l'approche à base de classes. Mais si elle existe dans plusieurs langages (JavaScript, Lua, Perl 6...) c'est peut-être qu'elle a tout de même un intérêt.

sails.js ?



Ca doit peut-être être possible car, rien que chez O’Reilly, il y a au moins 4 livres qui abordent le sujet :
- Beautiful JavaScript: Leading Programmers Explain How They Think
- JavaScript: The Good Parts
- Learning JavaScript Design Patterns
- Functional JavaScript

---

Je vais regarder pour sails.js, plusieurs points, j'ai toujours pus de mal à me mettre à utiliser des langages faiblement typés/dynamiques comparés à du typage statique. A mon sens Java/C# sont un poil plus verbeux mais plus explicites.

Malheureusement je fais du PHP aujourd'hui et le langage est moche, avec des comparaisons de type hasardeuses et des fonctions qui renvoient false au lieu de péter.

Je veux bien un exemple d'un objet exporté avec module.exports sous la notation var monObjet {} si t'as un exemple.

On est quand même d'accord que c'est un peu brouillon, soit tu utilises un module.exports, soit import from dont la plupart ne fonctionnent pas nativement. J'en comprends la raison, tu ne fais pas une plateforme comme le web qui fonctionne sur n'importe quel appareil/OS sans quelques inconvénients.

Tous les autres langages que je connais ont une seule et unique façon de créer une classe et l'instancier.

Bonne soirée !

Citation:

---

Envoyé par Aizen64

j'ai toujours pus de mal à me mettre à utiliser des langages faiblement typés/dynamiques comparés à du typage statique. A mon sens Java/C# sont un poil plus verbeux mais plus explicites.

---

Je suis assez d'accord avec toi.

Citation:

---

Envoyé par Aizen64

Je veux bien un exemple d'un objet exporté avec module.exports sous la notation var monObjet {} si t'as un exemple.

---

Je ne suis pas sûr de bien comprendre ton problème. Les rares fois où j'ai dû réutiliser un module nodejs pour du navigateur, je suis passé par browserify et ça a fait le job.

Citation:

---

Envoyé par Aizen64

On est quand même d'accord que c'est un peu brouillon, soit tu utilises un module.exports, soit import from dont la plupart ne fonctionnent pas nativement. J'en comprends la raison, tu ne fais pas une plateforme comme le web qui fonctionne sur n'importe quel appareil/OS sans quelques inconvénients.

---

Ca résume bien la situation : js a des problèmes qu'aucun autre langage a car js a des applications qu'aucun autre langage n'a. Mais ça n'excuse pas pour autant certains problèmes.

Citation:

---

Envoyé par Aizen64

Je veux bien un exemple d'un objet exporté avec module.exports sous la notation var monObjet {} si t'as un exemple.

---

Code:

---

1 2 3 4 5 6 7 8

function add(a, b) { return a + b; }   module.exports = { add };

---

C'est de ça que tu parles ?

Citation:

---

Envoyé par Aizen64

On est quand même d'accord que c'est un peu brouillon, soit tu utilises un module.exports, soit import from dont la plupart ne fonctionnent pas nativement.

---

C'est brouillon dans ta tête parce que tu n'es pas formé. module.exports c'est la syntaxe d'export de CommonJS et import from c'est la syntaxe d'import des modules ES6.

Et si ça fonctionne pas nativement c'est parce que c'est pas implémenté dans le moteur que tu utilises. Ça fonctionnera très bien sur Chrome (V8) mais pas sur IE par exemple. Ça n'a pas de rapport avec le langage c'est lié au moteur qui implémente le langage.

Citation:

---

Envoyé par Aizen64

J'en comprends la raison, tu ne fais pas une plateforme comme le web qui fonctionne sur n'importe quel appareil/OS sans quelques inconvénients.

---

Le problème c'est la diversité des moteurs, pas le langage, il n'y a qu'une seule spec pour JavaScript elle est rédigée par le TC39.

Citation:

---

Envoyé par Aizen64

Tous les autres langages que je connais ont une seule et unique façon de créer une classe et l'instancier.

---

En JavaScript aussi : const reference = new MaClasse();. Tu confonds les classes et les modules, deux concepts complètements différents.

Citation:

---

Envoyé par Marco46

Code:

---

1 2 3 4 5 6 7 8

function add(a, b) { return a + b; }   module.exports = { add };

---

C'est de ça que tu parles ?



C'est brouillon dans ta tête parce que tu n'es pas formé. module.exports c'est la syntaxe d'export de CommonJS et import from c'est la syntaxe d'import des modules ES6.

Et si ça fonctionne pas nativement c'est parce que c'est pas implémenté dans le moteur que tu utilises. Ça fonctionnera très bien sur Chrome (V8) mais pas sur IE par exemple. Ça n'a pas de rapport avec le langage c'est lié au moteur qui implémente le langage.

---

Ta remarque sur CommonJs illustre bien mes propros et JS est à ma connaissance le seul language a avoir non seulement 3 façons de faire ce que d'autres langages appellent des classes, n systèmes de modules (CommonJS, AMD pour Async Module Definition ? Il y en a un autre ?).

C'est précisément le point que je soulève, c'est un vrai bordel.

Ce que je trouve assez équivoque c'est qu'un dev avec qui j'ai bossé, quand je lui ai dit que je n'aimais pas le language m'a rétorqué "tu devras changer d'avis en regardant NodeJS", pourtant, j'ai aussi entendu de sa part des "bon... c'est Javascript".

De la part de 3 devs expérimentés, j'ai entendu ces arguments :
- les frameworks Javascript c'est comme des champignons, il em pousse toutes les semaines. Ça ne me pousse pas à utiliser un framework backend car je ne sais pas si il sera là dans 3 ans. Ça bouge trop
- la communauté JS est tellement éparpillée que c'est un peu bordélique
- en framework backend JS (dit il y a un an et demi), il y a Express qui correspond à un micro framework

La partie asynchrone était novateur à l'époque mais il me semble que les langages .NET l'ont intégré, Java aussi j'imagine. Reste les nombreux langages interprétés où ça n'a pas l'air d'être le cas. Du moins des alternatives stables existent.

Citation:

---

Envoyé par Aizen64

n systèmes de modules (CommonJS, AMD pour Async Module Definition ? Il y en a un autre ?).

---

Depuis le début du mois, pendant une partie de mon temps libre, je suis en train de découvrir JavaScript et TypeScript.
Dans le manuel de TypeScript, à la page Modules, lis la section Code Generation for Modules.
On y voit que TypeScript peut transpiler le code vers 5 systèmes de modules différents. :ptdr:

Voici le début de la section :

Citation:

---

Depending on the module target specified during compilation, the compiler will generate appropriate code for Node.js (CommonJS), require.js (AMD), UMD, SystemJS, or ECMAScript 2015 native modules (ES6) module-loading systems.

---

En dessous, on voit un exemple de module très minimaliste en TypeScript puis, pour chacun des 5 systèmes de module, le code JavaScript généré par le compilateur depuis ce module TypeScript.

Citation:

---

Envoyé par Pyramidev

Depuis le début du mois, pendant une partie de mon temps libre, je suis en train de découvrir JavaScript et TypeScript.
Dans le manuel de TypeScript, à la page Modules, lis la section Code Generation for Modules.
On y voit que TypeScript peut transpiler le code vers 5 systèmes de modules différents. :ptdr:

Voici le début de la section :

En dessous, on voit un exemple de module très minimaliste en TypeScript puis, pour chacun des 5 systèmes de module, le code JavaScript généré par le compilateur depuis ce module TypeScript.

---

Alors, ça illustre bien mon point sur JS, il y a 5 façons différentes de créer des modules JS et presque autant de façons de faire un truc qui se rapproche d’une classe.

Allez PHP, ce truc mal conçu et moche en a 3 include/require et l’autoloading avec les espaces de nom.

Java/C# : une seule directive, Ruby et Python pareil il me semble.

Il faut regarder les choses en face, à la base JS n’a pas été conçu pour être très modulaire sinon ces systèmes de modules n’existeraient probablement pas et il y aurait déjà eu cette notion incluse depuis sa création.

Ce que je trouverai intéressant c’est que webassambly perce et que l’utilisation de JS ne soit plus une obligation.


Je reverrai la doc TS plus tard, merci de l’avoir incluse c’est intéressant.

Citation:

---

Envoyé par Aizen64

Il faut regarder les choses en face, à la base JS n’a pas été conçu pour être très modulaire sinon ces systèmes de modules n’existeraient probablement pas et il y aurait déjà eu cette notion incluse depuis sa création.

---

Non en effet, encore une fois JavaScript a été conçu à la base pour rajouter des interactions simples dans une page telles que faire clignoter un texte. L'utilisation actuelle de ce langage est un accident.

Citation:

---

Envoyé par Mrsky

Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur :aie: (https://www.npmjs.com/package/arrify).

---

Je ne suis qu'un débutant en programmation, mais je dois dire que j'ai beaucoup ri. :mrgreen: J'ai d'ailleurs fait partager le lien.