Discussion :

[rccc_]

4 messages sur le forum, et tu insultes déjà les auteurs d'articles, tout en faisant de la pub pour un autre site. Chapeau bas l'artiste. A moins que ce soit humoristique?

Je ne fais pas de pub. Répond sur le fond, cet article c'est du grand n'importe quoi. Les commentaires sont ouverts à tous apparemment, même à ceux qui ont pondu 4 commentaires

[rccc_]

Ou peut-être qu'ils réutilise des trucs qui fonctionnent déjà parce que leur but est de faire une application pour répondre aux besoin de leur client plutôt que réinventer la roue et se prendre pour les rois du monde.

RTuy sais bien qu'il ne s'agit pas de ça, il s'agit de gens non compétents qui empilent des librairies qu'ils ne maitrisent pas.

[Sodium]

Mais peut-être que s'ils ne sont pas compétents c'est tout simplement parce que JavaScript n'est pas un langage qui donne envie d'acquérir de la compétence dessus.

C'est comme les gens qui s'amusent à faire du graphisme sous Paint pour le fun, d'accord avec assez de pratique on peut faire des choses impressionnantes mais les gens normaux préfèrent acquérir de la compétence sous Photoshop ou Illustrator.

Personnellement j'ai fait des tas de trucs en JS Vanilla, des sites one page, des jeux vidéos, des concours à la con, eh bien je confirme que JS ça reste toujours tout autant de la merde quel que soit le niveau d'expérience dessus, donc maintenant qu'il y a de meilleurs outils pour ça je les utilise.

[melka one]

Personnellement j'ai fait des tas de trucs en JS Vanilla, des sites one page, des jeux vidéos, des concours à la con, eh bien je confirme que JS ça reste toujours tout autant de la merde quel que soit le niveau d'expérience dessus, donc maintenant qu'il y a de meilleurs outils pour ça je les utilise.

ce serait pas plutôt j'ai essayer de faire.

[walfrat]

RTuy sais bien qu'il ne s'agit pas de ça, il s'agit de gens non compétents qui empilent des librairies qu'ils ne maitrisent pas.

Donc quoi ? Il faut s'être bouffer toutes les specs du JS et avoir 5 ans de pratique avant de faire un projet ?
Il faut aussi s'être manger toute la documentation d'une librairie et avoir au moins 3 ans de pratique avant de commencer ?

Bien que je ne doute pas qu'il y a des gens plus ou moins compétent la réalité est là : l'informatique est encore un domaine qui dans certaines parties manque de maturité et qui n'est pas stable. Le développement d'applications avec IHM en est un très bon exemple. Ceci peu aussi s'expliquer que quand il s'agit de développer des IHM, n'importe qui qui arrivent à empiler quelque copier/coller peuvent faire croire qu'ils pondront quelque chose de sérieux. Ce n'est évidemment pas le cas pour d'autres éléments tel que l'embarqué, le système,...

En outre si on veut aller plus loin on peut ressasser ce que tout le monde a déjà dit et redit :

• la gestion plus ou moins foireuse des projet
• les estimations des développeurs coupé en deux parce qu"on arriver quand même a faire marcher quelque chose"
• Les gens qui n'y connaissent rien qui imposent leur décision

Je fais partie de ces gens qui "empilent" des librairies/framework. Par "empiler" ici dans mon cas, j'aime à croire que quand je rajoute un dépendance c'est que j'en ai vraiment besoin, et je la prends pas parce que c'est le dernier truc à la mode. Et quand j'utilise le framework (surtout le framework, moins les librairies) parfois je le fais bien, parfois non. Ou parfois je commence à bien le faire, puis la demande change, encore et encore, pas la deadline par contre.

Mon point est que quand on voit le résultat d'un site et que c'est pas bon, c'est souvent l'empilement de plus d'un dysfonctionnement ou incompétence.

[Sodium]

Avec Angular on a au final très peu besoin de rajouter des dépendances non intégrées à l'écosystème. Ca n'en fait pas un facteur de stabilité parfaite, mais c'est déjà beaucoup mieux qu'un React qui n'est qu'un squelette sur lequel on vient greffer tout et n'importe quoi.

