Discussion :

[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, 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

[GreatDeveloperOnizuka]

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

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

[Invité]

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.

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.

de plus bientôt on aura aussi les pwa

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

[youtpout978]

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

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

[mermich]

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.

[Sodium]

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

[Invité]

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.

[Invité]

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

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

[Sodium]

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

[Xinsura]

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.

[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 ...

[Aizen64]

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.

[Sodium]

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

[Invité]

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.

[Invité]

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.

Il est où le framework complet backend en JS ?

sails.js ?

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

[Sodium]

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.

[fredoche]

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

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.

[Aizen64]

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 !

[Invité]

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.

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.

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.

[Marco46]

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

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

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.

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.

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.