J'avais tort.
Dans le débat, client Web vs Programme, ou client léger sous forme d'un navigateur web vs client lourd à installer sur un poste, j'ai toujours penché du côté du client lourd.
Pour une application relativement simple, ou un usage relativement simple, le client léger me parait bien adapté. Mais dès que l'application devient un poil complexe, que les interactions avec l'usager sont variées, qu'on doit gérer des contrôles/widgets un peu tordus, le client lourd me parait plus adapté.
La raison en est simple: pour faire des applications élaborées, il faut aller plus loin que des boutons, des checkbox et des combo box. On va avoir du drag'n drop, des widgets aux contours variés, un besoin d'interactivité très forte avec beaucoup de réactivité. Par essence, le web introduit de la latence, et les contrôles complexes sont plus dur à gérer.
Mais là, une application m'a prouvé que je pouvais me tromper.
J'avais besoin d'éditer des diagramme de flux, et de décrire un business model pour un projet. D'habitude je fais ça avec Visio et le résultat est moyen mais acceptable. Depuis des années, je cherche une application potable pour faire ce genre de chose facilement mais force est de constater que c'est difficile de trouver mon bonheur. Mes contraintes sont difficiles : je fais ça deux fois par an, donc je ne vais pas investir sur une courbe d'apprentissage. Et je suis mauvais en design, donc il faut que l'application comble un minimum la mocheté de tout ce que je vais produire. Visio s'en sort raisonnablement mais reste moyen, les outils libres sont inutilisables dans le cadre de mon besoin. Il y a longtemps, Draw sous windows (issue de MacDraw) s'en sortait pas mal.
En tout cas, je me suis laissé aller à essayer un truc web: lucidchart . D'après la page d'accueil, c'est top moumoute pour ce que je dois en faire.
Et là, j'ai été bluffé:
* l'application est super réactive !
* les interactions sont agréables et intelligentes
* l'application est très bien pensée, il y a plein de petits détails qui font que c'est rapide à prendre en main, rapide à améliorer et que le rendu est bon.
* à ce jour, c'est la meilleure application que j'ai utilisé pour ce genre de tâche
Je me tâte même à prendre l'abonnement payant… bien que mon besoin soit trop ponctuel pour que ça se justifie.
Pour en revenir à mon débat de fond, c'est un exemple concret d'application web qui fournit des services de meilleure qualité qu'un client lourd, et ce précisément dans les zones où les clients lourds sont censés avoir l'avantage (interactivité, qualité du rendu graphique, complexité des interactions).
Cela veut dire que les navigateurs web ont atteint un niveau de maturité suffisant pour remplacer un client lourd. Je sais que beaucoup ici en étaient probablement déjà persuadés, mais moi pas du tout!
Alors ne nous emballons pas quand même.
La qualité de l'application est due avant tout à la qualité de son ergonomie et la même équipe pourrait très probablement produire une application version client lourd de même qualité.
Et il reste très facile sous couvert d'application web à la mode, de produire un truc peu réactif, pas pratique à utiliser et qui plante dès que tu le pousses dans ses retranchements.
Il reste aussi un gros inconvénient: je peux pas utiliser l'application dans le train. Je passe à peu près 1h15 dans le train tous les jours, sur une ligne où même les communication voix sont coupées toutes les deux minutes tellement ça capte pas, alors j'ose pas imaginer ce que ça donnerait avec cette application…
Mais c'est une grande victoire du web sur le vieux con réfractaire que je suis.
Je m'interroge d'ailleurs sur la qualité de cette application. Je trouve que globalement, l'ergonomie des applications lourdes de nos jours laisse particulièrement à désirer. Avec l'avènement du mobile, et des facteurs de forme réduits, des interactions un peu complexes, des applications qui sont évaluées en moins de 3 minutes par les utilisateurs donc doivent être bonnes dès le départ, l'ergonomie a été revue comme un critère premier de succès d'une application.
C'est à mon sens cette tendance qui font qu'un truc web comme LucidChart a peu être mieux conçu et est plus agréable à utiliser qu'un client lourd qui pourtant part beaucoup mieux armé sur ce marché.
Donc bravo à l'équipe qui a fait ça! Je serai curieux de savoir ce qu'ils utilisent comme pile logiciel derrière pour faire ce beau résultat.
Ah oui, je précise bien sur: c'est propriétaire, close-source, payant dès que tu utilises plus de 50 formes (autant dire au bout de 2h) et je sais pas si ça marche bien sous Linux. Mais c'est un journal, on peut parler de ce qu'on veut [ajouter le disclaimer habituel]
# moef
Posté par fredix . Évalué à 10. Dernière modification le 18 juillet 2013 à 11:15.
Ca fait quelques années qu'il y a des apps web complexe qui s'approchent du natifs, rien que celles de Google..
Le problème est que pour faire une app web complexe il faut maîtriser 3 tonnes de libs JS/CSS/HTML des framework, des outils de backend.
Avec une app native, il suffit de maîtriser Qt et c'est tout. Développer avec Qt est bien plus rapide, cependant il manque le gros truc, le stockage sur Internet des données qui est de fait avec une app web.
Si les devs natifs utilisaient un outil comme engin.io l'utilisateur aurait l'avantage du web et celui du natif ; comme il y a sur Mac avec les apps qui utilisent iCloud ….
Il parait que le natif sur le desktop c'est plus à la mode, sauf sur les Mac bien sur. Mais je suis convaincu que le natif n'a pas dis son dernier mot, loin de là.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: moef
Posté par fredix . Évalué à 3.
J'ai commencé comme développeur web, et je revis depuis que je fais du Qt/C++. Pour ceux que C++ fait peur, Qt/Python semble très bien marcher.
Mais le vrai problème est lorsque tu veux que ton app stocke les données utilisateur sur ton serveur, par exemple pour les rendre accessible par une interface web si le user n'a pas son ordi avec lui, ou s'il en a un autre et souhaite donc synchroniser les données. Tu n'as pas ce genre de problème avec une app web. Apple qui a bien compris l'intérêt de protéger son business juteux des apps native propose une API iCloud aux devs.
[^] # Re: moef
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
intégrer un truc comme camlistore, c'est trop difficile ? pas assez mature ?
"La première sécurité est la liberté"
[^] # Re: moef
Posté par fredix . Évalué à 3.
En effet camlistore montre qu'il y a un début de prise de conscience du problème et je ne doute pas qu'il y ait des solutions libre qui arrivent.
[^] # Re: moef
Posté par LaBienPensanceMaTuer . Évalué à 3.
J'ai jamais fait de QT … mais du GTK.
Et ma conclusion est la même que fork_bomb: faire des UI en web, c'est qd même 'achement plus simple !
[^] # Re: moef
Posté par téthis . Évalué à 4.
Gtk n'est pas non plus ce qu'on a fait de plus simple en UI. Il faut écrire un tas de code et de transtypage —n'abordons même pas le mise en œuvre de l'objet– pour arriver à quelque chose qui marchotte. Glade permet de s'abstraire d'une partie des tâches, les languages hauts niveau, comme Vala, ou l'utilisation de l'introspection Gobject permet de faire des choses intéressantes assez facilement, par exemple un pad en lua-lgi.
J'ai réalisé un simili-centre de contrôle (plusieurs iconviews pour les catégories, détection automatique des applis de paramétrages) en lua-lgi en 112 lignes. Bon ok, Il ne fonctionne pas correctement sur la distro cible (Ubuntu 12.04) mais ça peut-être la faute à la trop grande différence de version entre Gtk 3.0 installé sur Ubuntu et celui installé sur ma machine (une distro bleeding edge arquée) ou la différence de version de binding lgi car il pleure que les signaux ne peuvent pas tous être connectés.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: moef
Posté par Gilles G. . Évalué à 6.
Mon expérience à moi:
- deux applis "moyennes" avec Qt4, et quelques autres bricoles toujours avec Qt4.
- Récemment, j'ai fait une nouvelle appli avec un tout petit serveur local et une WebView pour l'interface graphique. L'interface est donc en HTML/CSS/javascript, mais ça tourne en local.
La raison pour laquelle j'ai choisi cette nouvelle façon de faire? Un de mes collègues avait déjà fait du dev web, il pouvait ainsi participer.
Ben il faut bien avouer que le html ça fonctionne très bien.
Un des gros avantages des techno web c'est la facilité de debug de l'interface graphique: on se retrouve tout de suite avec quelque chose qui fonctionne, on peut inspecter avec firebug pour modifier en live le CSS, etc. Au final, c'était beaucoup plus facile d'expérimenter différentes interfaces et je pense que nous n'aurions pas réussi à faire aussi bien avec du natif, tout simplement parce que l'expérimentation est trop couteuse.
Sinon, il y a l'aspect documentation/entraide: il y a toujours quelqu'un qui a été confronté au même problème que toi, donc on trouve toujours une solution rapide aux problèmes web.
Un autre aspect vraiment positif des technos web est la séparation naturelle entre la partie graphique et la partie métier (serveur); je trouvais cette limite plus difficile à définir avec Qt4.
Par ailleurs, le cycle de dev est beaucoup plus rapide avec les technos web:
- on évite la phase de compilation, et franchement avec Qt4 c'est loooong…
- on n'a pas besoin de makefile/moc: un soucis en moins
- on peut ajouter/supprimer des fichiers/images/icones/etc sans se poser de question. Avec Qt4 je me retrouvais avec des question du genre: ai-je bien déclaré cette icone en ressource?
Enfin, un truc sympa, c'est que l'on a pu réutiliser des parties de l'appli pour mettre sur notre site web. C'était facile à faire, et les clients sont contents.
Evidemment, ça ne convient pas à tous les styles d'applis, mais dans notre cas, c'était le bon choix.
[^] # Re: moef
Posté par akimatsumoto . Évalué à 2.
Dans ce cas là, une approche du style QtQuick peut peut-être t'aider. La partie graphique en qml, le cœur de l'appli en c++
[^] # Re: moef
Posté par dave_null (site web personnel) . Évalué à 0.
Mais ça ne tournera pas sur «insérer ici une technologie pas encore sortie qui fera tourner du HTML5» sans aucune action de ta part.
[^] # Re: moef
Posté par claudex . Évalué à 3.
Et en plus, il y a QMLWeb pour récupérer des partie pour son site web.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: moef
Posté par Grunt . Évalué à 10.
Ah ah, la bonne blague. Non, ça ne s'approche pas, même pas de loin. L'impression de performances correctes vient du fait qu'on a maintenant des puissances de calcul phénoménales (il suffit de passer sur un PC d'il y a 10 ans pour voir la différence), et du fait que la quasi-totalité des fonctionnalités d'une appli native sont sacrifiées lors du passage au Web.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: moef
Posté par zebul0n (site web personnel) . Évalué à 3.
D'un autre coté, sur un PC d'il y a 10 ans, tu constateras qu'une appli native d'aujourd'hui en prends aussi pour son grade…
[^] # Re: moef
Posté par Grunt . Évalué à 10.
Non non. Sur un PC d'il y a 10 ans, VLC arrive à lire une vidéo (certes pas en H264), là où dans un navigateur c'est impossible (que ce soit avec la balise idoine ou le plugin à daube). Il est parfaitement possible d'utiliser mutt, là où Gmail est impraticable si on ne le passe pas en version HTML simple. Causer sur IRC (avec irssi, kvirc..) se passe facilement, alors que les applis Web de chat proposent soit un massacre des fonctionnalités (où sont les logs, où sont les raccourcis claviers..) soit un fonctionnement poussif. Et ainsi de suite.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: moef
Posté par barmic . Évalué à 5.
C'est bien des exemples mais en sortir des généralités à la noix… Prenons gimp, LibO, Gnome, KDE, Dolphin,… Ah oui le constat est différent. Tu compare des logiciels choisis (mutt, irssi) avec « les appli web ».
Pour ce qui est de la vidéo j'ai un gros doute sur ce que tu dis. Fait faire du streaming à un firefox récent (via gstreamer) et vlc.
Mais la question la plus importante est : à quoi ça sert ? Mon éditeur de texte pourrait probablement se lancer sur une calculatrice graphique un peu avancé, mais quel est l'intérêt ? Si c'était aussi mauvais que tu l'imagine pourquoi tant de monde (tu en as des exemples ici) le font ? C'est plus simple à écrire, ils arrivent mieux à faire quelque chose de portable, le déploiement est trivial,… Il n'y a pas que la performance en informatique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: moef
Posté par Olivier Serve (site web personnel) . Évalué à 0.
Gimp, OpenOffice, Gnome, KDE n'existaient pas il y a 10 ans ?
[^] # Re: moef
Posté par barmic . Évalué à 1.
Si on test ce qu'il y avait il y a 10 ans sur du matériel d'il y a 10 ans ça n'a aucun intérêt (déjà que tester les version d'aujourd'hui dessus n'en a pas beaucoup…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: moef
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Sa réponse semble à côté de la plaque, mais ça me fait quand même un peu penser à un gros avantage pour les clients lourds : tu peux retrouver une vieille version d'un logiciel pour une vieille plateforme.
Pour les app web, par contre….
[^] # Re: moef
Posté par barmic . Évalué à 1.
La problématique est tout à fait identique. Tu peux ou non avoir accès à l'ancienne version des logiciels.
DirectX tu peux pas. SPIP tu peut remonter jusqu'à 2009 avec des archives et pour aller plus loin tu as leur dépôt.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: moef
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
C'est identique dans l'absolu mais en réalité, ce n'est pas dans la culture des logiciels web que de donner l'accès aux anciennes versions, alors que ça l'est beaucoup plus pour les applications natives.
Pour DirectX, tu as ça, par exemple http://www.oldversion.fr/windows/directx/
[^] # Re: moef
Posté par barmic . Évalué à 1.
Dans l'absolu c'est toujours pareil, la seule manière d'être à peu près sur de pouvoir récupérer une vielle version c'est que ce soit du logiciel libre.
À moins que ça ai changé depuis XP impossible de downgrader DirectX. D'ailleurs c'est un sacré problème ça, généralement les applications natives ont une adhérence bien plus forte au système d'exploitation. Pour faire fonctionner le Gnome d'il y a 10 ans il te faut une bonne gtk d'il y a 10 ans, la glic d'il y a 10 ans, gstreamer d'il y a 10 ans, etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: moef
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Bref, une distribution d'il y a 10 ans. Pas de problème, ça se trouve.
[^] # Re: moef
Posté par barmic . Évalué à 1.
Oui dans le libre, pareil avec des web app libres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: moef
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Pas seulement. Un CD d'installation de Windows XP ou 2000, voire 95, j'en ai encore.
Revenir à l'interface Google d'il y a 10 ans m'est impossible.
[^] # Re: moef
Posté par Olivier Serve (site web personnel) . Évalué à 1.
C'est exactement ce que je voulais souligner.
Les applications web sont mises à jour en continu, c'est bien… et pas bien. Un utilisateur ne pas revenir à une version plus ancienne, moins lourde de GMail, Yahoo, Facebook… Alors que son logiciel « lourd » vieux de 10 ans fonctionnera toujours.
# La même (ou presque) en libre
Posté par Clément David (site web personnel) . Évalué à 10.
Une application très similaire en libre existe : mxGraph avec une démonstration sur le site draw.io.
Cette librairie possède à la fois une implémentation en Java (JGraphX) comme en JavaScript (mxGraph) ce qui te permet de choisir entre client lourd ou application web avec les mêmes fonctionnalités.
[^] # Re: La même (ou presque) en libre
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Super !
Merci pour l'info. J'ai été voir la démo, ça ressemble à Pencil (Pas le truc de Mac mais le machin qui tourne sous Firefox 3+/SeaMonkey/XULRunner), mais en un peu mieux a priori.
C'est libre et ça à l'air de bien tourner. Reste à voir la difficulté (ou non) pour l'installer sur un serveur. Ça pourrait être une bonne solution en entreprise et ça permet d'avoir un outil qui tourne bien quelque soit l'OS (je vois souvent une mixité d'OS au boulot).
Rah je comprends pas que je l'ai pas trouvé quand je cherchais un logiciel libre pour faire ce genre de choses y'a un an. J'ai mal dû cherché.
Bref, encore merci !
[^] # Re: La même (ou presque) en libre
Posté par Naabster . Évalué à 2.
Un grand merci pour la découverte.
Je vais tester cela de ce pas.
[^] # Re: La même (ou presque) en libre
Posté par totof2000 . Évalué à 5.
Je te mets ton 10eme et dernier pertinentage. Pour ce genre de lien, on devrait pouvoir débrayer la limite des 10 "pertinentages". Si je t'avais en face de moi, j'aurais du mal à m'empêcher de t'embrasser (à moins que tu sois le sosie de Stallman … avc ma barbe dure ça ferait "velcro" ;)
[^] # Libre ?
Posté par Faya . Évalué à 4.
Je n'ai pas trouvé de lien vers les sources et voici la license :
http://www.jgraph.com/mxlicense.html
[^] # Re: La même (ou presque) en libre
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Heu, c'est où que c'est libre ?
Moi, je lis là : http://jgraph.github.io/mxgraph/docs/manual.html#1.5
« The JavaScript client of mxGraph is licensed under a standard commercial license For detailed licensing questions you are always advised to consult a legal professional. »
Sinon, l'outil est vraiment sympa !
Merci
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas d'accord
Posté par flagos . Évalué à 4.
Et après tu vas voir une démo de Firefox OS sur un de leur téléphones (d'ailleurs ils étaient aux rmll): tout est en html5, le téléphone est basique de chez basique, et ca tourne pas si mal. Ca lague un peu mais ca a l'air carrément mieux que ce qui se fait sur android pour une configuration équivalente.
Je t'avoue avoir été surpris mais en fait, il doit carrément y avoir moyen de faire du html5 performant. Pour ca, je pense qu'il faudrait un framework un peu bien qui évite que le codeur du dimanche sape les perfs en écrivant n'importe quoi dans la partie JS, style des load massifs et brutaux toutes les 2 secondes.
[^] # Re: Pas d'accord
Posté par totof2000 . Évalué à 3.
Moi je dirais plutôt qu'l faudrait interdire aux codeurs du dimanche de coder, ça évitera qu'il sape les perfs tout court; Parce qu'avec un framework, le codeur du dimanche ne va pas se transformer tout à coup en codeur du lundi (ou du mardi, ou n'importe quel autre jor d'ailleurs). Je pense que ce sera pire encore : le framework va ajouter sa popre couche d'abstraction donc plus de lenteur. Et un développeu web qui n'est pas capable de se pencher sur le HTML5 et le Javascript de base, il devrait changer de métier et aller changer des pneus chez Norauto ou Midas.
[^] # Re: Pas d'accord
Posté par Parleur . Évalué à 3.
C'est triste ton estime pour les changeurs de pneus.
[^] # Re: Pas d'accord
Posté par totof2000 . Évalué à 2. Dernière modification le 20 juillet 2013 à 12:31.
Je n'ai rien contre les changeurs de pneus, qui pour baucop péfèreraient faire autre chose. PAr contre j'ai une dent ontre les pseudos développeurs qui ne veulent pas réfléchir et apprendre à connaitre leur environnement (et il y en a … ). Dans ce cas, un métier comme changeur de pneu (ou tu n'as qu'a répéter les mêmes mouvements sans trop te poser de question) leur conviendrait bien mieux.
[^] # Re: Pas d'accord
Posté par flagos . Évalué à 3.
Disons qu'en javascript, ca devient tellement facile d'enchainer les call sur différents évenements qu'a la fin tu maitrises plus vraiment les appels à droite à gauche. Ca finit par faire des interfaces qui rament alors que tu n'as fait qu'ajouter ton petit grain de sel.
[^] # Re: Pas d'accord
Posté par fredix . Évalué à 2.
J'utilise les apps Evernote, Twitter et Spotify sur Mac, c'est à des années lumières des versions web… Plus de features, avec des effets visuel fluide et sexy (merci cocoa), le "web" n'est utilisé que pour transporter les données, ou bien pour afficher de l'HTML au sein de l'app (itunes,steam, spotify) ce qui est beaucoup plus intéressant.
Evidement ca nécessite un dev pour une plateforme contrairement au web, mais quand un user paye un bras son Mac il est en droit d'attendre qu'une application exploite au mieux les capacités de l'OS via ses API, plutôt qu'une stack web immonde en comparaison du rendu.
[^] # Re: Pas d'accord
Posté par Jean B . Évalué à 5. Dernière modification le 18 juillet 2013 à 15:27.
La majeure partie de Spotify est une WebKit View. Tout comme le client Steam.
[^] # Re: Pas d'accord
Posté par fredix . Évalué à 2.
Sauf la gestion des DRM, et le téléchargement, qui est en P2P sur spotify, voir aussi sur steam. Tout ce que ne sait pas faire le web donc. Ca me semble une utilisation intelligente du web, l'utiliser pour afficher des données au contraire de faire des "apps" en web.
[^] # Re: Pas d'accord
Posté par barmic . Évalué à 9.
Sauf qu'il n'a pas dis que les applications web sont légères, il a dis qu'elle peuvent l'être. Comme des applications lourdes peuvent être lourdes ou légères.
Un jour la communauté de LinuxFR arrêteront de troller sur tel ou tel langage pour comprendre qu'à part des cas particuliers, les techno sont largement assez véloces.
Un jour la communauté de LinuxFR arrêteront de troller sur les performances pour comprendre que ce n'est pas le seul critère de qualité logiciel et que la correction, l'ergonomie, la maintenabilité, la sécurité ou la portabilité (liste non-exhaustive) peuvent être plus importantes.
C'est agréable de rêver de temps en temps :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas d'accord
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 18 juillet 2013 à 16:59.
Ce n'est pas une question de langage mais de la différence d'architecture et des possibilités et limitations qui en découlent, entre l'exécution d'un programme sur une machine virtuelle, plus ou moins standardisée (Firefox/Chrome/IE/etc…) et l'exécution d'un code compilé adapté à chaque machine.
?
Les applis web n'ont pas détrôné les applis natives sur l'ergonomie. Pas pour l'ensemble des applications.
Le déploiement est plus facile car centralisé, c'est vrai.
Même réponse que pour l'ergonomie. Les approches sont juste différentes.
Oui mais si on prend l'exemple du rendu par CSS entre les différents navigateurs il faut écrire 3 fois le « même code » pour que ça fonctionne partout et la liberté est laissée au développeur d'utiliser des propriétés implémentées sur un seul navigateur, moteur.
Et je ne troll pas.
[^] # Re: Pas d'accord
Posté par fredix . Évalué à 2.
En natif c'est également possible, via l'app store, les dépots linux et le windows store. Idem sur les smartphones. Cet argument en faveur du web est caduc.
Concernant la portabilité, une app Qt est compilable telle quelle sur les 3 OS, et Qt5.1 vient d'être porté sur Android et iOS. QML renforce en plus cette portabilité.
[^] # Re: Pas d'accord
Posté par CrEv (site web personnel) . Évalué à 6.
Heu non ce n'est pas caduc, bien au contraire.
Pour une app web, tu as une URL à maintenir, un dépôt quoi.
Pour du natif tu as quoi ?
Franchement côté facilité de déploiement on a vu mieux.
[^] # Re: Pas d'accord
Posté par Alex . Évalué à 5.
Et surtout rien ne garanti que les utilisateurs font leur maj
Pour une appli web, tes utilisateurs utilisent toujours la version que tu mets à disposition
[^] # Re: Pas d'accord
Posté par zul (site web personnel) . Évalué à 3.
Oui, même si la nouvelle version a de nouveaux bugs bloquants pour son utilisation ou des features supprimées :)
[^] # Re: Pas d'accord
Posté par SidStyler . Évalué à 1.
C'est vrai, mais rien ne t'empêche non plus dans cette architecture d'avoir une URL pointant vers une version N-1 ou au contraire vers la version N+1 pour la tester.
Après c'est comme d'habitude, tu fais un peu ce que tu veux. Sur un client lourd, si tu ne permets pas de télécharger une ancienne version, c'est le même problème.
[^] # Re: Pas d'accord
Posté par Alex . Évalué à 2.
Je ne suis pas pro de la dev web, mais je ne ne pas que cela soit une bonne idée
si tes schémas ont changés par exemple, il devient complexe de garder une cohérence entre les divers versions de l'applis.
Pis bon, franchement, les utilisateurs, de nos jours, qui en a quelque chose à foutre ? ;)
[^] # Re: Pas d'accord
Posté par barmic . Évalué à 2. Dernière modification le 18 juillet 2013 à 17:58.
Il est très rare d'avoir dans les contraintes d'un logiciel d'être aussi rapide que possible. Il est plus généralement demandé d'être suffisamment rapide ou fluide et de tenir une charge donnée. Les machines virtuelles arrivent de mieux en mieux à obtenir ces performances. Bien sûr qu'elles seront toujours plus lente qu'une application faite pour la performance dans un langage compilé en natif avec un compilateur qui va bien, mais l'écart de différence n'est pas forcément intéressant.
Le fait d'être correct, de ne pas avoir de faute/d'erreur.
Je n'ai pas dis le contraire. Je dis juste que ce n'est pas parce que c'est du web que c'est moins ergonomique.
Il ne s'agit pas que de cela. Il faut pouvoir faire évoluer les fonctionnalités du logiciel.
Alors tu n'a simplement pas compris ce que je voulais dire. contrairement à ce que beaucoup pensent par ici, être contre les applications web, c'est de la bataille de clochet inutile. Ce type d'applications sont capables de rivaliser dans la majorité des cas avec des applications natives. Il faut voir au cas par cas plutôt que de s'insurger contre les applications web.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas d'accord
Posté par totof2000 . Évalué à 3. Dernière modification le 18 juillet 2013 à 22:08.
[^] # Re: Pas d'accord
Posté par fearan . Évalué à 3.
on bosse pas vraiment dans le même métier ;) Chez mes clients, la contrainte temps est primordiale; quand un calcul de d'état du réseau se fait toutes les 5 minutes voire moins, rendre le résultat en 4 minutes est hors de question; de même lorsqu'un calcul fait naïvement prend 2H, baisser le temps de calcul (autrement qu'en augmentant encore la puissance des machine de calculs) fait partie des priorité.
Toujours dans la même optique si ton calcul d'itinéraire en transport en commun parisien prends 15 minutes, le trajet qu'il t'indique est déjà caduc.
Si à chaque clique tu a 2/3 secondes de lag, ton utilisateurs il va aller voir ailleurs.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pas d'accord
Posté par claudex . Évalué à 3.
Si tu avais lu la phrase d'après, ça aurais répondu à toutes tes critiques.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas d'accord
Posté par barmic . Évalué à 4.
Je n'ai pas parlé de mon métier ou du tiens, j'ai parlé de généralité.
C'est précisément ce que j'ai dis. Ce sont des cas où tu indique une contrainte (rendre le résultat en un temps donné) et pas il faut être le plus rapide immaginable.
La différence est importante car dans un cas tu va toujours pouvoir troller en expliquant qu'en assembleur t'es capable de faire mieux (d'ailleurs si le système d'exploitation arrêtait de faire de la merde ça t'arrangerais bien), alors que dans l'autre tu es tout à fait capable d'estimer si une techno de plus haut niveau peut faire l'affaire ou pas et on voit ces dernières années que plus ça va plus les techno de haut niveau en sont capables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas d'accord
Posté par flagos . Évalué à 3.
T'as pas l'impression d'exagérer un peu ? Aujourd'hui, à part 2-3 hacks si tu utilises des trucs pas encore super bien normalisés, tu as quasiment un rendu au pixel près partout pareil.
Non non pas du tout :-)
[^] # Re: Pas d'accord
Posté par Grunt . Évalué à 3.
Et le rendu au pixel près, ça sert à quoi ?
http://www.hteumeuleu.fr/pixel-perfect/
Avec une appli native on n'a pas de rendu au pixel près, loin de là (par exemple chaque client mail a sa propre allure) et c'est tant mieux : ça permet de choisir côté client le look qu'on préfère. Pourquoi on ne pourrait pas choisir son navigateur en fonction du rendu, selon ses préférences personnelles ? Pourquoi, bon sang, ce serait celui qui propose le service qui décide de la façon dont on l'affiche, et qui en décide (et gaspille du fric pour ça) au pixel près ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Pas d'accord
Posté par flagos . Évalué à 2.
Ca permet d'éviter de devoir patcher pour chaque configuration OS-navigateur. Et c'était justement le troll auquel je répondais.
Le pixel près, c'est le CSS qui le détermine. A partir du moment où la mise en forme est définie par le css, il ne doit pas y avoir de zones floues sur son interprétation. Quand quelqu'un s'est pris la tête a définir un ombrage pour qu'il soit précis, le rendu ne devrait pas différer, c'est clairement un cas d'imprécision de la norme.
Par contre, je suis pour que CSS permette d'utiliser des styles par défaut et que le navigateur puisse appliquer le rendu qui convienne selon l'OS ou le navigateur. Ca se trouve ca existe cela dit, je suis pas assez spécialiste.
[^] # Re: Pas d'accord
Posté par maboiteaspam . Évalué à 0.
tu blâmes l'implémentation pas la techno…. Et de toute façon toute les sociétés qui font de la com. vont pousser le html5, les apps finiront par crever tout bonnement par leur inadéquations à s'intégrer dans un processus globale. m'enfin c'est pas pour demain matin non plus… c'est comme ie6 ont va se traîner le boulet un bout de temps encore, youpiii.
# Liens ?
Posté par Mimoza . Évalué à 4.
Journal intéressant mais un petit lien vers le site en question aurait été pratique.
http://www.lucidchart.com/
Sinon dans le genre petit soft sympa qui permet de faire rapidement et simplement ce qu'on lui demande il y a balsamiq mockup qui est vraiment sympa pour faire des maquettes d'interface utilisateur sans que le client se focalise sur la couleur du bouton de la maquette.
[^] # Re: Liens ?
Posté par ziliss . Évalué à 2.
Proposition dans le suivi: un petit avertissement lorsqu'un journal ne contient pas de lien.
# Un choix à faire
Posté par Jérôme Flesch (site web personnel) . Évalué à 1. Dernière modification le 18 juillet 2013 à 11:28.
En résumé, je crois qu'à l'heure actuelle, les choix possibles sont les suivants:
1) Un client lourd : peut être simple à installer, peut être libre, et est généralement réactif
2) Un client léger auto-hébergé : presque toujours compliqué à installer, peut être libre, et est généralement peu réactif
3) Un client léger hébergé par une entreprise tierce : aucune installation, jamais libre, peut être réactif, mais (comme mis en évidence par les histoires de PRISM/NSA récemment) pose des problèmes de confidentialité
Personnellement, je ne pense pas qu'il y ait une solution qui résolve tout les problèmes. J'ai opté pour un mix des 3 en fonctions de mes besoins (confidentialité, simplicité, etc).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un choix à faire
Posté par maboiteaspam . Évalué à 2.
Mh. Non. En node js tu fais un serveur en 8 lignes de code, espacement compris.
cross platform, suffisamment véloce et en parfait adéquation avec ton UI.
En soit node c'est moins de 10mo. Et tu n'es pas obligé d'être connecté à internet, tu peux faire un tarball qui contient tout.
Démo:
[^] # Re: Un choix à faire
Posté par Philippe F (site web personnel) . Évalué à 1.
Euh, c'est une blague ?
A part sous Windows où un client lourd est effectivement simple à installer la première fois, l'installation d'un client lourd est le problème numéro 1 des clients lourds.
Allons-y:
1. Sous Linux, c'est un tel bordel de distribution, version de la libc, version compatible de ta pile graphique que tu peux y passer des mois. Cf tous les posts de Zenitram sur le sujet.
Sous Windows, c'est relativement simple si ton utilisateur n'est pas dans un environnement professionnel contraint (genre pas les droits administrateurs). Sinon, c'est vite la zone.
Sous Mac, je crois que c'est relativement simple mais il faut découvrir la plate-forme et acquérir du savoir Apple.
Quand tu veux faire une mise à jour, le début du cauchemar commence. Comment encourager -forcer- ses utilisateurs à utiliser la bonne version ?
Au final, vive les App Store, qui ont au moins la vertu de permettre des mises à jour faciles.
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Tu as raison.
Mais Jérôme a raison aussi, son point de vue était celui d'un utilisateur, pas du développeur de l'appli qui lui doit gérer l'enfer des plateformes.
Mais pour te rejoindre, en ce moment je fais une appli Qt + QML (principalement pour découvrir QML), je kiffe grave, mais je repousse au maximum le moment où je vais devoir m'attaquer au déploiement sous linux et windows, d'expérience, je sens que ça ne va pas mais alors PAS DU TOUT me plaire.
[^] # Re: Un choix à faire
Posté par Adrien . Évalué à 3.
Faut pas non plus être traumatiser hein. Si tu fais bien ton appli, en particulier le système de build, le packaging devrait être relativement simple.
Par contre si tu commence à recompiler toutes tes dépendances, y compris les plus grosses (Qt, Python, etc.), à dépendre de plein de chose complètement exotique, à tout casser à chaque version, à avoir du code plus ou moins libre d'embarqué à larache, là c'est une autre paire de manche.
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Je prends un exemple, sous windows, un compilation statique d'une appli en Qt permet de réduire la taille de l'application à quelques mega.
Comme ma platforme principale est une archlinux, je n'ai pas envie d'investir pour une licence de visualstudio, j'utilise donc mingw.
Et compiler Qt5 en statique avec mingw, c'est déjà assez "rigolo".
Ensuite, si jamais j'y arrive, on me dit "ah mais oui mais tu peux pas parce qu'une appli QML, il faut un plugin et utiliser les libs dynamique de Qt".
Ok, donc j'en suis là actuellement ; il semble qu'on ne puisse pas distribuer une version complètement statique d'une application Qt QML/QtQuick et qu'il faille embarquer la ribambelle de DLL de Qt et sa horde de plugins.
En fait, je remarque que comme toujours, je galère essentiellement pour windows.
[^] # Re: Un choix à faire
Posté par Adrien . Évalué à 2.
Je te répond, pour le packaging Linux (Debian), pour windows je suis largement incompétent :
– compiler en statique, c'est une bonne idée ou pas ? perso je pense pas, mais chacun son opinion.
– embarquer des bibliothèques externes, bonne idée ou pas ? perso je pense vraiment pas une bonne idée.
Ensuite, Qt est packagé pour pas mal de distribution, dont Archlinux non ? du coup pourquoi vouloir l'embarquer ??
Bref j'ai l'impression qu'on retrouve l'éternel opposition du développeur, qui veut avancer très vite, quite à négliger l'installation, la sécurité, la maintenance, et l'admin système qui veut un truc carré, qui marche, sans trop de surprise.
[^] # Re: Un choix à faire
Posté par Marotte ⛧ . Évalué à 8.
Pour une « brique » logicielle c'est la moindre des choses !
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Pour les systèmes linux, je n'ai absolument aucune envie/besoin de distribuer un binaire linké statiquement, bien entendu… (mais j'ai eu besoin de le faire à une époque pour un projet pro prioprio qui devait tourner sur un grand nombre de distros car on avait ni le temps ni les compétences de faire des paquets)
[^] # Re: Un choix à faire
Posté par Philippe F (site web personnel) . Évalué à 2.
Tu galères sous Windows:
* parce que tu fais des optimisations à deux balles. A part les agités du linux, aujourd'hui, télécharger 200 Mo, c'est rien du tout. Je travaille régulièrement avec des utilisateurs lambda qui téléchargent une JVM pour faire tourner une appli. No problem ! Et je te parles bien du papy qui est sur le web. Donc exit la compilation statique ! Fait juste un installeur qui compresse à mort tes binaires et basta.
parce qu'il y a du savoir-faire spécifique à Windows que tu n'as pas. Mais c'est pas lié à Windows, c'est juste lié au fait que tu es un développeur inexpérimenté sous Windows. Un développeur inexpérimenté sous Linux galerera (à mon avis beaucoup plus que tu ne le fais pour Windows). Et idem pour MacOs. Oui, il y a des choses à savoir pour déployer sous Windows, mais infiniment moins à mon avis que pour déployer sous Linux.
parce que tu fais des choix techniques douteux. Compiler avec mingw sous Windows, c'est un peu comme installer un .deb sur une Fedora. C'est faisable mais vaut mieux pas. Les compilateurs de Windows sont disponibles en ligne de commande gratuitement, ça s'appelle les versions Express: http://www.microsoft.com/visualstudio/fra/products/visual-studio-express-products . De même sous MacOs, il est fortement recommandé de compiler avec le gcc livré avec ta version de MacOs. Sinon … problèmes subtils et pénibles. Et c'est pas la dernière version de gcc, tu peux me croire…
tu penses que tu ne galères pas sous Linux, mais as-tu fais un paquet qui s'installe déjà sur toutes les distributions majeures, en LTS et dernière version ? Ton application a-t-elle survecue à la mise à jour de la distrib lancée par le geek bleeding edge ? Reviens nous voir Zenitram et moi quand tu te seras farcie la réalité de la distribution sous Linux on reparlera du "je galère que sous Linux".
une autre raison pour galérer sous Windows, c'est d'utiliser des technos pas portable. Genre au hasard Gtk (ouh le petit troll) mais il y en a d'autres… . La plupart des applis Gtk ne sont plus packagées sous Windows, tous les développeurs ont jeté l'éponge… Et je te dit ça, c'est quand elles sont pas carrément passées à Qt.
[^] # Re: Un choix à faire
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est difficile, mais possible. Sous Windows, il n'y a pas de gestion de paquets…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
"rien du tout" ?!
Tu ne peux pas être sérieux.
Je ne veux pas que ma petite application de gestion de série soit aussi grosse que libreoffice, faut quand même pas déconner !
[^] # Re: Un choix à faire
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Il est tout ce qu'il y a de plus sérieux. Tout programme assez récent sous Windows prend de la place sur le disque dur qui se mesure en Go, à la limite en centaine de Mo. Hop un antivirus 2 Go supplémentaires…
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Un choix à faire
Posté par groumly . Évalué à 2.
Effectivement, c'est la derniere de clang. Et a partir de LOLcat 10.9, ya meme pu gcc-llvm.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un choix à faire
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Ce qui est normal vu que Mac OS X suit les évolutions de FreeBSD. FreeBSD 10.0 passe à Clang et abandonne GCC.
Veepee & UNIX-Experience
[^] # Re: Un choix à faire
Posté par groumly . Évalué à 4.
T'as remarque qui sont les commiteurs principaux sur clang/llvm et qui les paye?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un choix à faire
Posté par groumly . Évalué à 1.
2) ou utiliser l'appstore. Parait que ca fait un malheur sous ios, mais c'est des on dit. Le mac appstore est pas en reste cela dit.
3) encourager, c'est facile a faire. Forcer, c'est pas trop possible, et faut vivre avec.
Oui, c'est chiant, mais c'est la nature du mode distribution qui veut ca. Et la barriere psychologique au changement, qui fait que les gens n'aiment pas le changement.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un choix à faire
Posté par totof2000 . Évalué à 2.
4) un logiciel autonome: peut être lourd, difficile à installer, difficile à maintenir, ou avoir tous les défauts que tu cites mais aura une qualité inégalable : n'a pas besoin d'être connecté en permanence.
[^] # Re: Un choix à faire
Posté par barmic . Évalué à 4.
Sauf si l'appli web est codée en js et qu'elle utilise convenablement les possibilité offerte par le HTML5.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un choix à faire
Posté par claudex . Évalué à 4.
Ça dépend des client lourd, cf. les jeux avec DRM qui doivent se connecter toutes les 15 minutes à un serveur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un choix à faire
Posté par zebul0n (site web personnel) . Évalué à 2.
Je rajoute un 4) alors : Un client lourd qui enregistre les données dans le cloud hébergé par une entreprise tierce. Un client lourd peut aussi poser des problèmes de confidentialité.
# Un peu de thé ?
Posté par jigso . Évalué à 3.
Tu devrais jeter un coup d'oeil à Sencha : il y a principalement 2 libs, une pour le dev d'appli web sur le desktop (ExtJS), un autre pour appli mobiles (Sencha Touch).
C'est pas vraiment plus compliquer à apprendre que QT/GKT, juste que c'est en JavaScript.
Les examples : http://docs.sencha.com/extjs/4.2.1/extjs-build/examples/
[^] # Re: Un peu de thé ?
Posté par totof2000 . Évalué à 3.
On est sur linux**fr** ici.
[^] # Re: Un peu de thé ?
Posté par jigso . Évalué à 2.
Et tu veux pas des scrinechautes non plus ?
[^] # Re: Un peu de thé ?
Posté par Parleur . Évalué à 1.
Je me contenterais de captures d'ecran, merci.
# Mouais
Posté par fearan . Évalué à 5.
J'utilise pas mal la 'suite' office de google; mais coté réactivité et ergonomie on est à des années de ce qui se faisait avec star Office (oui vous avez bien lu).
C'est très pratique pour l'édition collaborative, la disponibilité quel que soit le lieu où je suis, mais maintenant pour l'édition collaborative je suis plus sur un wiki; je le garde la google office pour le tableur (très pratique pour les feuilles de perso PJ/PNJ, et rédiger les grandes lignes du scénar où que je sois)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Logiciels lourds toujours prédominants sur les clients légers
Posté par goeb . Évalué à 3.
Le client, léger ou lourd, est une toute petite part des logiciels.
J'avais vu dans un article que 80% du marché de l'informatique concerne l'informatique d'entreprise (industrie, services, etc.). Or l'informatique d'entreprise est gourmande de logiciels lourds (serveurs ou clients). Certes il existe en entreprise des interfaces web légères, mais le serveur (base de données par exemple), lui il est lourd.
Je pense que les logiciels lourds seront toujours prédominants sur les clients légers.
[^] # Re: Logiciels lourds toujours prédominants sur les clients légers
Posté par Alex . Évalué à 2.
Tu as des chiffres plus précis ?
Car j'ai tout de même qu'une infra "lourde" (db, serveur d'app, virtualisation, etc…) nourri un nombre supérieur de clients légers.
[^] # Re: Logiciels lourds toujours prédominants sur les clients légers
Posté par goeb . Évalué à 2.
Non, je n'ai pas de source ni de chiffre précis, et je suis d'accord que c'est un point à préciser.
Mais si on a 1 instance serveur et 1000 instances clientes, je pense qu'en temps de développement et de maintenance, c'est quand même le serveur qui coûte le plus. Car tous les clients sont des copies identiques du même logiciel, et le serveur a une complexité supérieure (répondre à toutes les requêtes clientes + gestion des accès concurrents, disque, haute disponibilité, etc.)
[^] # Re: Logiciels lourds toujours prédominants sur les clients légers
Posté par Alex . Évalué à 3.
Evidemment, mais:
- toutes les basses taches sont normalement prises en comptes par le serveur d'app
- vu qu'on était a la comapraison client lourd/leger: on gagne énormément en temps en dev/maintenance/déploiement
[^] # Re: Logiciels lourds toujours prédominants sur les clients légers
Posté par maboiteaspam . Évalué à 4.
En même temps on parle de clients là..
# Réactivité des clients légers.
Posté par Marotte ⛧ . Évalué à 4.
J'utilise pas mal de clients en JS+HTML, des webclients si on peut appeler ça ainsi, au boulot. Récemment j'ai changé de machine et je suis passé d'un dualcore Pentium 4 à un octocore i7. J'ai vraiment été surpris par la réactivité de l'interface des applications, on a la même sensation qu'avec un client lourd : ça réagit « instantanément », à condition que le navigateur ne soit pas en déjà en train de mouliner pour un autre onglet…
AJAX a apporté une énorme avancée en faveur des applications oueb mais dès que l'on va avoir besoin de widgets un peu particuliers ou gourmands (comme faire un tri rapide dans de longues listes ou afficher en temps réel des informations sous une forme graphique complexe) le client natif s'en sort encore mieux.
J'ai l'impression que la tendance est à la simplification des interfaces, ça expliquerait pourquoi bon nombre d'applications se contentent de « formulaires à boutons » avec à la rigueur une utilisation basique du glisser/déposer ou autres mouvements de souris. Le click-droit dans ton appli web tu peux l'oublier parce qu'il sert généralement déjà pour ton brouteur…
[^] # Re: Réactivité des clients légers.
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Pour l'application dont le journal cause et un bon nombre de celles de google par exemple, le bouton droit est exploité, et généralement fait apparaître un menu contextuel.
C'est moins choquant pour une application web que pour un site.
[^] # Re: Réactivité des clients légers.
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 18 juillet 2013 à 15:20.
Ah ouai tiens :) J'utilise le webmail GMail de manière vraiment basique, je préfère le client lourd pour gérer mes mails ! Rien que pour la possibilité d'agréger différentes adresses. Je sais que l'on peut souvent faire pareil en rapatriant ses mails chez l'un ou l'autre de ses fournisseurs mais bon…
D'ailleurs récemment GMail m'a trié mes mails en trois catégories, de mémoire : Defaut, Social et Commerical, sans que je n'ai rien demandé ou même accepté en me connectant ! On a l'impression d'avoir une secrétaire un peu trop zélée ça fait un peu peur :)
[^] # Re: Réactivité des clients légers.
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Oui, pareil, pas pu refuser la nouveauté tout de suite. Mais on peut revenir en arrière dans les préférences a posteriori.
[^] # Re: Réactivité des clients légers.
Posté par Marotte ⛧ . Évalué à 3.
J'ose l'espérer, je n'ai même pas pris le temps de regarder. Ça me laisse tout de même l'amer impression que si proposer des fonctionnalités en opt-out aux gens ça leur plaît, on va bientôt (encore plus) pouvoir leur faire faire n'importe quoi dans le but de consommer.
[^] # Re: Réactivité des clients légers.
Posté par ariasuni . Évalué à 1.
C'est des catégories personnalisables.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Réactivité des clients légers.
Posté par khivapia . Évalué à 2.
Récemment j'ai changé de machine et je suis passé d'un dualcore Pentium 4 à un octocore i7. J'ai vraiment été surpris par la réactivité de l'interface des applications,
Sur des clients web déployés sur des clients eux-mêmes lourds. Par contre, sur des téléphones, ça sera une autre paire de manches.
[^] # Re: Réactivité des clients légers.
Posté par dave_null (site web personnel) . Évalué à 1.
Oui parce que c'est bien connu que n'importe quel client lourd tourne sur un téléphone bas de gamme.
[^] # Re: Réactivité des clients légers.
Posté par totof2000 . Évalué à -1.
Tu devrais lire un bouquins de "bonnes pratiques" du développement d'interface web avant e dire de telles âneries.
[^] # Re: Réactivité des clients légers.
Posté par dave_null (site web personnel) . Évalué à 3.
Je vois pas le rapport, mon post est un message ironique sur le fait que les clients lourds déployés sur des téléphones, c'est pas forcément très utilisable non plus.
[^] # Re: Réactivité des clients légers.
Posté par totof2000 . Évalué à 3. Dernière modification le 18 juillet 2013 à 22:38.
Oups, désolé, mal compris ce que tu as écrit. La chaleur et le manque de sommeil m'ont encore plus ramolli le cerveau (en plus je n'avais pas vu l'ironie).
Fites-vous plaisir, moinssez moi.
[^] # Re: Réactivité des clients légers.
Posté par khivapia . Évalué à 3.
J'ai oublié de sourcer ;
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
m'a l'air assez pertinent.
[^] # Re: Réactivité des clients légers.
Posté par flan (site web personnel) . Évalué à 9.
Tu veux dire qu'avec un octoœur et une appli web, tu retrouves les perfs d'un client lourd avec un Pentium 4 ?
À se demander qui est vraiment le client lourd et qui est le client léger !
De mon côté, je suis toujours partagé entre les deux…
[^] # Re: Réactivité des clients légers.
Posté par barmic . Évalué à 2.
(sans troll)
Je suis intéressé, je n'ai pas encore trouvé de client e-mail qui me vienne. C'est quoi ton MUA ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Réactivité des clients légers.
Posté par flan (site web personnel) . Évalué à 1.
Ça ne devrait pas te plaire : Mail, sur OS X.
[^] # Re: Réactivité des clients légers.
Posté par fredix . Évalué à 2.
opera mail a l'air pas mal aussi.
[^] # Re: Réactivité des clients légers.
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
Le truc qui ne sait même pas replier les lignes ?
Je suis plusieurs listes sur lesquelles des gens utilisent ce machin, et c'est aussi pénible à lire que les bouzes issues d'outlook ou notes !
# Tout dépends de ce qu'on veut
Posté par Hodj . Évalué à 1.
J'ai commencé en C sou DOS puis je suis passé à C sous OS/2 puis à Java et enfin aux applis web.
L'avantage avec le client lourd c'est que tu peux faire beaucoup plus de choses car tu a accès à la totalité de la machine et donc tu peux modifier si tu en a besoin le comportement du système dans certains cas. Dans les applis web tu n'a accès qu'a une partie du navigateur donc tes possibilités sont beaucoup plus limitées.
Sans compter que je n'aime javascript.
[^] # Re: Tout dépends de ce qu'on veut
Posté par dave_null (site web personnel) . Évalué à 1.
Quand tu fais du web, tu n'as pas à avoir un accès total à la machine car tu fais une application pour tout types de machines.
[^] # Re: Tout dépends de ce qu'on veut
Posté par groumly . Évalué à 0.
Bollocks. Ou plutot, c'etait vrai en 2006, mais le monde a change un tantinet depuis, et maintenant c'est bollocks.
Tu fais une appli desktop, une telephone et une tablette.
La tendance responsive design n'est qu'un enrobage elegant, de la meme maniere qu'objc, les nibs et les fat binaries d'ios sont un enrobage elegant de plusieurs applis en une.
Ca ne te dispense pas de faire un bon design 3 fois, ni de penser tes api/usage de resources en fonction de la plateforme. Entre un telephone a usage extremement court et repete et un desktop, ya un monde niveau design.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Tout dépends de ce qu'on veut
Posté par dave_null (site web personnel) . Évalué à 0.
L'interface va certainement avoir des différences en fonction du support, mais ça fait partie du travail quand je dis qu'il faut développer l'application pour tout types de machines.
Et la remarque valait aussi pour l'accès bas niveau aux capacités de la machine.
# Ouais
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Curieux de nature, je suis allé lancer le soft et c'est vrai que ça trou le luc.
C'est assez désolant de se dire qu'un truc comme le module de libreoffice qui permet de faire de diagrammes et qui a de nombreuses années derrière lui n'a pas le dixième de l'ergonomie de cette appli… (oui je sais, j'ai qu'à contribuer…)
Rien que dans le détail par exemple :
- Le texte des flêches apparaît au dessus des flèches. Bin ouais, c'est con mais quand on veut faire apparaître du texte sur une flèche, on veut pouvoir le lire :)
- Relier les éléments avec des flèches est infiniment plus intuitif et peut démarrer depuis un bord de chaque élément
- Le texte des éléments est wrappé lorsqu'il commence à dépasser de l'élément
- On peut faire subir une rotation à n'importe quoi très facilement depuis l'élément
- …
# Dia
Posté par Marotte ⛧ . Évalué à 5.
Personne n'en a parlé c'est étonnant. J'avais utilisé Dia à une époque et je viens de le tester vite fait. Ça me semble très bien pour faire des diagramme et la bibliothèque d'objets ad hoc selon le type de diagramme couvre une vaste palette, de l'UML au routeur Cisco.
https://wiki.gnome.org/Dia
Les news datent un peu mais j'ai vérifié, le développement est bien actif.
Je ne crois pas que l'on puisse faire aussi ergonomique et efficace pour ce travail en JS, surtout si le diagramme est conséquent.
[^] # Re: Dia
Posté par barmic . Évalué à 7.
On parlait pas d'ergonomie ? Celle de Dia est pourrie. J'utilise toujours ce logiciel régulièrement parce qu'il n'est pas mauvais sauf son ergonomie (la gestion du texte est chiante, la recopie d'objet aussi, faire des liens se passe presque toujours bien, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dia
Posté par totof2000 . Évalué à 2.
Dans le genre anti-ergonomique, ya pas pire. Non seulement les shapes par défaut sont minables (on trouve jamais ce dont on a besoin), mais en plus de ça c'est une galère immonde pour ajuter les siennes. La gestin des connections est immonde. Pour tout dire je préfère encore l'éditeur de schéma de LibreOffice, xfig ou directement Inkskape : t'as pas grand chose en formes de base, mais tu sais ce que tu as et tu fais avec.
[^] # Re: Dia
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
On est sur linux.**fr** !
[^] # Re: Dia
Posté par totof2000 . Évalué à 3.
T'as pas mis la correxion ..;)
# " et je sais pas si ça marche bien sous Linux"
Posté par Mme Michu-cide . Évalué à 1.
Questionnement étrange, déjà, pour une appli web mais en plus pour quelqu'un qui poste sur Linuxfr et qui n'utiliserait pas l'OS en question.
[^] # Re: " et je sais pas si ça marche bien sous Linux"
Posté par Zenitram (site web personnel) . Évalué à 0.
Tu devrais regarder le nombre de dépêches/journaux n'ayant rien à voir avec le noyau Linux. Tu risques de prendre peur.
Questionnement étrange pour quelqu'un qui poste sur Linuxfr de penser qu'il faut obligatoirement avoir un OS précis pour s’intéresser aux 99% du site qui ne parle pas de Linux et/ou ne pas imaginer que certains peuvent avoir l'OS en question sur leur serveur et pas sur leur poste de travail.
[^] # Re: " et je sais pas si ça marche bien sous Linux"
Posté par Mme Michu-cide . Évalué à 2.
Cela étant, ça n'invalide pas complètement ma remarque et puis son je sais pas si ça marche bien sous Linux fait montre d'un certains préjugé* envers l'OS manchot alors que dans le cas d'une webapp** il n'y avait même pas à se poser la question.
Ce n'était pas une attaque personnelle.
*malgré lui ou non, issu peut-être d'un échec passé genre il y a >5ans. :)
** qui n'utiliserait pas de plugins proprio
[^] # Re: " et je sais pas si ça marche bien sous Linux"
Posté par Philippe F (site web personnel) . Évalué à 2.
Je connais pas la pile technologique utilisée par l'appli. Il m'a pas semblé voir de flash, mais il peut y avoir tellement de raisons pour qu'une appli ne marche pas sous Linux… Surtout une appli réactive comme ça, je peux imaginer qu'elle ailler cherche le max de perf du navigateur et qui dit max de perf dit risque d'incomaptibilité…
Par contre elle marche sous FreeBSD, mais je suis toujours pas "on-topics" sur LinuxFR. Ah zut alors… Bon en fait je déconne, j'ai aucune idée si ça marche sous BSD.
# Commentaire bookmark...
Posté par case42 (site web personnel) . Évalué à 6.
Je suis plutôt personnellement pro-client-leger plutôt que client lourd, mais je poste cet article (en anglais) qui va dans l'autre sens, parce qu'il pointe du doigt les problèmes que nous rencontrons / que nous allons continuer a rencontrer avec les clients légers, en tous cas sur le mobile : http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
[^] # Re: Commentaire bookmark...
Posté par zebul0n (site web personnel) . Évalué à 1.
Ce post se concentre principalement sur javascript, c'est un élément important des webapps modernes, mais c'est souvent la gestion et l'interaction avec DOM qui donne une impression de lenteur ou de saccades des appli webs.
Aussi en terme d'animation, il vaut mieux utiliser CSS avec accélération graphique que le JS, c'est flagrant sur les mobiles.
# le pasclient, c'est encore mieux!
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Pour faire mes diagrammes, j'ai juste besoin d'un éditeur de texte et d'un programme comme http://graphviz.org/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le pasclient, c'est encore mieux!
Posté par téthis . Évalué à 4.
Mais… mais c'est tout con pour faire le diagramme d'une FSM ! Pourquoi n'en as-tu pas parlé avant ?!!
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: le pasclient, c'est encore mieux!
Posté par Dr BG . Évalué à 3.
Car leFSM met tout en œuvre pour qu'on ne le découvre pas.
[^] # Re: le pasclient, c'est encore mieux!
Posté par téthis . Évalué à 4. Dernière modification le 18 juillet 2013 à 18:49.
Une FSM, c'est parfois un plat de spaghetti avec plus de boulettes de viande.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: le pasclient, c'est encore mieux!
Posté par Thomas Douillard . Évalué à 5.
Tout le monde connait. Non ?
[^] # Re: le pasclient, c'est encore mieux!
Posté par Sekigo . Évalué à 6.
Ah ah ah. J'utilise ce truc, c'est génial.
Le seul défaut, c'est que tu es tenté de toujours pousser ton truc plus loin et d'ajouter des tonnes de trucs plus "joli" et qui te semble plus lisible. Et au bout de 3 heures, tu as oublié pourquoi tu faisais ça, et tu te rend compte que c'est en fait beaucoup moins lisible que la première version torché en 10 minutes.
[^] # Re: le pasclient, c'est encore mieux!
Posté par zul (site web personnel) . Évalué à 1.
Sinon, si on veut des trucs un peu plus chiadé, il y'a tikz http://www.texample.net/tikz/examples/, mais ça ne rentre pas dans le cahier des charges (i.e. il y'a une courbe d'apprentissage assez importante).
Sinon, personne n'a évoqué inkscape (http://inkscape.org/), ce n'est pas son but premier, mais il peut faire ce genre de chose assez bien, d'après mon expérience.
Perso, je n'ai pas été impressionné par la réactivité de la chose, je trouve ça un peu laggy encore, même sur une machine relativement puissante.
[^] # Re: le pasclient, c'est encore mieux!
Posté par jben . Évalué à 2.
En parlant de TikZ et de graphviz dans le même thread, il y a dot2tex qui permet de génerer du code LaTeX utilisant PGF/TikZ à partir du résultat de graphviz. C'est tout simplement génial.
[^] # Re: le pasclient, c'est encore mieux!
Posté par fravashyo . Évalué à 4.
bref, c'est propriétaire, ça n'exporte pas en svg (mais en png, pdf, "visio"), et surtout ça ne fonctionne pas hors ligne, je ne vois vraiment pas en quoi c'est une victoire.
La démo sur https://www.draw.io/ est plus intéressante, au moins c'est libre, ça utilise nativement des formats ouverts (svg) et ça peut sans doute s'utiliser en local, donc hors connexion.
Je ne comprends pas pourquoi on parle de "client lourd" dans ce journal, un client comme son nom l'indique se connecte sur un serveur. Ici lucidchart est effectivement un client, qu'on peut voir léger (si on fait abstraction de la lourdeur de l'interface et des nagscreens qui forcent à s'enregistrer), et ça s'oppose simplement à un logiciel installé librement sur le poste de l'utilisateur, tel inkscape, qui lui n'est absolument pas un client lourd.
Et franchement, si c'est pour un petit diagramme, Inkscape va très bien et permettra d'obtenir la même chose avec son système de connecteurs (on peut ensuire remodifier la taille et la forme des connecteurs si on le souhaite). Dia est prévu pour cela également.
Pour un diagramme plus complexe, autant utiliser un outil comme graphviz.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: le pasclient, c'est encore mieux!
Posté par Philippe F (site web personnel) . Évalué à 3.
C'est une victoire car l'appli est plus performante et mieux foutue que tous les clients lourds que j'ai utilisé pour ce type de besoin. Alors même qu'il est bien plus difficile de faire cela en client léger ou client web dans ce cas.
client lourd, client léger sont des expressions classique pour distinguer des architectures logiciel, tout comme les expressions "client-serveur" ou "peer-to-peer".
En fait, je dis que j'ai un besoin précis que Lucidchart remplit et que je n'ai jamais trouvé d'autre logiciels pour le faire et tu me dis en essence que je suis trop con, je ne comprends pas mon besoin, Inkscape et Dia le remplissent très bien. Et bien non, une application c'est plus qu'une liste de check box devant des fonctionnalités. As-tu lu ce que je dis sur l'ergonomie, le temps de prise en main, la qualité du rendu, la disponibilités de formes prêtes adaptées à mon besoin ?
Sinon, xfig faisait déjà ça il y a 15 ans, et je l'utilisais déjà. Je suis vraiment trop con de pas continuer vraiment… D'ailleurs, je vois pas pourquoi des débiles développent Dia et Inkscape, xfig fait déjà tous ce qu'ils prétendent faire, et ce depuis bien longtemps.
[^] # Re: le pasclient, c'est encore mieux!
Posté par fravashyo . Évalué à 2.
Pour moi mon besoin c'est de pouvoir avoir accès à mes fichiers tout le temps (donc aussi hors connexion) et dans un format ouvert.
Donc en ce qui me concerne c'est plutôt le logiciel libre qui reste gagnant.
Et client lourd c'est toujours employé dans une notion de client-serveur : https://fr.wikipedia.org/wiki/Client_lourd
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: le pasclient, c'est encore mieux!
Posté par barmic . Évalué à 2.
Bien sûr toi tu connais les besoins des autres qu'ils ne les connaissent eux-même c'est ça ?
Les connecteurs avec inkscapes sont pourris. Il est vraiment très loin de Dia pour faire des diagrammes.
Dia (que j'utilise souvent) a une ergonomie exécrable comme je l'ai dis plus haut.
graphviz c'est pas trop mal pour les développeurs mais quand le diagramme deviens un peu grand ou que tu veux vraiment pouvoir faire tout et n'importe quoi tu passe plus de temps à faire du "debug" technique qu'à organiser tes idées. Pareil pour tikz (que j'aime beaucoup malgrès ça).
Mais oui tu as raison, faut pas être malin pour utiliser autre chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le pasclient, c'est encore mieux!
Posté par fravashyo . Évalué à 0.
je m'en moque de ce que les autres utilisent (sauf s'ils commencent à me demander de retravailler leurs diagrammes avec leurs logiciels dont je ne veux pas), c'est juste que je trouve un peu exagéré de venir tirer des conclusions définitives (« les appli web non librse sont gagnantes vis à vis des logiciels installés ») sur un cas particulier, qui de plus me semble peu pratique par rapport à mon utilisation.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: le pasclient, c'est encore mieux!
Posté par barmic . Évalué à 5.
Je crois que c'est plutôt toi qui est entrain de lire entre les lignes. Il décris ses usages et il dit qu'avec surprise, il découvre que des applications web peuvent être réactives et ergonomiques (le fait que l'exemple en question soit propriétaire n'est qu'un détail dans cette constatation à moins que tu n'estime que seule des applications propriétaires puissent être réactives et ergonomiques lorsque qu'elles sont web).
C'est toi qui imagine qu'il fait des généralités.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Avantages des technos web
Posté par tanguy_k (site web personnel) . Évalué à 5.
Standardisation
L'un des avantages des technos web est qu'elles sont standardisees.
Le developpement web devient similaire au developpement natif
Pendant longtemps (et encore aujourd'hui), la partie presentation (HTML, CSS) etait generee cote serveur.
Depuis, avec Backbone.js, AngularJS… on genere la partie presentation directement dans le navigateur web grace a JavaScript.
Le navigateur web devient donc une API du meme niveau que Qt, GTK+…
Les futurs web components (et Polymer de Google) s'inscrivent directement dans cette optique.
Dynamisme de la communaute et innovations
La communaute JS, HTML, CSS est beaucoup plus grosse et dynamique que Qt ou GTK+. Elle a aussi gagne en competences : on est bien loin de l'epoque de PHP3 et des devs qui ne savaient pas ce qu'etait un object. Le changement a eu lieu a mon avis quand Rails est sortie : des gens tres competents ont emerges.
(Les devs PHP3 d'il y a 10 ans existent toujours : ils font du Drupal maintenant
^_^)Du coup beaucoup d'innovations sortent pour ces technos la.
Pattern MVC cote client (navigateur) et serveur : un vrai, un beau, un qui fonctionne vraiment.
Tests automatisees (test unitaires, BDD) a tous les etages : j'ai toujours eu du mal a tester mes developpements Qt. Maintenant avec AngularJS il est possible de tout tester : c'est prevu pour des le depart et ca marche vraiment !
NodeJS, NoSQL, JSON, Bower, les promises, les fontes icones… toutes ces innovations tournent autour du web alors que le dev desktop semble sclérosé.
Il suffit de jeter un oeil sur GitHub pour comprendre l'ampleur du mouvement.
Multiplateforme
HTML, CSS, JS sont par definition multiplateforme. Avec le responsive design il est possible de couvrir les PCs jusqu'aux smartphones avec un seul code base.
Temps de developpement
Developper en Qt est un delice. Les technos web ne sont pas encore assez mures pour permettre de developper aussi vite qu'en Qt en obtenant un code aussi simple.
Le futur
Le gros point noir reste JS : Dart vs TypeScript vs ECMAScript 6 ?
Quoi qu'il en soit les technos web vont a mon avis bouffer le developpement desktop que l'on connait a l'heure actuelle, ca va peut etre prendre 10 ans mais c'est le sens de l'histoire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.