Quand je développe une application web, le truc le plus chiant pour moi c'est de développer l'interface utilisateur.
- Perdre du temps à re-développer des widgets graphique qui existe depuis des années lumières dans n'importe quel bibliothèque graphique de n'importe quel OS…
- Voir que mon client en Javascript sera toujours plus lent que mon appli native.
- Voir que c'est pas forcément plus compliqué de faire une application native.
- Voir que Google admet que Javascript ça tient pas la route pour les applications complexes. La preuve ils développent Dart, pourquoi d'ailleurs réinventer un nième langage de programmation ? Pourquoi ne pas mettre du Python ou du Ruby dans le navigateur ?
- De voir que je n'ai plus de limite imposée par un navigateur pour développer une appli.
- Voir que le développement web mobile (ou pas) est encore plus fragmenté que le marché des devices Android, bonjour les tests et le support client.
- Voir que c'est plus simple de monétiser mon appli native que mon appli web.
- Voir que les gens n'hésitent pas à acheter une appli native sur un AppStore.
Moi, l'OS de Mozilla j'y crois pas une seconde. ChromeOS, à mon avis ça va faire un flop total. Développer des petits jeux à la con avec du HTML5/JS dans un canvas pourquoi pas, pour le reste bof bof…
Le web ouvert je suis pour, mais à la base c'est pour diffuser du contenu pas pour développer des applications.
Finalement les vieux barbus avaient raisons, c'était mieux avant. Une appli simple qui fait une seule chose mais bien.
Donc moi je vais développer des applications natives maintenant, c'est cool j'apprends plein de trucs.
Bref, c'était ma vie, vous pouvez reprendre une activité normale.
# ahahah copain
Posté par fredix . Évalué à 10.
Putain soit tu es vraiment un trolleur pro soit tu vis dans ma tête …. Je fais le pari que le bon sens commence à refaire surface :)
Codez du natif les gars !!!! ET pour les webeux qui pensent que le compilé c'est dur, quand en on chie comme vous avec PHP/HTML/JS/CSS backend/frontend, Qt c'est juste facile à côté. Tu as ton langage C++ ta lib Qt et c'est tout, le monde est à toi sans limite technique de merde. Tu peux développer une app qui va révolutionner le monde façon kazaa/bitcoin/skype/utorrent… (je cite exprès des apps natives qui exploitent judicieusement les capacités d'Internet).
[^] # Re: ahahah copain
Posté par Niniryoku . Évalué à 3.
J'ai lu quelque part (si quelqu'un a un lien ce serai bien) qu'il y a une idée de « B2B » (je sais plus si c'est le nom exact) pour « Browser to Browser » où on pourrait se connecter en websocket (TCP over HTTP quoi) à un autre navigateur en javascript.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: ahahah copain
Posté par BFG . Évalué à 4.
Sachant que WebSockets ne permet pas de faire serveur, c'est impossible.
[^] # Re: ahahah copain
Posté par Ludo . Évalué à 1.
tu confonds avec WebRTC.
[^] # Re: ahahah copain
Posté par rogo . Évalué à 1.
A ma connaissance, il n'existe qu'une implémentation de ce Browser-to-Browser : Opera Unite. Grosso modo, c'est un serveur web léger embarqué dans le navigateur web, pour une diffusion au cas par cas.
[^] # Re: ahahah copain
Posté par trolleurPro . Évalué à 8.
Je ne vis pas dans ta tête :)
Mais à un moment donné, quand tu prends du recul sur ce que tu fais, tu te dis "Mais putain pourquoi je me fait chier à faire ce truc là alors que ça jamais été prévu pour…"
[^] # Re: ahahah copain
Posté par fredix . Évalué à 8.
Welcome. Mais faut pas le dire trop fort, chez Mozilla ils se pensent à la pointe :p
[^] # Re: ahahah copain
Posté par _seb_ . Évalué à 4.
Et ton QML, basé sur javascript avec un peu de CSS et xHTML.
Et ton Qt Script basé lui aussi sur javascript.
Et ton C++ et l'extension C++ Qt (Qt's meta-object system).
Et ton Qt Lighthouse backends.
Et ton QT Mobility
Et ton Qt Embedded
Les technologies web ont, certes, des défauts mais aussi beaucoup d'attraits et c'est peut être pour cela qu'elles ont remplacé un grand nombre d'applications natives.
[^] # Re: ahahah copain
Posté par silex . Évalué à 4.
Je te rejoins totalement à un détail prêt. Faire passer des habitués des langages web au C++ c'est que tu veux les tuer. Gestion de la mémoire manuelle, langage très verbeux - faire une classe en C++ c'est une déclaration + une implémentation c'est vraiment chiant je trouve car t'as 200 lignes de code alors que t'as encore quasiment rien fait à part le minimum - et aussi assez complexe. Puis les erreurs de compilations en C++ sont juste illisible.
Bon perso je préfère souvent le C au C++ mais le souci reste le même.
Sans parler de la porta…
Je conseillerais à ceux qui veulent un peu sortir du web de commencer par du ruby ou du python, je dirais plus python car c'est moins exotique que l'esprit ruby, c'est portable et ça reste du langage de script !
Sinon en langage compilé franchement du Java ou C#, ce genre de langage haut niveau pas trop compliqués à comprendre et où l'IDE est bien pratique :P Perso j'aime ni l'un ni l'autre, mais bon dnftt.
A titre perso je me sens ultra limité quand je fais du dev web. Je me sens bloqué dans se foutu navigateur, sans l'accès à plein de fonctionnalités de la machine, c'est une horreur puis il y a le souci d'affichage entre navigateurs.
Bref j'ai l'impression que faire du dev web c'est pas vraiment programmer. Sans mépris pour les dev' web, juste qu'en tant que passionné le dev web est trop limité en possibilités pour que je m'amuse.
# Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Niniryoku . Évalué à 9. Dernière modification le 28 mars 2012 à 22:12.
Ça fait du bien de lire quelqu'un qui ne dis pas de la merde et qui a tout compris à la vie. J'en ai marre de cette mode du tout web.
Cependant voilà ce qu'on me répond, quand je dis ça, et je fait appel à vous pour savoir que rétorquer :
Pour déployer massivement une application Qt sous Linux c'est facile. On publie un paquet sur un dépôt perso, et roulez. Mais quelqu'un a des retour d'expérience de déploiement massif d'application sur des postes Windows ?
Typiquement une application web, sur un Firefox sous Windows et un Firefox sous Linux sera la même. Essaie de développer une appli Windows/Linux en Java, C++ avec Qt ou en Python, je pense qu'on commence à complexifier. (Après c'est la même galère pour une appli web multi navigateur)
Typiquement, un mec qui a lu le site du zéro et fait du code de merde, on arrive à l'embaucher à 1200 € par mois 1300. Un mec qui fait du Python, C++/Qt ça coute tout de suite beaucoup plus cher.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Niniryoku . Évalué à 10.
J'ai oublié l'argument foireux aussi :
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Zenitram (site web personnel) . Évalué à 6.
Tu peux faire une appli native qui utilise HTTP. C'est pas un problème (tu crois que Skype fait comment pour passer en entreprise?)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Guillaume Knispel . Évalué à 6.
donc on fait du DPI
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Donc ils utilisent https.
Donc ils font du MiM avec des faux certificat.
Donc ils donc vérifient autrement les certificats, quitte à les définir en dure.
Donc ils installent des vrai faux certificats payés au créateur des certificats en question.
Donc…
"La première sécurité est la liberté"
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par windu.2b . Évalué à 4.
Ouais, mais la gestion du multi-navigateur est (au moins) aussi chiante que la gestion du multi-OS !
Et encore, ça va mieux depuis qu'IE6 disparaît enfin et que des bibliothèques comme jQuery permettent de masquer (en partie seulement, c'est bien là le pb) les
bugscomportements foireuxspécificités des navigateurs.[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par BFG . Évalué à 4.
Mon expérience est loin du "massif", mais je pense que ce n'est pas plus difficile à déployer que n'importe quelle autre application Windows. Pareil pour MacOSX. Skype utilise Qt, et pour autant que je sache, il n'y a pas de problèmes de déploiement liés à Qt lui-même.
La seule chose que je pourrais reprocher est qu'il y a un poids de bibliothèques à inclure, mais on est tout de même très loin des mastodontes comme Java ou .NET : Qt pèse une vingtaine de Mo sur Windows, bibliothèques 32bits ET 64bits, cependant les 32bits suffisent. Qt est divisé en modules, et l'on n'inclut pas ceux qu'on n'utilise pas. Sur MacOSX, c'est un peu plus gros. Si la taille est vraiment importante, on peut encore diminuer.
Oui, et des gens compétents en Web, qui savent faire du code robuste et des architectures solides, coutent cher également.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Guillaume Knispel . Évalué à 2.
java et .net sont globaux aux machines même windows
(je suis en train de me demander en live si de ce point de vue c'est du coup pas radicalement mieux que de compiler en natif sous windows…)
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par BFG . Évalué à 2.
Si .net est bien installé par défaut sur Windows, Java ne l'est pas, lui.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Guillaume Knispel . Évalué à 2.
Oui mais quand tu installes une VM java sous windows, en général tu n'en n'installe pas une par programme, ni une pour dix programme, mais bien une seule pour tout le système, éventuellement deux si t'es un dingue.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par trolleurPro . Évalué à 6.
Pour un contexte d'entreprise :
Déployer une application dans un environnement full Microsoft, les sysadmins Windows peuvent le faire facilement avec un *.msi et des GPO.
On peut aussi le faire au moment de l'installation de l'OS dans un master (tu installes le même Windows avec les mêmes applis sur tous tes postes).
Avec Windows 8, tu as un Store. Et pour les entreprises je pensent qu'elles pourront choisir les applications disponibles sur le store des postes de travail.
Pour Mac OS, il y a un "programme développeur" destiné à publier des apps internes sur tes devices.
Pour la question des salaires, ça n'a rien à voir. Si tu veux faire un truc qui tient la route dans tous les cas il faut des gens compétents. Il vaut mieux embaucher quelques personnes passionnées ultra-compétentes et bien payés plutôt que 50 pisseurs de code sous payés qui seront jamais motivés un peu comme les SSII (ah zut c'est un autre troll ça :).
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 4. Dernière modification le 28 mars 2012 à 22:58.
C'était un argument en faveur du web, sauf que Windows 8 va enfin intégrer un store, donc ça va balayer définitivement cette histoire.
Je te met au défi de développer une application complexe en web aussi facilement qu'en Qt. Simplement le web n'a pas été conçu pour donc au final tu es obligé d'empiler une multitudes de langages, frameworks, libs js pour s'approcher d'une vraie app. Actuellement la mode dans le web est à apprendre des langages qui vont générer du JS (http://coffeescript.org/) et du CSS (http://sass-lang.com/)…
Pour faire court, en natif tu peux développer une app du genre spotify ou dropbox. Pour info ces 2 apps mettent une grosse claque dans la figure de leurs concurrents web. Ils ont rapidement obtenu l'adhésion de plusieurs millions d'utilisateurs dont quelques millions qui payent le service. Pourquoi ? Parce qu'une app native est une vrai app qui s'intègre au desktop de l'utilisateur, qui n'a aucune limite technique et qui exploite à fond les capacités de l'OS et du matériel. Ils ont ainsi développé un protocole en P2P… Ils peuvent imaginer tout ce qui leur passe par la tête, le coder et le déployer.
Alors tout ça, ça vaut bien le vrai salaire d'une équipe d'ingé.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Sufflope (site web personnel) . Évalué à -7.
Ah ouais parce qu'avant y avait pas d'outils pour gérer un parc Windows ???
Tu feras gaffe, de ton côté t'as succombé à la mode d'utiliser un langage qui va générer du code machine… Je pense que ton PC n'est défitivement pas fait pour faire tourner des applis en Qt ; passe à l'assembleur. Que dis-je, au binaire.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 4.
Heu ton outil Windows il peut mettre à jour une app sur des millions de machines ? Tu confonds outil de gestion d'un réseau interne et un store qui permet de mettre à jour des postes clients à travers le monde … un apt-get quoi.
C'est bien beau d'essayer de troller salement, mais bon C++ est un langage standard et normé, coffeescript et sass ce sont des palliatifs pour simplifier le dev web tellement JS et CSS sont merdique. Mais bon tu sais pas de quoi tu parles.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Sufflope (site web personnel) . Évalué à -9.
Hahaha.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Sufflope (site web personnel) . Évalué à -9.
J'ajouterai : pense à cliquer sur le lien « page perso » avant de donner un jugement péremptoire sur le fait que je puisse avoir un avis (très orienté certes, m'enfin c'est pas caché) sur le sujet. Bouffon.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Laurent Cligny (site web personnel) . Évalué à 10.
Alors pourquoi as-tu arrêté le dev de ton site vers les années 90 ?
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Paul . Évalué à 3.
J'ai cliqué sur le lien page perso, et je suis désolé mais je vois pas en quoi tu connais :
De ce que je vois, tu as développé des applications qui sont web par essence, mais essaie de faire un LIMS en Qt et un autre en web, à mon avis tu sera d'accord avec fredix.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Sufflope (site web personnel) . Évalué à -5.
Donc mon avis sur le web n'a aucun intérêt. OK.
Donc je résume les arguments :
Ayé j'ai compris !! Y a les mauvais frameworks, ils voient un langage, ils l'abstraient. Et les bons frameworks, ils voient un langage… ils l'abstraient. Mais c'est des bons frameworks.
Derrière j'avoue que je réagis un peu brutalement parce que quand un kéké gominé posant avec ses lunettes de soleil Gucci m'explique SUR LE WEB que LE WEB ÇA PUE j'ai un peu l'impression de voir un mec qui sort des chiottes et se paint que j'empeste alors qu'il s'est torché avec les mains.
Ça va, quand vous postez sur DLFP, vous vous faites pas trop mal ? Faites gaffe, nono participe même à ParisJS. Je propose de le moinsser aussi.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 8.
Si linuxfr était un newsgroup perso je préfèrerais. Sinon les attaques personnelles tu pourrais t'en passer tu t'enfonces là.
[^] # Re: Monsieur, Bravo, je fais donc appelàvos conseil
Posté par Juke (site web personnel) . Évalué à 5.
linuxfr était disponible via NNTP.
[^] # Re: Monsieur, Bravo, je fais donc appelàvos conseil
Posté par Juke (site web personnel) . Évalué à 7.
Non car nous postons via weboob.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par CrEv (site web personnel) . Évalué à 3.
Dites, ça vous irait de vous calmer un peu là ?
Mouai…
EcmaScript est normé, oui. Javascript non. Javascript, jscript, actionscript, etc sont des implémentations d'ecmascript qui lui est normé. Pour faire un parallèle, ça voudrait dire qu'il n'y a pas de différence entre GCC et le compilo de MS car C++ est normé.
Essai d'argumenter un peu quand même, et un peu plus calmement, car là…
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Mal, très mal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Troy McClure (site web personnel) . Évalué à 4.
peux-tu preciser ce qui est si mal spécifié dans la norme du c++ ?
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
J'ai oublié le mot "implémenté". Ce n'est pas aussi dramatique que pour SQL, mais C++ est plus un langage transportable que portable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Niniryoku . Évalué à 10.
Ah mais je suis totalement d'accord avec toi. Un bon programmeur qui est plus productif et fait du meilleur code doit être largement plus payé que le vieux gars qui fait du PHP dans une fosse septique.
Le problème c'est que tu crois que les SSII regardent la qualité du code et disent « ouais, ça vaux le prix d'un ingé » ?
Nan, leur but, c'est de faire payer un projet au prix maximum, de rendre le client le plus dépendant possible (pour ça le web c'est pas mal parceque les données sont sur le serveur de la SSII), et payer au minimum la viande qu'on a utilisé pour le projet.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par trolleurPro . Évalué à 5.
C'est pour ça que les grosses SSII sont de la merde en boite. Quand les clients des SSII et le monde corporate chercheront à travailler efficacement…
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par mansuetus (site web personnel) . Évalué à 6.
Et la marmotte…
Efficacement, quand on est piloté par les coûts "court terme", c'est minimiser le coût de développement.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par dave . Évalué à 3.
En génie logiciel, on nous apprends qu'une application codée avec les pieds pourra coûter peu cher au départ mais voir ses coûts exploser sur le long terme à cause de la maintenance.
Donc, je ne suis pas sûr que ce soit rentable, ni pour la SSII, ni pour le client.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par shbrol . Évalué à 10.
Si la rentabilité long terme avait la moindre importance, ca se saurait…
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 6.
On s'en fou des SSII, ceux qui innovent qui font des produits de dingue ce sont les éditeurs, pas les SSII. Après le problème en France on a une culture SSII, donc si on veut bouffer il faut suivre la demande.
Mais perso j'ai la prétention de croire que les techos peuvent créer leur propre produit et même créer leur boite, c'est un "peu" ce qu'il se passe aux US (google, ebay, facebook, yahoo, etc etc) et ça marche un "peu".
[^] # Re: Monsieur, Bravo, je fais donc appelàvos conseil
Posté par Juke (site web personnel) . Évalué à 10.
Le jeudi 29 mars 2012 à 11:09 +0200, fredix a écrit :
> (google, ebay, facebook, yahoo, etc etc)
qui font du web quoi ;)
[^] # Re: Monsieur, Bravo, je fais donc appelàvos conseil
Posté par fredix . Évalué à 7. Dernière modification le 29 mars 2012 à 14:26.
Ahahah bien vu :) J'aurai du dire Apple, dropbox, spotify, skype .. et des petits comme sparrow qui ont décollé comme une fusée grâce à un client natif pour Mac avant celui pour iPhone. Et Sublime Text2 qui cartonne sur Mac, il suffit de tester pour comprendre pourquoi.
La question à se poser est pourquoi ca marche sur Apple et pas sur Windows où les apps sont piratés à mort. Sur Mac l'écosystème est simple, on clic sur un bouton pour acheter dans le store, hop ca download hop c'est installé, hop ca marche sans merde de spyware/malware/virus.
C'est exactement les mêmes arguments que l'on donne aux ayants droits contre le piratage : développez des plateformes légales, Hadopi est inutile et nocive.
Sauf que pour les logiciels Apple l'a fait. Sous Windows il n'y a pas encore de store pour simplifier l'achat, l'installation et les mises à jour. Sous Linux on a tout sauf la culture d'acheter (du proprio) et l'environnement de dev est chaotique…
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Jean . Évalué à 3.
Je pense que tu connais déjà ma position sur le sujet, rien ne vaut une bonne appli native intégrée correctement à mon espace de travail :)
Par contre, de part mon expérience (appli développée et installée sur un parc de milliers de machines aux versions d'OS variées) la vraie difficulté n'est pas le déploiement de l'appli mais le fait de réussir à la faire fonctionner au sein d'un environnement que l'on ne maîtrise pas. On peut commencer par citer les différentes versions de l'OS, 32 ou 64 bits, les versions installées ou non de Services Packs sous windows, les versions de libs sur la machine linux, les règles de sécurités au niveau de l'OS, les logiciels tiers qui peuvent parfois poser aussi problème… (d'ailleurs je pense que tu expérimente ce soucis avec les maj de ton client spotify).
Quand on a passé des heures de galère sur ce genre de problèmes, le jour où l'on doit coder une appli web tout parrait simple… malheureusement.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 5.
yop jean :)
Je conçois bien que le natif ne soit pas simple, cependant dropbox est justement parvenu à éviter plein de soucis en téléchargeant l'ensemble des libs et binaire nécessaire à dropbox dans le ~/.dropbox-inst/
Coder une app web ca parait simple de prime abord, les soucis arrivent quand les features s'allongent et qu'on demande au dev web de faire une app qui reprenne les codes du desktop et ses possibilités. Il y a un moment où c'est plus possible et là un concurrent arrive avec du natif et te met une claque dans la figure. Le succès d'Apple se fait grâce à des app natives, en face le GoogleOS dans chrome il est juste mort né, sauf à mettre en avant nativeclient, ce qui revient à faire du natif ….
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Jean . Évalué à 4.
Tout à fait d'accord, le problème aujourd'hui c'est qu'au lieu de choisir la techno en fonction des besoins, on choisi d'abord la techno web parce-que-cest-la-mode puis c'est aux besoins de s'adapter… ou pas… :D
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fredix . Évalué à 2.
Sauf que le succès phénoménal d'Apple avec un écosystème natif remet les pendules à l'heure et Microsoft, comme toujours suiveur, ce sent obligé de créer un app store. Or les stores sur Mac et Windows vont faire comme sur iPhone, ca va pousser les apps natives. La branlette des apps web ne devrait pas durer longtemps pour le bien de tout le monde :)
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
"Une application web est beaucoup plus facile à déployer massivement"
Pas forcément, et tu peux aussi virtualiser le poste de travail
"Une application web est multiOS (j'ai pas dis multi-navigateur)"
Pas toujours et c'est le problème, j'ai parcouru des DATs ou l'OS du client
est imposé et son navigateur génial (hors IE6 tourne pas sous Linux, ni IE9 sous XP d'ailleurs).
Pour beaucoup de décideurs, le navigateur fait partie du "socle" des outils
du poste client.
"Les développeurs d'appli web sont moins cher."
Ca se discute aussi, et ça ne devrait pas être le critère de toute façon.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Krunch (site web personnel) . Évalué à 10.
Surtout une application web est beaucoup plus facile a mettre à jour. Tu contrôles tout l'environnement. Tandis que le code qui tourne chez les clients tu ne peux pas tous les mettre à jour en même temps et il y a toujours des corners cases qui vont pas bien marcher mais que tu ne pourras pas corriger sans passer des heures à intéragir avec les clients concernés.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par weonbin . Évalué à 9.
Pour réconcilier les deux il y a les applets java, même si c'est un peu passé de mode.
- C'est facile à déployer (chargement via une page web)
- C'est multiOS sans se casser trop la tête (on y perd moins de cheveux qu'avec les incompatibilités des navigateurs)
- Il y a des tonnes de librairies et c'est pas limité par le framework du navigateur (pas de hacks pour implémenter une fonctionnalité au dessus d'un truc qui a pas été prévu pour)
- Ca a des performances comparables à une appli native
- Ca permet de développer des applis complexes (typage statique, API cohérente, Gestion des Threads, …)
Pour les désavantages
- Ca tourne pas sur android / iOS
- Ca met plus de temps à charger qu'une page web au premier démarrage de la JVM (encore que quand on voit certains sites c'est même pas sur …)
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Mieux que les applets, tu as java web start qui ne demande même pas un browser pour lancer une application.
De toute façon, rien ne tourne sous android/ios. Il faut presque toujours faire un développement spécifique, même en web…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par fog . Évalué à -6.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par claudex . Évalué à 4.
Sauf que tu ne maîtrise pas toujours ce qu'il y a sur les postes clients ce qui risque d’interagir avec ton application. Alors, c'est souvent la faute du client mais tu vas quand même perdre du temps à corriger ces bugs et le client va perdre du temps pour avoir son appli.
Quand on dis que le navigateur devient un OS, distribuer une appli web revient à déployer sur une vm clean pour chaque appli. Mois aussi je préfère développer une appli pas web mais je comprend ce choix qui diminue les coût et augmente la satisfaction du client (mais pas forcément celle de l'utilisateur).
« 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: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Philippe F (site web personnel) . Évalué à 6.
Euh, je suis surpris que Zenitram n'aie pas déjà sauté sur l'occasion mais je vais le faire à sa place.
A ma connaissance, c'est exactement l'inverse: déployer une application sur Windows est facile, il suffit de faire un installeur et il y a pas mal d'outil pour en faire des biens. Il est aussi assez facile d'embarquer toutes les libs dont tu as besoin.
Sous linux au contraire, tu te trouves confronté à plein de questions à la con:
- quel format d'empaquetage utilisé ?
- comment m'assurer que toutes les libs dont j'ai besoin sont présentes dans la version où j'en ai besoin, pour le 86 distribitions Linux et 23 versions de chacune de ces distributions
- pour sauvegarder les données de l'utilisateur, il faut bidouiller pour créer un répertoire dans le HOME de l'utilisateur mais tu es obligé de développer vachement de code "à la con" pour gérer plein de cas particuliers.
Au final, tu passes en temps monstrueux en support pour quelques barbus.
Et maintenant, quid de Mac OS ? Je me pose la même question, facilité de déploiement…
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Moonz . Évalué à 4.
C’est pas du déploiement ça, le déploiement c’est « je veux mettre mon soft sur 200 machines ». Tu vas faire clic-clic 200 fois, avec ton installeur ?
J’ose espérer que tu n’as pas installé 86 distributions dans 23 versions différentes sur ton parc de machines. Si c’est le cas, le déploiement d’une application est, je le crains, le dernier de tes soucis.
Pareil, dans un contexte où on parle de « déploiement », ton HOME c’est un NFS/Samba que tu peux gérer de manière centralisée pour tous les utilisateurs.
Pareil que Linux, grosso-modo. Les logiciels sont distribués en .pkg, qui est juste une grosse archive qui contient binaire, lib partagées et données.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Philippe F (site web personnel) . Évalué à 4.
On parle pas de la même chose.
Tu te places du point de vue de l'administrateur système qui se pose la question de déployer un programme sur ses postes. Programme qui apparemment répondrait déjà à pas mal de critère de déploiement automatisé.
Il me semble que l'auteur initial pose un problème différent, à savoir, du point de vue développeur, quelle est la bonne approche pour distribuer son programme face à la diversité des plate-formes. Le but étant de garder un programme simple à déployer et simple à mettre à jour pour les utilisateurs.
Donc je maintiens ma réponse, sous Windows, il est assez facile pour le développeur de générer un installeur, qui aura des propriétés d'installation automatisée (entre autres) et qui supportera un panel très large de versions de Windows.
Sous Linux, le problème est plus complexe. Tu as la solution de fainéant de fournir un .tgz avec un configure (ou un make install ou encore un python setup.py install)mais c'est loin d'être user-friendly.
Ensuite, solution 2, tu fournis un package. Le vrai truc de distrib. Sauf que qui dit package dit :
- choix dans le format: rpm ou deb ? Et ArchLinux ils vont se brosser ? Et gentoo ?
- choix dans la version de la distribution: pour une distribution donnée, il y a en général plusieurs versions utilisées par les utilisateurs à un moment donné. Laquelle choisir ?
Donc pour la problématique "comment faire un programme qui est facile à installer sur toutes les versions des OS que je vise" se résoud avec un installeur (et un peu d'huile de coude) sous Windows, et se résoud avec une armée entière de packageur sous Linux. Armée que peu de gens possèdent.
Et encore, je parle pas des bugs "sous Mageia 8.3.7 , ton soft plante en plein milieu d'un truc" qui te demandent donc d'avoir une Mageia 8.3.7 pour tester tout ça. Ouch…
# Et pour les outils collaboratifs ?
Posté par tanguy_k (site web personnel) . Évalué à 2.
Tout ce qui est dit est vrai. Mais pour les outils collaboratifs ou une appli web est AMHA bien mieux.
Deezer, Dropbox ect… en appli native ok. Mais GitHub en natif ? trop complique a mon avis. Et des outils collaboratifs il y en a un paquet :)
[^] # Re: Et pour les outils collaboratifs ?
Posté par Maclag . Évalué à 10.
Non, non, et non!
Pour les outils collaboratifs, je préfère largement un vrai tableur avec des cases qui se remplissent toutes seules parce que le collaborateur s'est branché dessus qu'un tableur à la ramasse qui fait ramer mon octo-coeur 4GHz parce que "la partie collaborative était plus simple à faire sur le web".
Et je ne vois pas en quoi Github ne pourrait pas être une appli native aussi. Les explorateurs de fichiers ont bien des vues à travers les réseaux transparentes. Qu'est-ce qui vous manque?
[^] # Re: Et pour les outils collaboratifs ?
Posté par CrEv (site web personnel) . Évalué à 7.
Ha ok, genre http://mac.github.com/
Ha mince, c'est natif.
(et en passant j'aimerais bien que ce soit dispo sous les autres OS, tout comme le client twitter pour mac)
D'ailleurs, de plus en plus j'utilise http://www.sourcetreeapp.com/ (oui je sais, pas libre pour un sous, pas multiplateforme pour un sous) pour accéder à mes dépots git et hg lorsque je suis sur un mac. Et c'est plutôt agréable.
Donc oui, github ou autre en natif ça peut être pertinent.
# même longueur d'onde
Posté par jay . Évalué à 5.
Une idée pour continuer à développer des sites internet sans se faire autant chier, ce serait peut-être de réaliser le backend en application native basé sur des services web.
L'accès à la base de données, contrôler les requêtes utilisateurs etc, ce n'est pas déplaisant à coder en php. Mais dès qu'il faut générer du html/js qui doit faire office de widgets graphique on se fait chier et on perd un temps fou.
Moi personnellement, je ne fait plus de site internet pour les autres. Je développe seulement des projets personnel où personne ne vient me dire qu'il faut rajouter telle où telle feature kikoolol qui va prendre 10x trop de temps à coder. Mais même comme ça je trouve cela trop long à développer.
Je compte faire pareil en C++/Qt peut-être en vala ? Weboob est une très bonne idée.0 Je pense qu'on va vers un tournant de l'utilisation du web après moulte framework et langages qui n'arriveront jamais à résoudre la cause du problème : utilisation non prévue du html document != application.
[^] # Re: même longueur d'onde
Posté par Toufou (site web personnel) . Évalué à 1.
tu oublies l'autre aspect qui est http != ip qui est tout aussi important. Le service web, ça va bien dans une appli avec une communication requête client / réponse serveur, mais ça devient n'importe quoi dans une appli où il y a des interactions plus complexes entre le serveur et le client. Mais c'est vrai que l'argument de vente c'est que ça passe les firewall donc que c'est BIEN (tm).
# Le beurre et l'argent du beurre
Posté par snt . Évalué à 6.
http://qt-project.org/wiki/Qt_for_Google_Native_Client
Qt dans un navigateur. Facile a développer, facile à déployer.
Elle est pas belle la vie ?
[^] # Re: Le beurre et l'argent du beurre
Posté par weonbin . Évalué à 2.
Facile à déployer non vu que c'est basé sur Google Native Client. (Il faut que le navigateur le supporte ce qui n'est pas donné)
[^] # Re: Le beurre et l'argent du beurre
Posté par Niniryoku . Évalué à 2.
C'est plus facile de demander aux admins : « Déployez moi Chrome sur tout les postes » plutot que « Déployez moi mon appli Qt ».
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Le beurre et l'argent du beurre
Posté par zebra3 . Évalué à 3.
En quoi ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le beurre et l'argent du beurre
Posté par Guillaume Knispel . Évalué à 5.
La prononciation de "Chrome" par un français est moins variée que celle de "QT", l'admin a donc plus de chance de comprendre.
[^] # Re: Le beurre et l'argent du beurre
Posté par zebra3 . Évalué à 1.
Euh pas sûr. Qt, à part « Kuté » et « Cute », je vois pas trop d'autres façon de prononcer. Et pour Chrome c'est pareil, j'en vois que deux : « Crome » et « chrome » (avec le ch comme dans « cheval »). Donc deux partout :-)
Éventuellement, la difficulté pour l'admin de déployer Qt est qu'il pourrait confondre avec QuickTime, mais en lui précisant bien la différence au début il devrait comprendre.
En tout cas, je vois pas en quoi Qt serait plus compliqué à déployer que Chrome. Et au moins, Qt ne se met pas à jour tout seul, ça simplifie la gestion du parc.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Prend un thé, ça ira mieux...
Posté par jigso . Évalué à 10.
Sencha propose une lib javascript ExtJS qui te permet de développer une appli graphique "à l'ancienne", cad en construisant ton application exactement comme si tu utilisais un framework de GUI classique : Panel, Window, Toolbar, Button, DataGrid, Charts, etc.
Rajoute à ça tout un ensemble de classes pour faire la connexion avec le serveur (ajax), un design pattern Observer pour gérer l'asynchronisme et la communication entre les widgets, etc.
Bref, on en revient donc à un vrai modèle Client/Serveur propre, cad que le serveur ne sert qu'à filer les données au client, il ne s'occupe pas de "construire" l'interface et de gérer la session graphique, toute la couche d'affichage et de présentation se passe dans le navigateur.
Jette un coup d'oeil aux exemples : http://www.sencha.com/products/extjs/examples/
En particulier le Feed viewer, avec un debugguer pour voir les échanges avec le serveur (par ex Firebug). Tout le code de l'application est chargée en une fois (~10 javascripts), puis le flux rss est demandé au serveur lorsque on sélectionne une entrée. Ce flux est renvoyé "brut", cad que c'est le javascript qui en fait l'analyse et l'affichage. Si on change la position du la fenêtre du message, ou des tailles de colonnes, il n'y a pas d'échange avec le serveur, les données sont chargées, et c'est juste le layout graphique qui change et qui prend en charge le rafraîchissement de l'affichage.
J'utilise ce framework dans le cadre de mon boulot et franchement c'est un plaisir : les composants sont de très haut niveau, il y a très peu de fonctionnalités que je n'ai pas trouvé déjà faites, et les quelques modifs que j'ai eu à faire ont été très simples à mettre en oeuvre : de base le code est disponible et bien commenté, et en plus le framework est vraiment fait pour être étendu.
Il existe une version pour mobile, Sencha Touch ; je ne l'ai pas utilisé, mais le peu que j'en ai vu me laisse à penser que c'est du même tonneau qu'ExtJS.
[^] # Re: Prend un thé, ça ira mieux...
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
J'ai une petite question: en quoi est-ce différent de Jquery UI ? Est-ce qu'il y a un IDE avec Sencha ?
[^] # Re: Prend un thé, ça ira mieux...
Posté par jigso . Évalué à 4.
J'ai regardé un peu rapidement Jquery UI, oui c'est différent . ExtJS va beaucoup plus loin. Tout d'abord il y a beaucoup plus de widget dans ExtJS, notamment des datagrids, ainsi que des composants de mise en page ( http://dev.sencha.com/deploy/ext-4.0.0/examples/layout-browser/layout-browser.html ). Ensuite ExtJS propose une modèle d'architecture pour faire une application web MVC ; JQuery UI reste plus comme une bibliothèque de widget qui permettent d'enrichir une page web, mais c'est à toi d'imaginer tout ce qui va autour (chargement des fichiers, structure du HTML, échanges Ajax avec le serveur). De ce point de vu ExtJS est plus complet car il offre en plus des composants de gestion de l'interface (layout), des composants abstraits de gestions des données (Stores, proxy,…)
Il y a un tutoriel qui explique tout l'architecture d'une application ExtJS : http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/
Le gros avantage est que pour développer une application web on a un cadre qui permet de structurer proprement son code. Si on part bille en tête avec juste HTML et Javascript, c'est comme vouloir coder une interface complète avec juste C et les bonnes vielles apis Win32 : c'est faisable, mais sans rigueur et expérience le premier jet est souvent catastrophique.
Pour le web on est dans la même situation : essaye de refaire un Google Doc like avec juste HTML et Javascript, Ouch… Et une lib pour faire des jolis boutons, ça aide, mais ça ne structure pas l'architecture de ton code.
Sinon il existe un designer graphique pour construire rapidement les interfaces http://www.sencha.com/products/designer/ mais il est payant.
[^] # Re: Prend un thé, ça ira mieux...
Posté par jigso . Évalué à 7.
Ah oui, autre gros point intéressant : les Stores d'ExtJS sont des classes qui se chargent d'envoyer les requêtes Ajax, de récupérer les données, et de mettre tout ça en mémoire dans des Collections (tableaux ou hash) à disposition des composant graphiques, par ex un tableau. Sans rentrer dans les détails, les Stores poussent naturellement à faire des appels REST (en promouvant les GET/POST/PUT/DELETE sur des apis style /object/id).
Bref, en développant avec ExtJS, on obtient naturellement des web services REST, qu'on peut alors réutiliser indépendamment de ExtJS pour d'autre type de client (lourd/natif/ HTML+javascript sans ExtJS,…)
À comparer avec le développement d'une interface web classique, par ex un serveur qui construit une page HTML par produit. Si on veut un WS pour l'interfacer avec autre chose, faut tout refaire…
[^] # Re: Prend un thé, ça ira mieux...
Posté par Raoul Volfoni (site web personnel) . Évalué à 1. Dernière modification le 29 mars 2012 à 21:37.
Merci beaucoup pour toutes ces infos, tu m'as donné pas mal de grain à moudre. ;)
NB: je débute à peine en jQuery…
# Ne pas juger sur la valeur mais sur l'opportunité
Posté par Nicolas Froidure (site web personnel) . Évalué à 7.
Je suis principalement développeur web et je commence tout juste à m'intéresser au développement sous GNU/Linux. Je ne suis donc pas à même de juger la valeur de l'un par rapport à l'autre.
Tout ce que je peux vous dire, c'est qu'il est plus sage de mesurer l'opportunité que représente chaque plateforme. Sur ce point, je considère que le web est le plus prometteur.
En effet, grâce à la plateforme qu'est le web, on peut vendre un programme en cycle court. Pas d'installation, pas de mises à jour, pas de données stockées sur le poste client.
De même, pour les entreprises, c'est une véritable opportunité. Certes le Javascript et les langages interprétés utilisés pour le web sont plus long que le code compilé, mais le cycle de développement est plus simple. Grâce à cela, je vends aux entreprises des logiciels faits pour eux uniquement et pour le prix d'une intégration d'un CRM en code compilé type SAGE ou CEGID dont 80% des fonctionnalités ne leur sont pas utiles, les 20% restant étant inutilement complexes.
Le web répond à tous ces marchés pour lesquels il ne serait ni viable, ni raisonnable de faire une application en code natif.
Enfin, il reste toujours possible d'utiliser du code natif côté serveur, qu'est-ce qu'apache, mysql etc… sinon des executables ? N'oublions pas le rôle principal du Javascript : l'interface utilisateur et la gestion des e/s de l'ihm. Pour cela, javascript est suffisant, les applications utilisant XUL/Js en témoignent parfaitement.
while(coding) alert('smile');
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par fredix . Évalué à 6.
Le faux problème du natif, c'est qu'on a tendance à croire que c'est un binaire isolé du réseau comme dans les années 80-90.
Or dans le monde réel actuel, des apps native comme spotify, dropbox, itunes, skype, etc etc, utilisent Internet pour stocker et accéder aux données. Certaines embarquent même webkit pour simplifier l'affichage de certaines informations (spotify,itunes). Et non faire une app web ou intégrer webkit dans une app native ça n'a rien à voir. Dans le 2ème cas on a la puissance du natif, et on exploite le web à sa juste valeur pour afficher de la data.
L'avenir est pour moi clairement vers le natif qui utilise le web via des API REST pour l'accès aux données, et webkit embarqué pour la présentation de certaines données . Cela n'empêche en rien de faire également un client web simplifié, dropbox le fait très bien pour permettre de consulter ses fichiers et modifier son compte. Twitter le fait également, l'interface web dépanne, mais les user addict utilisent des clients natifs….
Mais pour comprendre ceci il faut avoir déjà codé en natif, rare sont les dev web qui l'ont fait.. les autres vivent dans leur tête, pendant ce temps Apple fait des milliards avec un écosystème natif sur iphone, et la même chose va se produire sur les Mac et Windows.
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Nicolas Froidure (site web personnel) . Évalué à 2. Dernière modification le 29 mars 2012 à 12:11.
Les utilisateurs sont tous très différents. Certes les geeks utilisent plutôt des applications natives quand ils ont le choix, mais je pense que l'utilisateur lambda n'a souvent pas le recul nécessaire pour préférer l'un ou l'autre. Il juge plutôt les applications sur le court terme et il faut bien dire que sur ce point, les applications web sont plutôt gagnantes.
Un exemple, les clients mails. J'utilise Thunderbird car je veux maîtriser mes données et les recherches sont infiniment plus rapides. Mais la plupart des non-geeks que je connais utilisent les applications web comme GMail, Hotmail et YahooMail. Certes, c'est moins rapide, mais c'est surtout moins compliqué. Installer un logiciel desktop signifie attendre son téléchargement, répondre à des questions pas rassurantes de l'OS/browser pour exécuter l'installateur et configurer le logiciel (sur ce point des efforts sont faits comme pour thunderbird, mais dans les cas un peu différents, c'est encore plus complexe). A cela s'ajoute le fait qu'il fait encore aller chercher le logiciel dans le menu de l'OS alors que sur Google, c'est si simple de taper ce qu'on veut et de l'obtenir.
Les exemples que tu donnes sont valables aussi, mais il s'agit d'applications natives dans un environnement maîtrisé (AppStores) ou d'applications très grand public qui répondent aux besoins génériques quotidiens de millions (milliards ?) d'utilisateurs. Pourtant, comme tu le dis, ces applications ont leur équivalent sur le web, et je parie que nombreux sont ceux qui les utilisent.
Finalement, la question qu'il faut se poser est peut-être cela là : un service peut-il se passer d'une application web ?
while(coding) alert('smile');
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par fredix . Évalué à 3. Dernière modification le 29 mars 2012 à 12:33.
L'idée n'est pas de dire qu'il faut arrêter les apps web. Je pense qu'il faut changer de paradigme lorsqu'on veut développer un outil, et ne plus foncer tête baissé vers son PHP/MySQL/jQuery… Je pense qu'il faudra d'abord penser service web et développer une API. Ensuite travailler de concert sur des clients natifs et une interface web. Décorréler complètement le backend des frontends me parait plus pérenne pour l'avenir d'un produit (proprio, ou libre), car la vraie question au final c'est qu'est-ce que préfère l'utilisateur qui paye ? Celui qui paye pas il s'en fou de tout, de toute manière c'est lui le produit.
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Nicolas Froidure (site web personnel) . Évalué à 1.
Je te rejoins à 100% sur ce point, mes applications web sont basées sur des services RESTful (d'ailleurs, j'envisage sérieusement d'ouvrir son code) car même si je n'ai pas créé d'app native, je me réserve la possibilité de le faire un jour. Et puis, je n'exclue pas de faire des apps android, j'ai déjà un peu tâté le terrain : https://github.com/nfroidure/SimpleRestAndroidClient
Je suis d'accord, le client est roi. Cependant, il n'est pas dieu et ne peut pas obtenir pour le budget qu'il a souvent une application native personnalisée. Et même dans les cas où il a ce budget, c'est toujours mieux de commencer par une appli web pour tester rapidement un concept sans problématique d'installation, compilation etc…
Je ne vais pas faire l'expérience, mais j'imagine que demander un devis pour une application cliente web et son équivalent en natif devrait mettre en évidence cette différence de complexité par un écart de prix important.
while(coding) alert('smile');
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par fredix . Évalué à 1.
Par client je pensais plus à l'utilisateur qui paye son app quelques euros sur l'app store. Propose ton app en web uniquement et regarde s'il est prêt à payer de la même manière …. Une app web ne donne pas aussi envie qu'une native réactive, sexy, qui exploite toutes les features de l'OS et du matériel. Quand tu payes un smartphone 600€ l'utilisateur est en droit d'avoir des applications qui exploite à fond les possibilités du truc, et pas des sous merdes en HTML fut-elles en HTML5.
Et c'est la même chose sur le desktop, sauf qu'avant les stores c'était plus compliqué pour acheter du natif. Au final le client, grand public, pousse le marché vers le natif, et ça c'est une bonne chose.
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Anonyme . Évalué à 1.
Tu parles d'utilisateurs qui maîtrisent déjà un peu mais pas assez pour faire un choix éclairé. Mais de ce que je vois le plus souvent, quand je suis de corvée de dépannage, la grande majorité n'en est même pas à ce niveau. Ils utilisent le webmail parce qu'ils ne connaissent que ça. Certains vont même jusqu'à penser que le mot de passe du FAI est universel ! Ils ne lisent absolument rien — ce n'est pas une pieuse exagération de ma part — et donc ne progressent pas.
Tellement vrai qu'il faut placer systématiquement l'icône des logiciels principaux sur le bureau sinon ils ne savent pas qu'ils existent.
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Toufou (site web personnel) . Évalué à 1.
Le client mail c'est pas non plus un ERP hein :) Et encore moins un outil de CAO. Mais bon prenons le client mail.
90% des Windows grand publics sont installés avec un client mail. Pas de téléchargement, pas d'installation juste a répondre à quelques questions de config qui en effet ne sont pas posées quand tu vas sur un webmail… Uniquement parce que le webmail est lié au fournisseur de l'email. Tu as la même complexité si tu veux que ton webmail aille pomper les mails ailleurs que chez son hébergeur (pour peu que ce soit autorisé).
Si MS avait créé un compte MSN / hotmail et préconfiguré outlook express pour y accèder, je pense que Madame Michu appellerait un mail un "MSN".
Sous mobile, je suis curieux de connaître la proportion de gens qui utilisent un client webmail au lieu d'une appli native. Comme dit au dessous, Madame Michu utilise ce qu'on lui propose par défaut. Fut une époque c'était Outlook express, maintenant c'est OrangeMail ou GMail.
Ca dépend du point de vue. Ta question, d'un point de vue marketting est sans doute bonne : tu proposes une possibilité avant même l'expression du besoin (donc tu peux vendre quelque chose même si c'est inutile).
D'un point de vue purement technique, il me semble complètement délirant de proposer des solutions avant d'avoir un besoin exprimé. La question serait plutôt : sous quelle forme un service répond-il mieux à mon besoin ?
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Toufou (site web personnel) . Évalué à 1.
En quelle manière ? Parce que le déploiement sur les postes clients est "instantané" ? A part ça, je ne vois pas en quoi les technos web simplifient le cycle de développement.
Rien à voir avec la techno employée : tu compares un produit boite qui ne correspond pas à leurs besoins et une application sur mesure. Tu vendrais ces mêmes softs sur mesure en natif tu aurais les mêmes conclusions : 80% des fonctionnalités des mastodontes sont inutiles au client, les 20% restant resteraient trop compliqués et ton appli sur mesure correspondrait mieux à leurs besoins.
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Nicolas Froidure (site web personnel) . Évalué à 2.
J'ai parlé un peu vite, je ne connais pas le cycle de développement complet d'une application native. Mais j'imagine que le prix est différent (cf mon commentaire plus haut) si l'on veut une application multi-plateformes en code natif comme le sont les applications clientes HTML5. Rien que pour le mobile, en iOS et Android, c'est au moins deux langages de programmation différents.
while(coding) alert('smile');
[^] # Re: Ne pas juger sur la valeur mais sur l'opportunité
Posté par Toufou (site web personnel) . Évalué à 1.
Le multiplateforme c'est de toutes façons la misère.
En web comme en n'importe quoi on impose la plateforme sinon on ne s'en sort pas.
Actuellement sur le web, si tu n'as pas :
- un navigateur récent (essaye d'aller sur le net avec un Moz 1.0 et rigole :) )
- un navigateur acceptant les cookies ET javascript
- un navigateur en mode graphique (et oui, y'en a en mode texte et c'est bien pratique dans certains cas)
Tu n'as pas accès a 90% des sites web disponibles sur le net. Pourtant la techno a été faite pour supporter tout ça.
En natif c'est pareil : pour limiter les couts on limite les plateformes supportées.
Quand au mobile… Une appli (web ou non) destinée à un ordi classique rendra mal sur un écran timbre poste avec un pipo clavier, il te faudra généralement la revoir pour l'adapter aux possibilités de la machine (à minima l'IHM, mais bon c'est quand même la grosse partie d'une appli exécutable sous mobile). Alors à moins que tu ne développes ton appli web que pour les mobiles, tu n'échapperas pas à un développement.
Bref, je ne pense pas qu'un mec qui développe une appli pour un Windows, une distro linux ou pour une VM Java ou .NET (oui je met ça dans le natif : c'est natif à la VM ,) ) ait un surcout par rapport à ce que tu rencontres en Web. A mon avis il a même moins de maintenance sur l'existant qu'une application web un peu chiadée, vu la faible durée de vie des multiples versions des navigateurs / framework / libs utilisées dans le monde du web.
# hum...
Posté par CrEv (site web personnel) . Évalué à 10.
Trois choses :
Vu certains mastodontes c'est pas toujours le cas. Quand on voit que le moindre soft qui ne fait rien prend 50 ou 100Mo et se traine comme une loutre mal léchée on se dit que le js c'est performant
Faut voir, ça dépend beaucoup du langage utilisé. Et le javascript est plutôt agréable lorsqu'on le connait (ha mince, comme quasiment tous les langages en fait…) 1 partout
Quelle preuve ? Ce qu'ils prouvent c'est que, par design, javascript ne peut pas être optimisé comme ils le voudraient alors qu'un langage proche mais dont l'objectif est d'être plus rapide est réalisable.
Comme si c'était pas exactement la même chose du côté natif… D, Scala, vala, Go, rust, etc Tout le monde crée toujours un nouveau langage, c'est comme les standards finalement…
De voir que je n'ai plus de limite imposée par les problématiques multiplateformes et de déploiement pour développer une appli
Oui, c'est vrai, avec du windows XP, vista, 7, bientôt 8, mac 10.6, 10.7, je ne sais pas combien de linux différents avec des versions totalement diverses (si on prend une debian stable, une redhat supportée, une ou plusieurs ubuntu, arch, …). Bonjour les tests et le support client.
Voir que c'est plus simple de pirater mon appli native et donc de ne rien toucher dessus plutôt que mon appli web avec abonnement
Voir que les gens n'hésitent pas à payer un abonnement à un site
Bon, sous cette critique je pense simplement que les deux mondes sont intéressant, pas toujours pour les mêmes besoins. On est arrivé à un stade où on veut tout faire en web, puis finalement non (les applis natives sur mobile par exemple). Il faut surtout trouver un bon équilibre, mais aucun des deux mondes n'est meilleur que l'autre. C'est juste différent.
Mais surtout, il ne faut pas chercher de fausses raisons pour développer l'un ou l'autre.
[^] # Re: hum...
Posté par Christophe Discours (site web personnel) . Évalué à 6.
4. année lumière est une unité de distance, pas de temps
[^] # Re: hum...
Posté par dave . Évalué à 2.
Bah si tu es relativiste le temps et la distance c'est pareil. (même dimension c=1) Mais bon
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: hum...
Posté par Babelouest (site web personnel) . Évalué à 3.
Si t'es relativiste, tu es en train de sabrer le champagne parce que les suisses ont mal branché le GPS, t'as pas le temps d'expliquer à des linuxiens l'introduction que t'as eu lors de ton premier cours de physique à la fac (et que tu savais déjà parce que tu étais abonné à Science & vie Junior au lycée)
Si t'es étudiant en relativisme, quand on te dit que "le temps et la distance c'est pareil", tu réponds "ca dépend"…
[^] # Re: hum...
Posté par dave . Évalué à 1.
C'était juste parce que je voulais « sodomiser une drosophile » comme dirait nos amis des animaux. :D
Sinon, l'année lumière est bien une unité de distance :D. D'ailleurs saviez vous qu'un photon n'avait pas conscience du temps qui passe ? ie dans son référentiel, le temps est immobile. Intéressant n'est-ce pas ?
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: hum...
Posté par fredix . Évalué à 1.
C'est bizarre si j'installe dropbox natif et que je ne paye plus mon abo ca marche plus … tu peux avoir un abo avec du natif, ca n'a rien à voir avec une histoire de frontend web/natif.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 3.
Non, car là tu ne parle pas d'un logiciel mais d'un service.
Ce que tu paye ce n'est pas la licence d'utilisation de dropbox natif, c'est le service dropbox hébergé.
Et que ton client soit natif ou non ne change en effet rien, car ce n'est pas lui que tu paye.
[^] # Re: hum...
Posté par fredix . Évalué à 5.
C'est toi qui parle d'un abonnement, or un abonnement ça correspond à un service que tu payes.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 1.
Oui mais non.
Si on me coupe mon abonnement à GMail (imaginons) alors je n'ai plus accès au logiciel webmail gmail.
Mais ça tu peux plus difficilement le faire avec du natif.
Après, que le logiciel soit diffusé ou non (donc que tu y accède par navigateur ou non) c'est un autre problème que service vs application
[^] # Re: hum...
Posté par fredix . Évalué à 3.
Si on te coupe ton abonnement Gmail tu n'auras plus non plus accès à l'IMAP Gmail via thunderbird …
[^] # Re: hum...
Posté par BFG . Évalué à 3.
Mais certains messages seront stockés hors-ligne et l'on pourra encore y accéder et effectuer des recherches. Ça ne couterait rien au fournisseur de service, mais je suppose que certains voudraient empêcher cela.
[^] # Re: hum...
Posté par fredix . Évalué à 2.
Et donc ? Si tu ne paye plus l'abo dropbox 50Go/mois ca ne supprime pas tes données en local.
[^] # Re: hum...
Posté par BFG . Évalué à 2.
Ça ne me pose aucun problème, de même que pouvoir effectuer des recherches locales avec l'application GMail native (on est dans l'hypothétique) dont j'ai cessé de payer l'abonnement.
Mais si j'ai bien compris, certains voudraient que je ne puisse même plus faire de recherches locales quand je cesse de payer l'abonnement, peut-être même voudraient-ils garder les données Dropbox en otage tant que je ne paye plus (ne jamais les avoir en local permettrait cela).
J'espère sincèrement que j'exagère leur propos et que ce n'est pas réellement ce qu'ils pensent. Je préfèrerais encore qu'ils se contentent de penser au cas des logiciels sans service, sans abonnement, où l'on achète une licence d'utilisation, et qu'ils se plaignent, tel Hollywood, que quelqu'un visionne leur film/utilise leur logiciel sans être préalablement passé à la caisse.
[^] # Re: hum...
Posté par fredix . Évalué à 1.
Je ne vois pas de quoi tu parles, le modèle de dropbox c'est la synchronisation pas l'accès à un disque réseau comme HubiC.
Ca c'est le modèle de 1990, où aucune app n'utilisait le réseau, sauf le mail et le web … Si les services proprio te font peur tu es libre d'en utiliser des libres (apinc.org, owncloud.com, identi.ca, teambox.com, …)
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 2.
Oui et ?
Ce ne changera donc rien sur ton thunderbird, lui tu l'aura
Encore une fois, j'ai l'impression qu'il y a confusion.
Lorsqu'on coupe ton abonnement à gmail on te supprime deux choses :
Mais c'est deux choses distinctes bien quelles soient packagées ensemble (et encore, tu n'es pas obligé d'activer l'imap)
[^] # Re: hum...
Posté par fredix . Évalué à 3.
Oui il y a confusion. Tu ne veux pas comprendre que le natif peut être un moyen d'accéder à un service, et que le client natif sans le service n'a plus de valeur dans un modèle à la dropbox/spotify.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 2.
Donc au final natif ou non ça ne change rien si tu parles de service.
Si ce que tu vends est un service (un service de mail, un service de musique, un service fichiers, etc) que ton client soit natif ou non ne change donc strictement rien, y compris pour la partie monétisation puisque ce que tu vends c'est ton service.
Ce qui était au final l'objet du message (oué j'ai l'impression qu'on s'en est un peu échappé, moi y compris)
[^] # Re: hum...
Posté par fredix . Évalué à 2.
Justement on reste complètement dans le sujet qui dit que le natif est ce qu'il y a de mieux pour l'utilisateur et même pour le dev. A service identique, dropbox et spotify ont éclaté leurs concurrents full web et qui étaient avant eux….
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 2.
Heu non, enfin si. Tu le dis mais ne prouve absolument rien. Ni pour l'utilisateur, ni pour le dev.
Sauf que tu n'as pas montré en quoi c'est leurs clients natifs qui le permettent (enfin pour spotify, il est évident et normal que dropbox a besoin d'un client natif, un dropbox sans client natif ce n'est pas le même service)
[^] # Re: hum...
Posté par fredix . Évalué à 2. Dernière modification le 30 mars 2012 à 13:00.
Moi je n'ai rien à prouver on est pas dans un tribunal. Ce que je dis l'auteur du journal le dit aussi, ainsi que d'autres sur cette page. Tu es libre de penser le contraire, je m'en fou total.
Quant au natif pour dropbox, il est nécessaire sinon ca ne serait pas le même service, c'est la palisse …. Et ca confirme que le natif permet un "peu" 3 tonnes de feature que ne pourra jamais faire le web car il n'est juste pas fait pour.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 3.
Ha ben si tu préfère on peut aussi arrêter de discuter. Moi qui pensais que ça pouvais être une discussion intéressante. Enfin si on sort un peu du "moi je pense" sans argumenter.
Mais bon…
mouai…
Prenons un autre cas alors.
Si je colle toutes mes données sur des services d'hébergement. Et que j'unifie ces services. Je peux alors avoir des interfaces de consultation, modification, etc de mes données. Elles deviennent synchronisée de fait (ce que ne peux faire dropbox) et je ne fait que les représenter et non accéder directement à la donnée brut (qui n'a que très peu d'intérêt dans la plupart des cas).
Dans ce cas, je n'ai juste absolument pas besoin d'une application native.
Je pourrait en avoir une, mais ce serait ridicule et lourd. Toutes les machines d'aujourd'hui on un navigateur, je n'ai besoin de rien d'autre que me connecter à mon service de données.
Si c'est du natif, faut que je télécharge et installe mon client lourd. Et là c'est le drame. Je ne peux plus le faire chez un pote, au taff, c'est lourd sur mes multiples ordis, etc.
Donc non, au final ça ne confirme que le fait que dans certains usages c'est mieux, et dans d'autres c'est moins bien.
Donc ce n'est pas dans le sens du journal qui tente de faire croire que le web say rien que de la merde et que ça sert à rien.
[^] # Re: hum...
Posté par fredix . Évalué à 3.
Des arguments ont été jeté à la pelle dans ce journal et dans l'autre.
Moi mon sens est de dire qu'une application est par définition est plus agréable à faire en natif pour le dev et plus agréable à utiliser pour le user. Étant dev web puis dev natif je parle de mon expérience personnelle. Côté user je constate le succès phénoménal de apps native dans le monde Apple.
Cependant, je conçois que le web à son intérêt, déjà pour tester un service rapidement, ou pour dépanner si on a pas accès à ses propres terminaux. L'exemple de Twitter est parlant.
Ensuite il y aura toujours des dev qui ne voudront faire que du web, et des users qui sont content du web et seront heureux avec un chromebook ou un jolicloud.
Cependant je perçois que les desktop Mac et Windows vont suivre le modèle des smartphones où les applications natives exploitent fortement Internet, via des services et cloud, proprio. Par exemple, lorsque j'ai connecté ma tablette Android sur mon compte Gmail, elle a téléchargé toutes les app que j'avais déjà installé sur mon smartphone.
Le natif qui exploite les capacités d'Internet, c'est mixer la puissance du natif avec la facilité du web, il n'y a rien d'étonnant donc à ce que ca marche, même si certains pour caricaturer ce succès focalisent sur des apps qui font des pets…
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 3.
Ha ben désolé, un journal posté par trolleurpro à -32 je suis pas allé le voir…
Ha tiens, j'ai un peu l'inverse en tête. J'ai commencé par tu natif, et surtout de la migration d'applis C++ natives en applis web. Et je préfère dans pas mal de cas faire du js, de l'html, du css que faire du C++ (par contre tu marques un très bon point pour QT, c'est quand même un des meilleurs framework existant…), du C# ou du java.
Mais qui rapportent vraiment pas mal (pour connaître le dev d'une des plus "connues" sur iphone ;-) )
Sur les apps natives, il ne faut pas oublier deux choses : le js débarque petit à petit, et pas qu'un peu, côté applications natives (scripting) ou serveur V8, nodejs, etc. Le gap entre ça et du dev client web devient de plus en plus limité.
Nombreuses technologies natives proviennent aussi du web, css notamment. C'est loin d'être négligeable.
Actuellement oui, sur iphone et android on a pas mal de natif. Mais je pense que ça va un peu s'estomper, car gérer n applications, toutes avec des langages différents c'est difficilement tenable. Alors que modifier un template ou un css pour passer d'un navigateur desktop vers un mobile c'est pas si compliqué. Et avec du "reponsive design" finalement c'est identique.
Et dans ce cas, côté dev c'est bien mieux.
[^] # Re: hum...
Posté par claudex . Évalué à 3.
Comme le web a des features en plus que le natif comme le fait d'y accéder depuis n'importe quel ordinateur disposant d'un navigateur.
« 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: hum...
Posté par fredix . Évalué à 2.
Oui et on revient à des arguments qui ont déjà été cités que tu vas galérer pour faire une app web complexe alors qu'en natif ca sera plus simple à faire et avec plus de features pour le user et une meilleur intégration.
Et on en revient aussi à dire qu'il ne s'agit pas de supprimer les apps web, elles ont parfois leur utilité, comme l'interface web de twitter qui dépanne, mais les user addict utilisent un client natif.
Et on en revient aussi à dire qu'il faudrait arréter de penser web monolithique dès qu'on veut faire une app, mais backend avec une API, qui permette de dev des clients natifs desktop, smartphone, ou web.
Bref, ca tourne en rond ce débat.
[^] # Re: hum...
Posté par claudex . Évalué à 4.
Tu prends un mauvais exemple, regarde Facebook, il n'y a pas besoin d'appli native pour que les gens y passent la journée.
« 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: hum...
Posté par fredix . Évalué à 2. Dernière modification le 30 mars 2012 à 13:55.
Faux. Sur les smartphones ils utilisent un client natif, pas la version mobile http://m.facebook.com
Et s'il y avait une app native pour le desktop, rien ne dit qu'elle ne serait pas moins utilisé que la version web, je crois même le contraire.
[^] # Re: hum...
Posté par claudex . Évalué à 2.
Source? J'ai vu des deux avec une majorité pour la version mobile.
Je ne crois pas car elle n'aurait sans doute aucun avantage sur la version web (contrairement à twitter que tu citais qui une inteface web très pauvre en fonctionnalité).
« 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: hum...
Posté par fredix . Évalué à 3.
Ahah si c'est pas de la mauvaise fois :) Il y a une app native pour iOS et Android, je ne vois personne utiliser un navigateur pour aller sur m.facebook.com
Bon j'ai fais le tour des trolls.
[^] # Re: hum...
Posté par dave . Évalué à 0.
Juste comme ça…
Finalement, on parle d'applications qui passent par le réseau, donc par TCP/IP. Facebook utilise HTTP, donc les applications dédiées sont probablement des interfaces pour le protocole HTTP.
Il y avait google qui voulait supprimer TCP/IP dernièrement, (ou HTTP, je ne sais plus) avec Guido van Rossum, je ne sais pas où ils en sont à l'heure actuelle.
En tous cas, il me semble que pour passer du client web au client natif (navigateur contre application native), c'est HTTP qui s'efface en général, car peu adapté, non ?
En fait, il me semble que c'est plus une question de protocole qu'autre chose, car je ne crois pas que les navigateurs soient autre chose que des purs utilisateurs de HTTP. La question est plutôt de savoir quand HTTP est utile ou non - non ?
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: hum...
Posté par fredix . Évalué à 3. Dernière modification le 30 mars 2012 à 23:32.
Pas forcément et je pense que dans la pratique c'est rarement le cas. Développer un client natif n'empêche en rien celui-ci de communiquer avec une API REST vers un serveur en HTTP ou via les ports 80/443 en priant dans ce cas qu'il n'y ait pas de DPI dans l'entreprise (si c'est pas du HTTP qui passe par les ports 80/443, pan la socket).
HTTP a l'intérêt de passer les firewalls, vu qu'en entreprise ou sur les réseaux GSM 3G, tout est souvent est filtré, même en sortie, sauf HTTP[S]. Une app native passe donc bien souvent par les ports 80 et 443, et elle utilise bien souvent des API REST vers leur serveur applicatif. Donc HTTP ne s'efface pas forcément avec un client natif, loin de là.
La question de HTTP est une autre problématique, étant un protocole stateless four tout, il est à mon avis moins intéressant que XMPP qui maintient une socket bidirectionnelle et permet automatiquement le renvoi de message en cas de coupure réseau. Cependant les websockets qui font partie des bricolages du Web pour s'approcher du desktop, arrivent à maintenir des sockets persistantes pour faire du push vers les navigateurs.
Certains pensent que c'était mieux avant quand chaque app native avait son propre protocole et port IANA dédié, exemple les newsgroup avec nntp (port 119). Le problème est qu'il n'est pas viable que chaque startup qui fasse une app de pets propose auprès de l'IETF un protocole standard de pet et fasse une demande auprès de l'IANA d'un port dédié…
Je vois donc HTTP comme une solution pratique pour ce genre d'app native ; et même le client Dropbox autorise dans ses préférences de passer par un proxy HTTP pour sortir.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 4.
Et on va te répondre exactement l'inverse car il y a bien des cas où faire une application web est plus simple, plus ergonomique, plus agréable pour l'utilisateur.
Sauf que cette critique n'a rien à voir avec web/natif. C'est exactement la même critique pour nombre d'applications avec un client natif pour lesquelles il est impossible d'attaquer proprement le serveur pour en faire une version smartphone ou web.
Le truc c'est que la plupart des arguments avancés pour le natif sont de fausses raisons.
Les arguments intéressant à débattre sont plutôt de l'ordre du multiplateforme vs multinavigateur, de la facilité de faire des interfaces sympa natif vs html, des problématiques déploiement vs application en ligne. Mais aussi la capacité d'intégrer un designer qui va te faire ton interface, facile en web, plus complexe en natif. etc. Mais c'est justement les points sur lesquelles ça ne tourne pas en rond, ça ne débat même pas en fait…
[^] # Re: hum...
Posté par fredix . Évalué à 2.
Oui il y a des cas, car ce n'est pas 0 ou 1. C'est un curseur qui fait que jusqu'à un certain point de complexité, une version web est intéressante pour le dev et le user, mais arrivé à un autre niveau de complexité une version native est plus agréable. Ca dépend de l'app il n'y a rien de généralisable.
J'en vois plus de fausses bonnes raisons pour le web depuis trop d'années, heureusement que des startups prouvent le contraire ainsi qu'Apple :)
Perso je suis satisfait de voir que d'autres font le même constat que moi, convaincre untel m'importe peu.
[^] # Re: hum...
Posté par thecat . Évalué à 5.
Et on va te répondre exactement l'inverse car il y a bien des cas où faire une application web est plus simple, plus ergonomique, plus agréable pour l'utilisateur.
Plus simple: Par expérience, je dirais "oui pour de petite applications" … mais dés que tu rajoute des fonctionnalités alors non, le dev web n'est vraiment pas le plus simple, tout bêtement car il ajoute un nombre très important de limitation.
plus ergonomique: Pareil: dés que tu sort de l'usage "texte/document simple" l'ergonomie tombe en flèche: l'exemple le plus terrible est l'ajout d'une image dans tous les documents "en lignes" (wiki, forums, éditeur texte …), impossible d'utiliser le copier-coller; tu est obligé de faire une première étape d'upload de l'image. Autres exemples: l'utilisation du systray, d'un icône bien reconnaissable dans la barre des taches, la possibilité de redimensionner et repositionner la fenêtre ou je le souhaite.
C'est ergonomique d'avoir toujours le menu de Firefox dans une application Mail ?
agréable pour l'utilisateur: C'est très relatif … De plus plein d'applications ne sont pas agréable du tout sur le web: les applications audio par exemple … de manière générale toute applications qui gère des documents de plus de quelques centaines de Ko.
Ce qui est agréable en revanche est d'avoir toujours accès à la même interface et cela plutôt facilement sur n'importe quel ordinateur.
Le truc c'est que la plupart des arguments avancés pour le natif sont de fausses raisons.
L'argument c'est que tous les OS ont proposés un grand nombres de services aux applications "native" des utilisateurs: presse-papier (riche), systray, gestion des fenêtres (et des bureaux), icône spécifique dans la barre des taches (et maintenant on peu même avoir une barre de progression en fond), stockage (fichiers ou mémoire), évènements ("Nouvelle clef USB connectée", imprimante disponible), connectivité (reseau, périphériques bluetouth) …
Franchement, vouloir réinventer tout ça dans un navigateur web, qui au départ n’était pas prévu pour cela, et en ayant en plus de gros boulet au pied comme l'obligation des technos HTTP/DOM/JS … ça ne te parait pas illusoire voir irréel ?
multiplateforme vs multinavigateur
Le vraie multiplateforme/multi-navigateur ça coute cher, aussi bien en natif qu'en applis web; Sortis des exemples triviaux je doute qu'une technos puisse prétendre être radicalement plus facile qu'une autre.
de la facilité de faire des interfaces sympa natif vs html
Idem, suivant les cas il est bien plus simple de faire une interface "sympa" en natif (je pense à la 3D par exemple). Par contre pour toute interface orienté "document" (simple formulaire plus ou moins complets -ca représente la majorité des interfaces je te l'accorde-) alors oui les technos "web" (HTML/CSS/DOM/JS) aident pas mal.
des problématiques déploiement vs application en ligne
Je ne parlerais pas vraiment de déploiement mais d’accès simplifié a un service: alors la oui une applis web est imbattable.
Mais aussi la capacité d'intégrer un designer qui va te faire ton interface, facile en web, plus complexe en natif
"Facile" en web ? Je dirait moins difficile à la rigueur … ou plutôt: les technos web font moins peur à un designer … mais de la à qualifier de "facile" …
Ton commentaire m'a fait réfléchir: quelle application je préfère utiliser sous forme "Web" et surtout, pour quelle raison.
Ma réponse personnelle est: je trouve que n'importe quelle application native est plus "performante" que sont équivalent web (au sens fluidité, ergonomie, facilité d'utilisation); par contre oui j'utilise des applis web car je jongle entres différents ordinateurs sur lesquels je peut ne pas avoir la possibilité (ou l'envie) d'installer une applis native.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 5.
Oué enfin pour du natif aussi, plus tu rajoutes de fonctionnalités plus c'est complexe.
Pour illustrer, lorsque je parle d'applications complexes en JS je parle quand même d'applications de 30 ou 40 000 lignes de code (lib non comprises). Et d'applications métiers d'ailleurs.
Hum, si je fais un client natif pour un service distant, faudra bien que j'upload aussi.
En html on peut aussi uploader des répertoires et faire du drag and drop maintenant. Donc l'écart se comble de plus en plus.
Non, pas forcément.
Qui a encore des clés usb ? Ca doit faire un an que j'en ai pas touché une. Les gens ont du dropbox maintenant (par exemple et pour le principe) du picasa, du facebook, etc.
De mon expérience, c'est quand même plus lourd de debugger du C++ sur différents linux et windows que du css dans plusieurs navigateurs. Après, en effet, ça dépend beaucoup des applications.
Si on ne parle pas de 3D (peu représenté dans les interfaces) les applications natives sont en général pas du tout agréables visuellement. Ca change petit à petit, d'ailleurs ça change en général en intégrant des technologies provenant du web (html, css).
Le truc c'est qu'en général tu va trouver un designer qui peut te pondre un html/css.
Ensuite l'intégration n'est pas forcément complexe.
De là à trouver un designer qui va me faire mon interface en QT, c'est quand même plus complexe. Et souvent l'étape de transposition vers le code est plus longue.
Je suis plutôt d'accord avec la conclusion, de manière globale. D'ailleurs cette conclusion est finalement de dire que les deux ont leurs avantages et inconvénients, et que pour un même service les deux clients (web et natif) sont complémentaires. Et non l'un qui soit meilleur que l'autre, l'un est juste meilleur que l'autre dans un scope, et inversement.
[^] # Re: hum...
Posté par thecat . Évalué à 5.
Oué enfin pour du natif aussi, plus tu rajoutes de fonctionnalités plus c'est complexe.
Je répondais à ton commentaire qui disait que "il y a bien des cas où faire une application web est plus simple" , et je persiste: pour de petites applications limités peut-êtres, mais trés vite les applications "natives" sont plus simples à développer (car tu as le choix des technos).
Hum, si je fais un client natif pour un service distant, faudra bien que j'upload aussi.
Cela n'a rien a voir, je parle d'un service fournis par l'OS (presse papier riche) que le navigateur va devoir réimplémenter …
L'upload n'est la que parce que le service est distant … (et note qu'une applis native peu uploader quand elle veut … à la fin, sur demande; alors qu'une applis web, juste pour insérer une image, il faut déja l'uploader …)
Qui a encore des clés usb ? Ca doit faire un an que j'en ai pas touché une. Les gens ont du dropbox maintenant (par exemple et pour le principe) du pic
Cela n'a rien a voir non plus … on ne parle pas du stockage des documents !
Je fait une grande distinction entres le service "web" et "l'applis web" …
Je n'ai jamais utilsé de clef usb pour mes mails ! je préfère une applis "native" pour mes mails.
Les photos sont un trés bon exemple: La consultation "simple" me va plutot bien via une interface web (note que le web était prévu pour cela …), mais pour leurs gestions (tag, tris et mème consultations intensives) je préfère une applis native.
De mon expérience, c'est quand même plus lourd de debugger du C++ sur différents linux et windows que du css dans plusieurs navigateurs.
Du C++ à la rigueur… mais du Java ?
Pense aussi que tu est tellement limité avec JS/CSS/Html que tu as énormément de garde fou ! Fait une applis native mono-threadé qui n'a accés à rien (pas de fichier, pas de presse papier, pas de fenètre …), a cela sera super simple à débugger.
les applications natives sont en général pas du tout agréables visuellement.
Honnètement, donne moi deux applis (une native et son équivalent en "web") et comparons leurs interface … je suis pas sûr de qui des deux est la plus agréable.
Le mail: Gmail ou Thunderbird ?
Les suite bureautique: Google document ou LibreOffice ou MSOffice? (note quand même la différence de focntionalitées entres elles)
Le chat/l'IM/le dessin/l'audio: Je n'ai encore jamais vue d'interface web correcte (et pareil, le nombre de fonctionalitées est incomparables entres la version native et web).
Le truc c'est qu'en général tu va trouver un designer qui peut te pondre un html/css.Ensuite l'intégration n'est pas forcément complexe.De là à trouver un designer qui va me faire mon interface en QT, c'est quand même plus complexe.
Si j'utilise JQuery/ExtJS/GWT cela va pas ètres évident car son HTML je sais pas ce que je vais en faire … mais en général le designer est la pour faire les icones, choisir les couleurs et définir/suivre/critiquer l'interface, mais le sale boulot c'est pas lui qui le fait.
Je suis d'accord qu'un designer devrait pouvoir grandement aider si tu utilise du CSS par exemple, mais dans les faits, a par changer les couleurs et certaine images, qui laisse un designer changer réélement l'interface comme la position des boites par exemple ?
[^] # Re: hum...
Posté par fredix . Évalué à 1. Dernière modification le 31 mars 2012 à 00:37.
Tu n'as pas du souvent coder des IHM native, parce que tous les outils de dev intègrent comme Qt un Qt Designer qui te permet de pauser des widgets graphiquement en quelques clics, pas besoin d'un homme/femme designer. Ensuite pas besoin de looker ton app le toolkit va utiliser le thème du système choisi par l'utilisateur.
Il y a quand même une sacré dose de mauvaise fois dans tes arguments, mais bon je met ça sur le fait que tu as du avoir une approche très légère du dev natif, d'autant plus qu'avec Qt et toute sa stack, le dev C++ est très simplifié, beaucoup plus simple que l'usine à gaz que devient le développement web.
Je constate qu'en natif on architecture, on imagine ce qu'on veut même des choses qui n'existent pas encore comme l'on fait les dev de kaaza à l'époque ou bitcoin plus récemment. En web on contourne, on empile les libs et frameworks coté serveur et côté client, pour au final mettre plus longtemps à développer un outil qui aura par définition moins de features que du natif …
Quoi qu'il en soit, web ou natif, le nerf de la guerre se situe aussi, voir surtout, sur le backend, qu'il tienne la charge, scalable, assez générique pour évoluer facilement, etc. On a des briques disparates en libre pour en faire, mais rien qui facilite le développement et l'intégration de ces briques. Ca tombe bien je taff dessus, et je dis ça aussi pour donner un peu un nouvel air frais à ce débat :)
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 2.
Ce qui est bien dans tes commentaires c'est que tu crois vraiment tout savoir et que l'autre en face de toute façon n'est pas compétent pour répondre. Finalement je comprends que sufflope soit parti en couille.
D'ailleurs, si je lis la suite :
Faut croire aussi que t'as une approche très légère du dev web finalement.
Mais je vois surtout que t'as rien compris à des problématiques de design ou d'ergo finalement.
Ha oué, pas besoin d'un designer ? Et be, on va pas aller bien loin.
Ce qui n'est pas toujours souhaitable si tu veux une ergo ou un design différent, mais bon vu qu'un designer ne sert à rien…
Ha oué, c'est vrai, architecturer, imaginer ce qui n'existe pas encore, tout ça ça n'existe que dans le monde natif. Pauvre de nous qui s'évertuons à réimplémenter encore et encore les mêmes outils sans jamais les architecturer ni imaginer.
Tu te rends compte à quel point la critique est ridicule ? Et en plus du parle de mauvaise fois ?
Histoire dans remettre un bonne couche sur le design, je te dis qu'il est plus complexe d'intégrer un designe en Qt que d'avoir un designer qui bosse avec de l'html par exemple. Réponse : de toute façon ça sert à rien on a Qt designer. Genre, dis moi ce dont tu as besoin je te dirai comment t'en passer. Supaïr !
Ben ça ferait pas de mal plutôt que de rejeter tout ce qui n'est pas natif pour des raisons à la con, finalement juste parce que tu as décrété que le web say de la merde. Mais bon…
[^] # Re: hum...
Posté par fredix . Évalué à 6.
Oui j'assume et répète que le web pour faire des app complexe c'est de la merde , et je n'ai rien contre les dev web.
Dans 99% des cas tu n'as pas besoin que ton app native ait un look différent des autres. Pour des raisons de cohérence il vaut mieux en effet qu'elle respecte les codes de l'OS. Cependant si tu souhaites vraiment la différencier, je dis que les outils des IDE graphique permettent de placer tes widgets très facilement et de les personnaliser. Ca n'a juste rien à voir avec devoir maitriser les CSS, demander à un graphiste de faire le design graphique, pour faire l'intégration ensuite.
C'est bien pour ça que des projets comme bootstrap on vu le jour, pour simplifier cet aspect lourdingue du web.
Quand je parle d'architecture je parle pas de la conception d'un projet en lui même, je pense à la création de nouveau paradigmes, et protocoles, exemple les dev de Kazaa qui ont imaginé le P2P. Par nature en web tu es bridé par ses limitations technique, en natif tu as ton compilo, un SDK, TCP/IP ce qui permet d'imaginer des architectures innovantes.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 3.
Et pourtant on a quand même des contres exemples, voir toute la suite gmail/calendar/… + google docs, etc. Ben il y a quand même pas mal de monde qui préfère cette ergo à un thunderbird par exemple.
Donc c'est loin d'être aussi 0 - 1
Bon, je crois qu'on se comprend pas vraiment sur la partie design. Ce que j'en dis c'est justement que le design est important, bien au delà de juste placer des widget et laisser le toolkit les styler. Même si c'est assez peu représentatif c'est pourtant un point très important. Tiens, un exemple rapide, il suffit de voir tout le boulot qui est fait pour améliorer le style et l'ergo de firefox par exemple. On est loin de juste pouvoir placer un widget.
Heu… non. Là on est justement pour les sites qui n'ont pas de design. Mais bon, les applis totalement moches en natif c'est quand même hyper facile à trouver malheureusement, et ça leur ferait du bien d'avoir un bootstrap aussi en natif…
Et tu es aussi bridé par toutes les contraintes existantes (par exemple fw d'entreprise) qui font qu'au final dans 99% des cas on va faire, même en natif, du REST (ou autre) sur le port 80. Attention, je trouve ça très bien hein, c'est justement parfait pour faire du client serveur avec surtout des clients (natif, web, etc). Donc oui, théoriquement on peut faire plein de choses, en pratique, en multiplateforme, en entreprise toussa, on est beaucoup plus limité malheureusement.
[^] # Re: hum...
Posté par fredix . Évalué à 6. Dernière modification le 31 mars 2012 à 10:47.
Quand je dis que c'est de la merde je parle pour moi. GMail il m'arrive de l'utiliser de temps en temps mais je préfère au quotidien un client natif. Et je constate par ailleurs le succès phénoménal de sparrow, un client mail natif sur Mac, visiblement une bonne partie de gens sont préfèrent le natif au web et payent même pour ça…
Idem pour les suites bureautique en web, elles ont leur succès via des usages casual, ou si leurs features suffit. Pour un usage avancé quotidien un client natif est indispensable.
Je répète qu'il est inutile de designer une application native, le toolkit utilise le thème défini par le user, les apps natives sous KDE/GNOME/OS X/Windows ont presque toutes le même look heureusement, et s'il y a personnalisation c'est léger, rien à voir avec le web. Il suffit de regarder le desktop que tu as sous les yeux hein.
Le protocole entre le client et le serveur n'est qu'une partie de l'architecture. En natif tu peux intégrer une lib torrent dans ton client procotole qui, oh, n'utilise pas HTTP, accéder à tout le matériel, à des fonctionnalités de l'OS inaccessible à un navigateur, etc etc …
[^] # Re: hum...
Posté par did . Évalué à 0.
Globalement tes commentaires m'ont fait herisser le poil. Je suis desole Papi mais ta connaissance du developpement web s'est arretee en 1999. Depuis, les choses ont vraiment evolue et plutot dans le bon sens.
Desole de te dire que si les applis desktop mac par exemple sont aussi belles aujourd'hui, c'est qu'entre temps et celui depuis 2003 environ, des developpeurs webs / startups ont code des apps web de fou furieux en innovant en matiere d'interfaces. Cela put etre possible car designer une UI etait devenu plus facile avec le CSS et meme chose cote interface (JS). Meme un designer pas con pouvait coder des apps funky rapidement et montrables !
Cela a cree une veritable emulation. Si tu as du temps, va sur dribbble.com et regarde les proto d'interfaces, tout simplement bluffant. Je suis desole mais en app native, je suis rarement bluffe car peut-etre elles se ressemblent toutes. Normal, vu qu'on utilise tjrs les memes toolkits et libs. Tu gagnes du temps certes mais tu perds en originalite. Heureusement c'est en train de changer mais cela a un prix…
Apres, coder une application web, c'est aussi gratifiant intellectuellement que de coder une app native. Au passage, je deteste la ségrégation faite entre developpeurs web et les autres. Un bon developpeur web (ruby, php, …etc) est un bon developpeur point barre.
Ah oui et aussi, pratiquement tout le monde a son API.
Ceci etant dit, je comprends tres bien que tu defendes ta paroisse. Mais force est de contaster que l'histoire sur les 10 dernieres annees ne t'a pas donne raison. Twitter, Facebook, Groupon, Amazon, ..etc n'ont pas fait une app native des le depart. Il faudrait que tu demandes pq non ? Tu penses qu'ils sont plus cons que toi et qu'ils n'ont pas vu l'extreme facilite avec laquelle tu peux creer et diffuser une app native ?
Tu crois aussi que l'IT des SSII, des startups, des grosses boites ont decide d'un coup de faire des apps web sans reflechir au pour et au contre.
Sois serieux 2s, faut pas pousser qd meme !
Donc oui, il est plus rapide / facile / moins cher de faire une app web qu'une app native dans la (tres) grande majorite des cas. Et tu pourras sortir tous les contre-arguments de la terre, tu auras faux. C'est un fait.
Mais comme les technos evoluent rapidement, il se peut que dans qq annees, une boite sorte un super framework de fou pour creer des apps natives, originales et deployables en 2 cuilleres a pot. D'ici la, desole pour toi mais tu vas devoir te farcir le js/css/html/ruby/php/nodejs/…etc. C'est dommage pour toi car tu loupes qq chose.
Et arrete stp, pépé, de prendre le web pour un jouet "playskool" !
[^] # Re: hum...
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 04 avril 2012 à 22:48.
Et presque toutes ont une procédure cacaNerveu(troll) ! Mais chacune étant relié a des signaux différents. C'est compliqué.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hum...
Posté par did . Évalué à 1.
Certes mais le probleme que tu decris la n'est qu'une petite partie de pourquoi les apps ont migre sur le web. Sans parler du fait que l'utilisateur lambda s'en fiche completement, lui veut au final, envoyer un email.
Je vous conseille de lire le bouquin de Marc Benioff, le gars qui a fonde Salesforce (il etait dans le top 10 de chez Oracle). Il dit texto que c'etait plus facile de creer une web app qu'un "complicated software entreprise". Et on peut dire qu'il a fait un excellent choix a l'epoque (annees 90). Ce constat est toujours valable aujourd'hui meme si l'arrivee des smartphones semblent (un peu) changer la donne.
Il faut raisonner plus loin que la technique pure mais apparemment c'est difficile pour certains….
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hum...
Posté par Juke (site web personnel) . Évalué à 3.
Le jeudi 29 mars 2012 à 14:04 +0200, CrEv a écrit :
> Non, car là tu ne parle pas d'un logiciel mais d'un service.
Et qu'est ce qu'un logiciel ? Voir les debat sur la vente liée.
[^] # Re: hum...
Posté par Toufou (site web personnel) . Évalué à 2.
Cette bonne blague :) Ce n'est pas parce que ça ne s'installe pas qu'on ne profite pas du service, un proxy ou un partage de compte et le tour est joué pour 99% des applis web.
[^] # Re: hum...
Posté par CrEv (site web personnel) . Évalué à 0.
Ce qui revient à la même chose que d'aller chercher un crack, ça marche pour tout un tas d'applications natives. (et parfois on peut même se partager un compte, utiliser un proxy ou filtrer les requêtes au serveur d'authentification).
[^] # Re: hum...
Posté par Toufou (site web personnel) . Évalué à 1.
Tout à fait d'accord et c'est ce qui fait que le piratage n'est pas un argument qui se tient quand on parle de monétisation d'une application de manière générale. Suivant le cadre et le public visés par le logiciel, on sera plus ou moins exposé au piratage et on aura des stratégies différentes pour tenter de lutter contre, et ce, quelque soit le type d'appli (web ou non).
J'imagine que WoW n'a pas les mêmes problèmes de piratage que Warcraft3, et googlemaps doit avoir des problèmes liés au piratage différents de ceux de googlemail.
[^] # Re: hum...
Posté par ckyl . Évalué à 1.
Oui enfin d'un côté t'as un binaire ou une fois qu'il est publié tu peux plus faire grand chose. Il suffit qu'un mec le crack (et il sera forcément cracké) c'est free food pour tout le monde jusqu'à la fin des temps.
De l'autre un service que tu gères, que tu peux monitorer et modifier à ta guise quand tu veux. Détecter les comptes aux comportements anormaux, je crois que c'est pas vraiment la fouille de données la plus difficile à faire. Et même si 5 ou 10% de tes utilisateurs passaient entre les mailles, le reste assure tes revenus. Tu ne pourras jamais arriver dans la situation du binaire qui correspondrait au fait que tu ais UN compte payant.
[^] # Re: hum...
Posté par Toufou (site web personnel) . Évalué à 3.
Ce que tu décris correspond à un mode en ligne ou hors ligne, pas binaire / natif mais c'est vrai que c'est moi qui ait commencé avec mon proxy :)
Ton appli web hors ligne est crackable de la meme manière que n'importe quel binaire hors ligne et un binaire se connectant sur un serveur te permet les mêmes fouilles de données qu'une appli web.
Comme l'a dit quelqu'un au dessus, il reste encore beaucoup de monde qui pense qu'une appli native est un binaire isolé du monde, tout comme une application web semble rester dans les esprits comme une application en ligne.
Pour en revenir à la question du piratage, je ne vois pas ce qu'offre de plus une techno web par rapport à du natif.
# Hors-sujet, mais…
Posté par ianux (site web personnel, Mastodon) . Évalué à 10.
Au XXIème siècle, y'a encore des
gensdéveloppeurs web qui pensent qu'une année-lumière est une unité de temps ?# J'dis ça, j'dis rien.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Le compilo V8 est très bon je crois. Avec du jit, tout ça. Donc du natif.
Idéalement, tu utilises un langage qu'on peut interpréter et compiler… JS en fait partie.
Tout ce que fait Google est bien ? G+, wave, buzz ?
Chez Google, ils adorent réinventer la roue. Ces trucs, c'est des projets persos qui ont été assez bien foutus pour devenir des produits officiels. Ça ne veut pas dire qu'ils ont été conçus pour de bonnes raisons, ni qu'ils sont vraiment mieux que ce qui existe déjà (ou qu'ils justifie qu'on les utilise à la place de l'offre existante).
Ce qui n'a rien à voir avec le fait que l'application soit native ou non, web ou nen.
Fais donc des CGI en C !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.