fredix a écrit 1945 commentaires

Si cela avait été un logiciel libre, la question ne se poserait meme pas .

Avec des Si on en ferait des choses… Posons nous 2 questions, quel éditeur serait prêt à faire un logiciel libre gratuitement ? quel utilisateur serait payer à payer pour avoir un logiciel libre ?

Mais bon tant qu'on peut lancer un vim/emacs dans un xterm, on s'en fou du reste pas vrai ?

ils peuvent aussi avoir un Linux parce qu'il répond à leurs besoins

Ou bien ils ont adapté leurs besoins à ce que peut faire Linux, afin de se convaincre qu'il répond aux besoins … :) C'est plus courant qu'on ne le croit.

Quand bien même on te garantirait qu'il s'agisse du même code source il est impossible de prouver que le binaire fonctionnant sur tel machine a été généré à partir du même code source non modifié. Mais bon ça, à part un informaticien avancé, personne ne peut le comprendre.

Je code sous eclipse et la JVM est très lente

Apparemment Apple a l'habitude de laisser des JVM moisie, d'ou des failles… Mais mon collègue qui utilise XCode pour faire de l'objective-C n'a aucun soucis.

Mais collègues ont des Mac au boulot, je les vois pas buguer…

Yth, diantre, fuir les ennuis du quotidien pour tomber dans un système carcéral, ça rassure de se voir dicter sa vie, mais moi j'préfère mes petits problèmes, sérieux !

Il y a des gens qui ne veulent plus de problèmes mais juste utiliser des softs et même se faire plaisir avec un matériel au top et supporté à 100%. Un truc qui le libre n'est pas foutu de faire outofthebox, de manière sexy, et optimisé. Bref je m'attends pas à être plussé avec ce type de message ici, mais comme l'auteur je constate une fuite du desktop de nombreux Linuxiens, dommage ..

Perso c'est simple pour définitivement résoudre ces problèmes j'ai fais comme toi je me suis ressaisi, mais j'ai décidé de passer au Mac … Le dogmatisme au bout de nombreuses années ça atteint ses limites quand tu commences à subir tes convictions…

je comprends parfaitement depuis quelque temps les gens qui passent de Linux à MacOS (j'avoue que parfois je pense à le faire - avant de me ressaisir).

genre Qt creator ?

il vaudrait mieux avoir une seule UI par défaut sur toutes les distribs

lol.

Sauf si tu limite le nombre de candidat au nombre possible de vote, exemple la note max à un seul candidat.

http://blogs.mediapart.fr/blog/gilles-sainati/030412/brazil-languedocien
Et un autre fou
http://paroledecitoyens.blog4ever.com/blog/lire-article-155111-9108238-internement_sous_contrainte_de_jean_pascal___mon_i.html

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

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.

Heu… non. Là on est justement pour les sites qui n'ont pas de design.
Et oui car c'est tellement chiant à faire le design en web que bootstrap permet de le faire très rapidement, structuré et joli.

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

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.

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.

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 …

juste parce que tu as décrété que le web say de la merde

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.

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…

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.

Pauvre de nous qui s'évertuons à réimplémenter encore et encore les mêmes outils sans jamais les architecturer ni imaginer.

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.

De là à trouver un designer qui va me faire mon interface en QT, c'est quand même plus complexe

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 :)

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 ?

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

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 ?

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.

Source? J'ai vu des deux avec une majorité pour la version mobile.

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.

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.

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.

Le truc c'est que la plupart des arguments avancés pour le natif sont de fausses raisons.

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.

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.

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.

Des arguments ont été jeté à la pelle dans ce journal et dans l'autre.

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.

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…

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.

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.

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

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.

Je préfèrerais encore qu'ils se contentent de penser au cas des logiciels sans service, sans abonnement

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, …)

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

Si linuxfr était un newsgroup perso je préfèrerais. Sinon les attaques personnelles tu pourrais t'en passer tu t'enfonces là.

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.

Et donc ? Si tu ne paye plus l'abo dropbox 50Go/mois ca ne supprime pas tes données en local.