[partok]

Svelte

Svelte is a radical new approach to building user interfaces. Whereas traditional frameworks like React and Vue do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app.

Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the DOM when the state of your app changes.

[gbegreg]

Bonjour,

Je suis obligé de faire du React depuis plus d'un an maintenant et je dois dire que je n'accroche pas du tout mais bon il en faut pour tous les gouts. Pour moi, j'ai clairement l'impression d'être revenu dans les années 90 où il fallait tout faire à la main.

Le DOM et CSS sont ce que l'on a de mieux actuellement pour la conception d'interfaces responsives et multi-devices

Je ne suis pas du tout en accord avec et c'est d'ailleurs en partie pour cela que j'ai l'impression de revenir dans les années 90... Sans parler que même avec des frameworks tels que Bootstrap par exemple, il faut passer des tests sur tout un panel de navigateurs et versions (en entreprise on n'a pas toujours les dernières versions des navigateurs).

Dans cinq ans l'application pourra toujours être maintenue, avec du Delphi, Windev ou autre ça ne sera pas le cas. C'est sûr que c'est pratique d'avoir un système qui permet de générer des vues, des formulaires, des interfaces en trois clics, sauf que l'on est très vite bloqué dans ce que l'on souhaite faire et que l'on est définitivement marié avec le concepteur.

Dans 5 ans ton appli ne sera pas maintenue : elle aura été réécrite (peut être même plusieurs fois) en fonction des frameworks à la mode. Je développe aussi avec Delphi sans problème tout type d'application avec : Web, Mobile, Desktop sans avoir été limité ou bloqué par l'éditeur. C'est justement la force de pouvoir utiliser le créateur d'interface ou non en fonction des besoins. Les ihms sont en vectoriel et il est possible via un mécanisme d'héritage d'adapter au mieux ton interface en fonction de la cible (ce n'est pas la même utilisation sur pc doté d'un 1 ou plusieurs écrans que sur un smartphone 5 pouces ou une montre connectée). C'est à mon avis bien plus responsive et multi devices qu'une application web. En plus on peut s'appuyer sur les thèmes des OS donc l'utilisateur n'est pas perdu.
En plus, le maquettage est facilité et une autre personne qu'un dev peut le faire et cela peut être repris tel quel par le dev ensuite pas besoin d'un outil intermédiaire !

J'utilise et apprécie beaucoup VSCode et Teams par exemple basés sur Electron mais j'ai du mal à voir le bénéfice d'Electron. Il y a à mon sens bien mieux pour faire du natif multi device. Il suffit de lancer VSCode sans plugin sans ouvrir de projet : c'est tout de suite plus de 300 Mo de RAM occupé, Teams 800 Mo... Alors dire que c'est ultra léger...

tout en restant ultra-léger

Mais cela est une tendance générale malheureusement, les développeurs ne cherchent même plus à optimiser un minimum leur application. Si l'appli ralentit, on préfère la scaler différemment, lui ajouter des conteneurs, ajouter du CPU et de la RAM tant pis pour la consommation d'énergie...

[Sodium]

Je suis obligé de faire du React depuis plus d'un an maintenant et je dois dire que je n'accroche pas du tout mais bon il en faut pour tous les gouts. Pour moi, j'ai clairement l'impression d'être revenu dans les années 90 où il fallait tout faire à la main.

C'est normal, React est dans la philosophie JavaScript et reste du bricolage, ça permet juste de bricoler plus vite.

Je ne suis pas du tout en accord avec et c'est d'ailleurs en partie pour cela que j'ai l'impression de revenir dans les années 90... Sans parler que même avec des frameworks tels que Bootstrap par exemple, il faut passer des tests sur tout un panel de navigateurs et versions (en entreprise on n'a pas toujours les dernières versions des navigateurs).

C'est une question d'expérience, l'application que je développe actuellement est compatible Internet explorer 9 et je n'ai fait aucun effort particulier pour cela. Mais il faut bien connaître la technologie. Le CSS ce n'est pas facile, ça en a l'air mais ça ne l'est absolument pas, ça nécessite de l'expérience et une très bonne connaissance de ses sélecteurs et règles.

Dans 5 ans ton appli ne sera pas maintenue : elle aura été réécrite (peut être même plusieurs fois) en fonction des frameworks à la mode.

Non, je travaille dans une entreprise dont le chiffre d'affaire se compte en millions, hors de question de redévelopper quelque chose de stable s'il n'y a pas une valeur ajoutée considérable. C'est purement une question idéologique, personne ne met un fusil sur la tempe pour passer au dernier truc sorti, mise à part des décideurs incompétents. On ne peut pas attribuer la responsabilité de mauvais choix de technologie aux technologies en question.

Je développe aussi avec Delphi sans problème tout type d'application avec : Web, Mobile, Desktop sans avoir été limité ou bloqué par l'éditeur. C'est justement la force de pouvoir utiliser le créateur d'interface ou non en fonction des besoins.

Une tentative avait été faite (pas par moi) de développer une application en Delphi. Finalement ça s'est révélé impossible et c'est moi qui ai repris le projet... en Angular. Si tu considères que tu peux faire ce que tu veux en Delphi, c'est que tu ne travailles pas avec un graphiste et avec de grandes exigences en design et qualité d'interface utilisateur.

Ca fait vingt ans que les gens ici travaillent sur du Delphi. Pour une fois on a décidé de faire les choses correctement et d'utiliser les ressources du département graphique pour faire une application de qualité. Eh bien avec Delphi, ça ne fonctionne pas. Mais si tu as de super contre-exemples je veux bien être mise face à mes erreurs.

J'utilise et apprécie beaucoup VSCode et Teams par exemple basés sur Electron mais j'ai du mal à voir le bénéfice d'Electron. Il y a à mon sens bien mieux pour faire du natif multi device.

Non, ça n'existe pas, et c'est pour cela que les développeurs se sont peu à peu tournés vers les technologies web, notamment vu la galère que c'était de maintenir une application juste compatible iOS/Android. Delphi est une technologie d'un autre âge dont on ferait mieux de débrancher de le respirateur. Le problème c'est que le développeur veut avant tout développer vite est a très peu d'exigence en terme de qualité d'Interface utilisateur.

Il suffit de lancer VSCode sans plugin sans ouvrir de projet : c'est tout de suite plus de 300 Mo de RAM occupé, Teams 800 Mo... Alors dire que c'est ultra léger...

Mais cela est une tendance générale malheureusement, les développeurs ne cherchent même plus à optimiser un minimum leur application. Si l'appli ralentit, on préfère la scaler différemment, lui ajouter des conteneurs, ajouter du CPU et de la RAM tant pis pour la consommation d'énergie...

Ce n'est pas que les développeurs ne cherchent plus à optimiser leurs applications, c'est que les applications ne font plus la même chose qu'il y a dix ans, et nos machines n'ont pas les mêmes ressources qu'il y a dix ans. 300mo ce n'est rien, Chrome me prend la même chose juste pour maintenir mon plugin Hangouts.

Juste par curiosité, si tu lances un Eclipse, un Visual Studio ou Delphi ça prend combien ?

[gbegreg]

C'est une question d'expérience, l'application que je développe actuellement est compatible Internet explorer 9 et je n'ai fait aucun effort particulier pour cela. Mais il faut bien connaître la technologie. Le CSS ce n'est pas facile, ça en a l'air mais ça ne l'est absolument pas, ça nécessite de l'expérience et une très bonne connaissance de ses sélecteurs et règles.

Tout à fait d'accord, le css n'est pas simple et c'est une question d'expérience. D'ailleurs, c'est valable pour n'importe quel langage.

Non, je travaille dans une entreprise dont le chiffre d'affaire se compte en millions, hors de question de redévelopper quelque chose de stable s'il n'y a pas une valeur ajoutée considérable. C'est purement une question idéologique, personne ne met un fusil sur la tempe pour passer au dernier truc sorti, mise à part des décideurs incompétents. On ne peut pas attribuer la responsabilité de mauvais choix de technologie aux technologies en question.

Moi aussi, je travaille dans une grande entreprise et il s'avère que si on laisse vieillir une application stable qui répond au besoin tôt ou tard cela se transformera en dette technique (la version du framework utilisé est ancienne et les impacts seront importants pour migrer vers la nouvelle version du framework, parce qu'une dépendance n'existe plus etc...).

Une tentative avait été faite (pas par moi) de développer une application en Delphi. Finalement ça s'est révélé impossible et c'est moi qui ai repris le projet... en Angular. Si tu considères que tu peux faire ce que tu veux en Delphi, c'est que tu ne travailles pas avec un graphiste et avec de grandes exigences en design et qualité d'interface utilisateur.

Si je travaille avec des UX designer...

Ca fait vingt ans que les gens ici travaillent sur du Delphi. Pour une fois on a décidé de faire les choses correctement et d'utiliser les ressources du département graphique pour faire une application de qualité. Eh bien avec Delphi, ça ne fonctionne pas. Mais si tu as de super contre-exemples je veux bien être mise face à mes erreurs.

Justement, ces personnes qui travaillent depuis plus de 20 ans avec Delphi utilisent ils les dernières versions ? Le framework multi plateforme (Firemonkey) ?

Et voici quelques exemples d'applications récentes faites avec Delphi qui disposent d'interfaces stylées :

A titre personnel, ma dernière petite démo (ce n'est pas une application complète), mais elle fait environ 500 lignes de code, fonctionne sans pb (et avec le même code) sous Windows, Linux, MacOS, Android et IOS (pour le coup, je ne suis pas graphiste) :

Non, ça n'existe pas, et c'est pour cela que les développeurs se sont peu à peu tournés vers les technologies web, notamment vu la galère que c'était de maintenir une application juste compatible iOS/Android. Delphi est une technologie d'un autre âge dont on ferait mieux de débrancher de le respirateur. Le problème c'est que le développeur veut avant tout développer vite est a très peu d'exigence en terme de qualité d'Interface utilisateur.

Si ça existe (cf les exemples ci dessus). Delphi n'est pas une technologie : c'est l'IDE RAD Studio couplé au compilateur Pascal Objet d'Embarcadero. Si on couple RAD Studio avec le compilateur C++ d'Embarcadero, c'est C++ Builder.
Et pour la petite histoire Delphi et Javascript ont le même âge et les deux ont beaucoup évolué depuis leur apparition

Les frameworks Electron et autres (React native...) ne sont là que pour permettre aux développeurs qui n'ont fait que du web de faire à moindre couts (pour eux) des applications natives. Regardez aussi les consommations électriques de ces applications sur des appareils mobiles où l'autonomie est aussi un critère important des clients finaux.

Ce n'est pas que les développeurs ne cherchent plus à optimiser leurs applications, c'est que les applications ne font plus la même chose qu'il y a dix ans, et nos machines n'ont pas les mêmes ressources qu'il y a dix ans. 300mo ce n'est rien, Chrome me prend la même chose juste pour maintenir mon plugin Hangouts.

Les applications font toujours les mêmes choses : des IHM, des bases de données, des besoins utilisateurs à combler. Ce qui est certain c'est que les délais pour répondre aux utilisateurs se sont réduits et qu'il faut aller toujours plus vite. Ce qui peut expliquer le manque d'optimisations mais comme tu le disais c'est aussi une question d'expérience.

Juste par curiosité, si tu lances un Eclipse, un Visual Studio ou Delphi ça prend combien ?

Pas de pb :


NB : Delphi en version 10.4 Sydney, VSCOde en version 1.46, Eclipse en 4.16 (juin 2020). A chaque fois IDE démarré, aucun projet ouvert.

[Sodium]

Moi aussi, je travaille dans une grande entreprise et il s'avère que si on laisse vieillir une application stable qui répond au besoin tôt ou tard cela se transformera en dette technique (la version du framework utilisé est ancienne et les impacts seront importants pour migrer vers la nouvelle version du framework, parce qu'une dépendance n'existe plus etc...).

Ca sera vrai sur n'importe quelle technologie. Ne pas migrer vers le nouveau framework à la mode, ce n'est pas la même chose que d'acquérir de la dette technique.

Justement, ces personnes qui travaillent depuis plus de 20 ans avec Delphi utilisent ils les dernières versions ? Le framework multi plateforme (Firemonkey) ?

Pour les nouvelles applications oui, les anciennes sont du Delphi 7 et il a fallu engager des personnes spécialement pour les maintenir...

Et voici quelques exemples d'applications récentes faites avec Delphi qui disposent d'interfaces stylées :

La première ce sont des vues très simples et de l'interactivité simple. Ca n'existe a priori pas sur desktop, bien que j'avoue avoir la flemme de vérifier.

Fl Studio je l'utilise, très franchement niveau UX c'est loin d'une référence, c'est même très en dessous de la concurrence à mon humble avis. Apparemment ils ont galéré énormément à sortir une version MacOS (ce qui est un peu un problème vu que MacOS est bien installé niveau création audio. Est-ce la même base de programmation pour la version mobile ? J'en doute fortement, l'interface n'a rien à voir, elle est d'ailleurs beaucoup plus jolies (l'avantage surtout d'être sorti d'une dette technique...).

L'application de dessin c'est de l'api graphique pour le dessin, je ne vois pas vraiment le rapport, et les menus ressemblent à du Windows 98. Même remarque pour les jeu vidéo, c'est du jeu vidéo, pas de l'application multi-devices.

Les frameworks Electron et autres (React native...) ne sont là que pour permettre aux développeurs qui n'ont fait que du web de faire à moindre couts (pour eux) des applications natives. Regardez aussi les consommations électriques de ces applications sur des appareils mobiles où l'autonomie est aussi un critère important des clients finaux.

C'est partiellement vrai, c'est effectivement devenu populaire par question de facilité de dev car maintenir des applications iOS/Android est très vite devenu un casse-tête pour les développeurs lorsqu'Android s'est popularisé.

Par contre, le fait que le DOM soit devenu aussi populaire n'est qu'une prise de conscience de sa puissance en terme de conception d'interface. Le "je ne peux pas faire ça" dans ce domaine ça n'existe pas.

Par ailleurs, penses-tu honnêtement que les équipes de Microsoft aient développé VSCode en JavaScript par paresse ou par incompétence ? Et penses-tu réellement qu'il serait devenu probablement l'éditeur le plus populaire s'il s'agissait d'un soft de mauvaise qualité

Pas de pb :

NB : Delphi en version 10.4 Sydney, VSCOde en version 1.46, Eclipse en 4.16 (juin 2020). A chaque fois IDE démarré, aucun projet ouvert.

Effectivement, impressionnant, après il faut voir en utilisant réelle, et considérer également que Delphi fait du Delphi tandis que VSCode fait à peu près tous les langages imaginables avec des armées de plugins pour leur prise en charge ainsi que sa customisation. Note que VSCode sans projet ouvert je tombe à 160mo, avec un projet je monte à 230mo et 400 avec deux instances et deux projets ouverts.

[gbegreg]

Pour les nouvelles applications oui, les anciennes sont du Delphi 7 et il a fallu engager des personnes spécialement pour les maintenir...

Delphi 7 c'était en 2002, il y a 18 ans (Windows XP venait juste de sortir...). Même si les applications fonctionnaient et étaient stables, le fait de ne pas les avoir maintenues à jour à créer de la dette technique. C'est quand même une belle preuve de longévité qu'elles aient pu passer Vista, Seven, 8 et Windows 10 !

La première ce sont des vues très simples et de l'interactivité simple. Ca n'existe a priori pas sur desktop, bien que j'avoue avoir la flemme de vérifier.

Fl Studio je l'utilise, très franchement niveau UX c'est loin d'une référence, c'est même très en dessous de la concurrence à mon humble avis. Apparemment ils ont galéré énormément à sortir une version MacOS (ce qui est un peu un problème vu que MacOS est bien installé niveau création audio. Est-ce la même base de programmation pour la version mobile ? J'en doute fortement, l'interface n'a rien à voir, elle est d'ailleurs beaucoup plus jolies (l'avantage surtout d'être sorti d'une dette technique...).

Les goûts et les couleurs , on a chacun son avis mais tu ne peux pas dire que l'interface n'a pas été travaillée avec des graphistes. Et si la version mobile (depuis la version 3) est faite aussi avec Delphi.

L'application de dessin c'est de l'api graphique pour le dessin, je ne vois pas vraiment le rapport, et les menus ressemblent à du Windows 98. Même remarque pour les jeu vidéo, c'est du jeu vidéo, pas de l'application multi-devices.

L'application de dessin avec l'interface du stylet et sa représentation graphique en 3D qui s'incline, s'oriente en fonction du stylet et la pression qui est gérée...
Pour le jeu, l'interface l'interface est travaillée (ce n'est pas encore multi device (utilisation de DirectX) mais c'est dans les tuyaux...).

Je t'ai donné quelques exemples divers et variés car tu parlais de travailler avec un graphiste et que ça n'était pas possible à faire en Delphi. Je serai bien curieux de voir ce qui n'est pas réalisable en Delphi mais qui le soit en Angular...

Par contre, le fait que le DOM soit devenu aussi populaire n'est qu'une prise de conscience de sa puissance en terme de conception d'interface. Le "je ne peux pas faire ça" dans ce domaine ça n'existe pas.

Du moment que l'on a la main sur le graphisme, on peut faire tout ce que l'on veut. L'avantage de jouer avec le DOM c'est que ça tourne dans une application Web. Ça ne montre en rien sa puissance en terme de conception d'interface.

Par ailleurs, penses-tu honnêtement que les équipes de Microsoft aient développé VSCode en JavaScript par paresse ou par incompétence ?

Non je pense qu'ils l'ont fait pour contrer Atom qui commençait à devenir populaire. Il se sont appuyer sur les mêmes briques pour le concurrencer et le dépasser rapidement.

Et penses-tu réellement qu'il serait devenu probablement l'éditeur le plus populaire s'il s'agissait d'un soft de mauvaise qualité

Pour moi la qualité d'un soft ne dépend pas du langage utilisé. L'utilisateur se fiche pas mal de la techno utilisée : il veut que l'application fasse ce pourquoi elle est prévue de manière fiable et si en plus elle peut être agréable c'est un plus indéniable (mais les goûts et les couleurs je me répète...).

[Sodium]

Le principe des logiciels tels que Delphi est de fournir une interface graphique pour créer des applications, de fournir des briques utilisables facilement pour créer des éléments d'interface. C'est pratique, mais ça trouve forcément ses limites, les éléments sont conçus pour être personnalisés et adaptés jusqu'à un certain point. Ca a été le cas avec les éditeurs web tels que Dreamweaver ou plus récemment Adobe Muse mais plus aucun développeur sérieux ne travaille avec ça.

Le DOM et CSS c'est exactement l'inverse, rien n'est rien et tout est tout. Il n'y a, à part les éléments de formulaires qui sont d'ailleurs souvent substitués pour plus de contrôle, rien qui ait un rôle particulier, tout se fait à la main et le développeur doit donc immédiatement apprendre à utiliser le peu qu'il a à sa disposition pour remplir les besoins de plus en plus poussés en termes d'interface. Ca signifie qu'il a plus de boulot. Ca signifie aussi qu'il n'y a pas de limites. Le tout séparé en trois couches distinctes, le DOM, le CSS et JavaScript, parfaitement adaptés à la représentation code d'un rendu graphique.

Alors, peut-être qu'avec assez de maîtrise, quand on génère l'ensemble du code source soi-même plutôt qu'avec l'éditeur Delphi, on peut faire la même chose. Mais alors pour s'infliger de travailler son IDE, se marier avec un éditeur qui peut abandonner complètement le support, l'absence d'une vraie communauté derrière et surtout... travailler en Pascal, brrr.

Oui, l'utilisateur se fout complètement dans quel langage est développé le logiciel qu'il utilise. Sauf que, si VSCode est actuellement l'un des éditeurs préférés des développeurs c'est que... eh bien la technologie utilisée pour le faire est adaptée à cela.

[frfancha]

C'est normal, React est dans la philosophie JavaScript et reste du bricolage, ça permet juste de bricoler plus vite

C'est ton opinion, ce n'est pas la seule possible.
Nous utilisons React pour toute nos applications depuis trois mois (après 6 ans d'angularjs) et ce n'est absolument pas du "bricolage". Note aussi que tout est en Typescript.

Dans 5 ans ton appli ne sera pas maintenue : elle aura été réécrite (peut être même plusieurs fois) en fonction des frameworks à la mode.

Merci pour ce moment.
Va dire ça en entreprise qui tourne Cobol, ou encore des app VB6 avec des composants VB4 qui bloquent la migration Windows 10...

[Sodium]

Boucle d'affichage en Angular :

Code :

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

1
2
3
<select>
    <option *ngFor="let i of numbers">{{i}}</option>
</select>

Boucle d'affichage en React :

Code :

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

1
2
3
4
5
<select>
    {
       numbers.map(el => <option value={el} key={el}> {el} </option>)
    }
</select>

Je pense que ça se passe de commentaire.

Et ça c'est sans même aborder l'ignoble mélange de scripting et de rendu de vue, séparer la vue de la logique c'est tout de même le point un de toute application lisible.

[gbegreg]

Le principe des logiciels tels que Delphi est de fournir une interface graphique pour créer des applications, de fournir des briques utilisables facilement pour créer des éléments d'interface. C'est pratique, mais ça trouve forcément ses limites, les éléments sont conçus pour être personnalisés et adaptés jusqu'à un certain point.

C'est très pratique et ça couvre facilement 80% des cas les plus fréquents que l'on trouve dans une application. C'est un gain de temps appréciable sur la majorité des applications demandées. On peut alors passer plus de temps sur l'implémentation des règles métiers, les tests...

Le DOM et CSS c'est exactement l'inverse, rien n'est rien et tout est tout. Il n'y a, à part les éléments de formulaires qui sont d'ailleurs souvent substitués pour plus de contrôle, rien qui ait un rôle particulier, tout se fait à la main et le développeur doit donc immédiatement apprendre à utiliser le peu qu'il a à sa disposition pour remplir les besoins de plus en plus poussés en termes d'interface. Ca signifie qu'il a plus de boulot. Ca signifie aussi qu'il n'y a pas de limites. Le tout séparé en trois couches distinctes, le DOM, le CSS et JavaScript, parfaitement adaptés à la représentation code d'un rendu graphique.

Les besoins particuliers en interface peuvent être gérés manuellement aussi en Delphi, il n'y a donc pas de limite non plus. Ça demandera alors forcément plus de temps et de tests. Ca signifie plus de boulot mais aussi plus de risque de bug du coup.

et surtout... travailler en Pascal, brrr.

Affaire de goût toujours... et il a évolué depuis Delphi 7 !!!

Sauf que, si VSCode est actuellement l'un des éditeurs préférés des développeurs c'est que... eh bien la technologie utilisée pour le faire est adaptée à cela.

Non c'est plutôt que l'outil est adapté au besoin mais en rien que la technologie utilisée pour le faire est adaptée.

Mais j'attends toujours un exemple d'ihm faisable en Angular et pas avec Delphi

Merci pour ce moment.
Va dire ça en entreprise qui tourne Cobol, ou encore des app VB6 avec des composants VB4 qui bloquent la migration Windows 10...

Ben justement dans mon entreprise il y a toujours et pour encore un moment du Cobol. Sauf que (même si c'est possible) on ne l'utilise pas pour les IHM, il est côté back sur des serveurs Unix. Or, la conversation était basée sur les ihm.

[Sodium]

C'est très pratique et ça couvre facilement 80% des cas les plus fréquents que l'on trouve dans une application. C'est un gain de temps appréciable sur la majorité des applications demandées. On peut alors passer plus de temps sur l'implémentation des règles métiers, les tests...

Ouep, 80% des cas, jusqu'au moment où on te demande un truc et où tu es obligé de répondre je peux pas fai

Mais j'attends toujours un exemple d'ihm faisable en Angular et pas avec Delphi

Boah je ne sais pas, si je te demande de faire un menu horizontal et que lorsque je clique sur un élément il décolle et se transforme en boule dont le background est un flux Youtube que je puisse m'amuser à faire rebondir contre les bords de l'écran ça te prend combien de temps ?

[frfancha]

Boucle d'affichage en Angular :

Code :

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

1
2
3
<select>
    <option *ngFor="let i of numbers">{{i}}</option>
</select>

Boucle d'affichage en React :

Code :

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

1
2
3
4
5
<select>
    {
       numbers.map(el => <option value={el} key={el}> {el} </option>)
    }
</select>

Je pense que ça se passe de commentaire.

Ben si faisons-en de commentaire, et même deux:

1) Le code React de création des options est beaucoup plus puissant puisqu'il dispose de tout ce que Typescript offre, on n'est pas limité à ce qu'offre Angular dans ngFor
2) Mais surtout, il n'est pas nécessaire d'apprendre un langage spécifique au framework

Pour moi y a pas photo React est loin devant.

Et c'est vraiment marrant ton exemple, parce que tu sembles aimer dans Angular les possibilités spécifiques prédéfinies et limitées, le genre de chose que tu reproches à Delphi d'autre part

[frfancha]

Ben justement dans mon entreprise il y a toujours et pour encore un moment du Cobol. Sauf que (même si c'est possible) on ne l'utilise pas pour les IHM, il est côté back sur des serveurs Unix. Or, la conversation était basée sur les ihm.

Oui merci je sais que cobol est côté back end, et encore certaines grandes banques utilisent encore des écrans "verts" pilotés en cobol.
Mais oui c'est très rare, à la limite si on voit des écrans verts ce seront plutôt des AS/400 avec du RPG.
Néanmoins mon exemple était sur le conservatisme de l'entreprise en général, cobol n'était qu'un exemple, l'autre étant VB6 avec composant VB4 dont plus personne n'a la source qui bloque le pasage à Windows 10, et là on est bien dans IHM

[Sodium]

Le code React de création des options est beaucoup plus puissant puisqu'il dispose de tout ce que Typescript offre, on n'est pas limité à ce qu'offre Angular dans ngFor

Le ngFor il peut faire à peu près tout et n'importe quoi. C'est juste qu'entre gens civilisés, on sépare cette logique du template.

2) Mais surtout, il n'est pas nécessaire d'apprendre un langage spécifique au framework

Quel langage exactement ?

Pour moi y a pas photo React est loin devant.

Oui, en terme de popularité car faire de l'Angular requière de la rigueur et de bonnes pratiques de programmation tandis que React demande... ben de savoir faire du JavaScript quoi

Et c'est vraiment marrant ton exemple, parce que tu sembles aimer dans Angular les possibilités spécifiques prédéfinies et limitées, le genre de chose que tu reproches à Delphi d'autre part

Quelles possibilités spécifiques et prédéterminées exactement ? Mon exemple est très simple, passer la balise en positionnement fixe, lui appliquer une classe CSS et mettre une balise Youtube dedans. Bon après faut rajouter un petit moteur physique en JavaScript, mais je l'ai déjà fait et je suis une brèle en math donc ça ne doit pas être si compliqué.

Par ailleurs, je parlais de la technologie DOM-CSS-JavaScript, pas d'Angular spécifiquement.

Néanmoins mon exemple était sur le conservatisme de l'entreprise en général, cobol n'était qu'un exemple, l'autre étant VB6 avec composant VB4 dont plus personne n'a la source qui bloque le pasage à Windows 10, et là on est bien dans IHM

C'est plutôt la philosophie des informaticiens de manière générale, si ça marche on y touche pas. Si ça marchouille et que ça a dix ans on y touche encore moins car il n'y a plus personne qui sait comment ça marche.