
Envoyé par
defZero
Oui, effectivement, moi aussi je ferais un "site" avec auth plus vite en web qu'en client lourd, tout simplement parce que ça n'as aucun sens de "faire du web avec du client lourd"

(je plaisante, mais je croit avoir comprit l'idée).
Et puis, ça doit aussi à voir avec ton expérience.
Evidemment, j'ai fais plus de web que de client lourd, mais j'ai tout même fait du Swing et aussi du JavaFX, et il y a des points qui prennent plus de temps, exemple bête : aligner des libelles/champs de formulaire et aussi éventuellement s'adapter à la résolution de l'écran. Personnellement après m'être arraché les cheveux pendant quelque jours, j'ai lâché l'affaire et considéré une résolution fixe (c'était de la R&D, donc ça passe).
Pense qu'un développeur qui fait du client lourd toute la journée fume n'importe quel dev web ("finger in the nose", moi comprit

) pour faire une UI métier (temps de compilation et interactivité de l'UI comprit).
J'ai pas croisé le premier cas, mais je ne vais pas spécialement commenter

Le web pour faire des Applis métier, c'est juste à défaut d'avoir des technologies cross-plateform valable et "gratuite" pour les Entreprises (et accessoirement, de la main d’œuvre pas cher

).
N'oublie pas la facilité de déploiement, c'est le principal atout pour faire du web en entreprise, plutôt que le cross plateforme (ils sont tous sur Windows de toute façon).
Les techno ont évolués certes, mais certains essai de tout faire en web, alors que ce n'est juste pas comparable / pas les mêmes usages.
On est d'accord.
Euh, ... La validation des data, ok, mais ça c'est un fait que tout ce qui rentre dans ton appli doit être validé, client lourd ou léger, d'avant ou d'aujourd'hui, c'est pareille.
Même une entrée système/utilisateur local doit être parsé et validé avant traitement (j’espère que tout le monde fait ça

).
Mon point c'était que faire tout les petits retour utilisateurs qui gère sont largement mieux gérer de base en Web que en client lourd, de ma propre expérience évidemment (angularJS/Angular vs Swing / JavaFX). Évidemment c'est parce que le Web considère la gestion de formulaire comme "native" alors que Swing et JavaFX, n'ont pas spécialement des éléments très poussés pour la gestion de formulaire de base.
Et il faut pas oublier de revalider les entrée utilisateurs côté serveurs, évidemment

.
Par contre, en ce qui concerne le rendus utilisateur (et je l'est déjà écrit ici sur un fils de discussion concernant l'UI), les frameworks d'UI pour client lourd, font tout le job et sont largement moins galère que le web (qui n'est juste pas fait pour ça à la base).
D’ailleurs ce n'est pas un hasard si les framework d'UI Web tendent à mimer des idées/comportements de framework d'UI pour client lourd (composants web, rendu dans canvas, ...etc).
Et puis, dire que HTML, CSS et JS sont plus "avancé" aujourd'hui, ce n'est pas vraiment le cas (pas taper

, j'explique).
- HTML à supprimer certaine balises et en a ajouter d'autre pour ajouter de la sémantique (du sens), alors évidemment c'est une bonne chose, mais fondamentalement, rien n'as changé.
HTML est un langage de balisage pour organisé un document texte, et pas une technologie d'UI révolutionnaire.
Ce n'est pas le bon outil pour le job. - CSS lui c'est vraiment transformé, mais dans le fond, il ne sert qu'à la mise en page du document HTML qui vient derrière.
De plus il est loin d'être "bien plus simple" qu'un framework d'UI pour client lourd.
P.S. : Alors pourquoi de plus en plus de framework gui l'utilise me direz-vous ? Et bien peut être pour mettre à la portés des très nombreux dev web leur outils.
Au contraire, il tend à ce complexifier avec l'age, ce qui est une preuve en soit d'un manque quelque part, non ?.
Combien de personnes sont capable de l'utiliser à sont plein potentiel ?
Et je parle pas de 4 @keyframes qui ce touches pour faire de l'animation
.
Honnêtement, pas moi, même si je peut faire de jolies animations et de belles mises en page, ça demande quand même pas mal d'effort, quand un client lourd en QML ou VCL aura déjà probablement ce que je veut dans une lib ou autre sans devoir modifier mon code par ailleurs pour coller à ma présentation (Merci qui ? Merci DOM/VDOM/ShadowDOM).
Qui n'as jamais du toucher sont HTML pour "permettre" de faire ce que le client voulait en CSS ?
C'est comme devoir recoder une partie de son appli parce que l'on veut mettre un spinner au chargement, c'est limite non ? - JS lui aussi c'est transformer, malheureusement il est resté rétrocompatible avec lui même et ça sa le plombe directement.
Quand on fait du client lourd, on est relativement confient quant aux comportements de notre appli, alors qu'avec un client léger, vous êtes complétement dépendant du client utilisé par vos utilisateurs.
Ok, Chrome à un quasi monopole, mais ayant connu l'aire IE6 et le faite de se reposer sur un client tiers totalement indépendant de vous ou de vos usager, d'expérience, c'est jouer la confiance
.
J'ai effectivement pas très bien dit ce que je voulais dire, je pensais simplement plus à l'évolution des technos et le langage, que le langage lui-même.
Et quand je vois le templating Angular (même angularJS) et le templating JavaFX, y'a aucun doute que c'est le templating Angular qui gagne.
Disons que pour ton appli de gestion de données, il faudra que tu fasse en "client léger", du HTML, CSS, JS + du backend (donc serveur / proxy HTTP, ...etc + ton coeur de métier avec le langage X), ça n'as de léger que le nom à mon avis.
Alors qu'avec (je reprend ton exemple en JFX) ton "client lourd", tu fait une UI en JavaFX/TornadoFX/...etc (AWT ?

) et tu code ton app en Java/Kotlin/...etc (et en prime, ton "client lourd" sera plus léger que ton "client léger"

.
Sachant qu'avec ton appli lourd, tu contrôlera tout de A à Z et le comportement est relativement uniforme et stable (ça fait un moment que les différentes résolutions peuvent être prisent en charge par les framework ui "lourd"

.
Quand je parle de client léger, je parle de la définition formelle à savoir pas de déploiement de ton appli sur les client, puisque les navigateurs sont là. Aussi quand je parle de la progression sur 20ans, e pense aussi au fait que l'ère IE6/7/8
est terminée, heureusement pour nous, même si ce n'est pas encore parfait.
D'accord la plateforme web est flexible, mais comme écrit précédemment c'est à défaut de mieux qu'elle c'est imposé face au client lourd, pas par ces méritent intrinsec.
La plateforme web est faites pour la manipulation de documents texte et l'a toujours était.
L'avantage qu'elle a acquit, c'est de disposer de clients/browser sur toutes les plateformes existantes, mais un client lourd ciblant une plateforme donné, donnera toujours de meilleurs résultats que l'utilisation du web hors de sont domaine de prédilection (site web et présentation de documents).
Il faut définir "meilleur résultat". Le web est pratique pour faire des pages relativement "simple" qui n'ont pas des dizaines de milliers de noeuds HTML (la magie du CSS fait qu'on n'est plus limité que sur un client lourd, sauf si on prend des Canvas et qu'on fait tous à la main).
Personnellement les deux points qui m'ont fâche quand je suis passé sur client lourd c'est :
Les formulaires (validation, rendu utilisateur, alignement des champs, résolution, bref formulaire aux petit oignons)
La navigation
Pourquoi ? Parce que ces mécaniques sont largement plus intégrées nativement dans le web que dans Swing/JavaFX où il faut gérer cela soi même (toujours de mon expérience). Et il s'avère que quand on fait des applis qui font une grosse partie de la gestion de données, ce qu'on fait principalement ce sont :
Des tableaux
Des formulaires
De la navigation
Des requêtes vers le serveur.
Bon y'a la sérialisation native dans JS en JSON mais c'est pas assez significatif pour que je le mette en bon point par rapport au client lourd (sérialisation java, oui bien sur, embarquée dans du SOAP

).
Pour moi le "meilleur résultat" c'est de pouvoir répondre aux specs dans les coûts et avoir un truc maintenable. Et autant dire qu'une fois qu'on est rôdé à Angular, je trouve largement plus maintenable des templates ou je peux exprimer un maximum de choses et de conditions dans celui-ci et gérer le framework, que de gérer plus de choses à la main. Et oui, je sais que Angular c'est pas gratuit en perf, c'est pour a que j'utilisais Ag-grid, grille native avec intégration Angular, et pas grille Angular.
Ma propre expérience est basée sur ce que j'ai appris par moi-même a travers différents tuto pour te mettre le pieds à l'étrier, que ce soit en Web et JavaFX (j'ai fait info en école d'ingé mais on apprend pas spécialement à faire du Web ou du Swing).
Je ne prétend pas pouvoir déterminer ce qu'un maître du client lourd vs un maître du client léger peut faire. Déjà je crois pas tant que ça de personnes qui sont juste capable d'être à l'aise dans une techno et comprendre comment elle fonctionne, alors trouver des experts... (les vrais, pas ceux qui sont juste le seul a connaître la techno dans la boîte ). Si on me demande, je suis un dev intémédiaire, mais on préfère me dire que je suis à un plus haut niveau.
0 |
1 |