iphone? HTC? - Page 97

Nil (./2833) :
Ben... oui, c'est abandonné, en fait... http://www.frandroid.com/android/developpement/345342_microsoft-enterre-project-astoria-pour-faire-tourner-des-apps-android-sur-windows-10

Pen^2 (./2834) :
Merci ! C'est un peu dommage... :/
edit : tiens apparemment il y a des alternatives

Un peu comme WINE, mais dans l'autre sens. Les temps changent.

Zeph (./2835) :
Ce qui est surtout dommage c'est que les développeurs n'essaient pas de faire des applis en HTML/JS. Dans une grosse majorité des cas c'est largement suffisant, et au moins c'est compatible avec toutes les plate-formes.

Heureusement qu'ils ne font pas ça!

Godzil (./2859) :
Zero: a vrai dire vu comment certains codent comme des porcs, j'aurais tendance a penser que si le navigatueur web est pas trop mal foutut, il pourrais consommer moins qu'une app native avec des perfs équivalentes

Sauf que le pire code de porcs se trouve dans les sites web.

- Le calcul d'itinéraire est fait par le serveur et non l'appareil

En théorie, oui. En pratique, tu risques de te retrouver avec du JavaScript côté client qui rame à fond (soit parce que les développeurs se situent toujours dans le contexte d'un client lourd, soit exprès pour économiser les ressources du serveur au dépens de celles de ton appareil).

C'est vrai que google map fait tout avec du JS et aucune utilisation des serveurs.

(Mais Google Maps rame à mort )

Non c'est pas OSS donc c'est le mal (absolu)

La navigation est (probablement – je n'ai pas vérifié) faite côté serveur, mais Google Maps a quand-même une énormité de JS pour l'affichage. Il suffit d'essayer d'aller dessus avec KHTML pour s'en rendre compte (je me tape une fenêtre remplie par le fond gris, quelques contrôles dans les coins, mais pas de carte!). Et même avec Konqueror+KWebKitPart, j'ai un avertissement que c'est le "mode Lite" (qui occupe quand-même un de mes 2 cores à 100% quand je zoome, alors qu'est le mode pas lite?!).

Kevin Kofler (./2881) :

Heureusement qu'ils ne font pas ça!

Kevin Kofler (./2881) :
Sauf que le pire code de porcs se trouve dans les sites web.

Difficile de trouver quoi répondre devant tant d'arguments

Les versions récentes de Chromium et Firefox sont optimisées à mort pour la performance du JavaScript pour masquer dans la mesure du possible l'incompétence des "développeurs" web. Essaie les sites web "modernes" avec quelque chose comme KHTML et tu verras à quel point ils rament. Les moteurs JavaScript sont de plus en plus optimisés en vitesse (au dépens de la sécurité – faire du JIT sur du code auquel on n'a pas confiance est beaucoup plus dangereux qu'un interpréteur pur, la probabilité de trouver un moyen d'exécuter du code arbitraire est beaucoup plus grande pour un JIT) pour permettre aux sites d'être de plus en plus lents sans que l'utilisateur ne s'en rende compte.

Et pour que ce soit clair, je ne vise pas yAro et toi! yN est vraiment léger par rapport à ce qu'on trouve ailleurs.

Moui, je trouve quand même ça assez arbitraire comme argument. Oui, les moteurs JS ont eu énormément d'attention ces dernières années et ils sont optimisés à mort, du coup la comparaison avec d'autres langages n'est pas tout à fait honnête. En revanche je ne pense pas que ça permette d'en conclure qu'une appli web sera plus mal codée qu'une appli "native" (pour ce que ça veut dire, surtout sous Android) mobile. Il y a un besoin énorme également de ce côté, beaucoup de gens qui s'improvisent développeurs et une qualité au final qui n'est probablement pas tellement mieux que ce qu'on trouve sur les sites web. Même l'argument de performance ("les smartphones sont moins puissants donc il faut optimiser un minimum") ne tient plus tellement, avec la puissance des appareils modernes.

KK > tu nous donnes surtout des arguments contre KHTML, là

Oui et non. Si tu te places du point de vue de l'utilisateur, effectivement KHTML sera moins agréable à utiliser que Chrome, donc c'est un argument "contre".

Maintenant si tu réfléchis plus globalement, optimiser à fond les perfs du JS c'est bien dans un sens (ça rend viable des usages qui étaient impossibles avant), mais mauvais dans l'autre (ça encourage les gens à coder sans se préoccuper de la qualité, ça nécessite des ressources qui ne sont plus dispos pour d'autres choses, ça ne favorise pas l'émergence de solutions meilleures que l'existant). Un peu comme le fait que les navigateurs sont très tolérants sur la syntaxe HTML : c'est sympa pour les débutants, mais ça encourage des horreurs et c'est un boulet à maintenir.

Kevin Kofler (./2887) :
Les versions récentes de Chromium et Firefox sont optimisées à mort pour la performance du JavaScript pour masquer dans la mesure du possible l'incompétence des "développeurs" web. Essaie les sites web "modernes" avec quelque chose comme KHTML et tu verras à quel point ils rament. Les moteurs JavaScript sont de plus en plus optimisés en vitesse (au dépens de la sécurité – faire du JIT sur du code auquel on n'a pas confiance est beaucoup plus dangereux qu'un interpréteur pur, la probabilité de trouver un moyen d'exécuter du code arbitraire est beaucoup plus grande pour un JIT) pour permettre aux sites d'être de plus en plus lents sans que l'utilisateur ne s'en rende compte.

En même temps C et C++ sont aussi optimisés a mort et tu ne vas pas t'en plaindre. Tu ne peux pas à le fois dire que le Web doit être lent et te plaindre qu'il soit lent.
Le HTML devient un environnement d’exécution du type VM Java qu'on le veuille ou non, car c'est le moyen le plus accessible. donc autant que ça soit efficace.

./2890 : Là encore je ne suis pas d'accord. Optimiser les moteurs JS permet une navigation plus agréable et rend accessible des applications web qui n'auraient pas été réalisables sinon (ou alors elles auraient été lentes et pénibles à utiliser). Le fait que ça permette à des développeurs d'être paresseux n'est qu'une malheureuse conséquence. Tandis que tolérer les erreurs de syntaxe HTML c'est encourager les développeurs à ne pas faire attention à leur code, ça ne débloque pas de nouvel usage ni de permet d'atteindre aucun objectif qui n'était pas déjà atteignable sans cette fonctionnalité.

full-

Je ne pense pas que ce soit aussi simple que ça, parce que toutes les optimisations n'affectent pas tous les programmes, et que leur coût n'est pas nul.

Pour prendre un exemple : remplacer un algo en O(n) par un algo en O(log N) dans le code de gestion des objets DOM, sur le papier c'est une bonne chose. Mais en pratique, ça pourrait très bien n'avoir un effet notable que pour les codes qui créent un nombre d'objets complètement excessif. Du coup, tu as passé du temps et introduit de la complexité dans ton code pour quelque chose qui ne bénéficie qu'aux "mauvais élèves" (et qui encourage indirectement les développeurs à être paresseux).

L'autre point, c'est qu'optimiser une technologie faiblarde peut être contreproductif, en dissuadant la transition vers une technologie meilleure. Je pense qu'on connait tous des projets qui ont été bidouillés dans tous les sens pendant des années, et qui se porteraient mieux s'ils étaient refondés sur des bases saines.

Après, tout ça est assez théorique : il suffit que l'un des navigateurs principaux se mette à optimiser un point pour que les autres le suivent, juste pour ne pas être dépassés par la concurrence.

C'est une réponse partielle : je suis d'accord avec tes deux points mais je les range dans les "malheureuses conséquences" que j'évoquais au ./2892. Il n'y a bien sûr pas que des bénéfices à optimiser une technologie à mort au détriment d'autres, tes exemples le montrent bien, mais je ne suis quand même pas d'accord avec la comparaison à la permissivité HTML des navigateurs.

(c'était peut-être pas une très bonne comparaison, j'avoue )

flanker (./2889) :
KK > tu nous donnes surtout des arguments contre KHTML, là

Je ne peux effectivement plus conseiller KHTML, même le projet KDE l'a laissé tomber, il n'a pas réussi à suivre avec le web de plus en plus gourmand, en ressources (CPU etc.) comme en "fonctionnalités" dont on se passait très bien pendant des décennies. Comme solutions Qt/KDE, il ne reste plus que QtWebEngine d'un côté, et une tentative communautaire de ressusciter QtWebKit de l'autre. QupZilla 2 est un navigateur basé sur QtWebEngine, il fonctionne avec tous ces sites "modernes".

Uther (./2891) :
Le HTML devient un environnement d’exécution du type VM Java qu'on le veuille ou non, car c'est le moyen le plus accessible. donc autant que ça soit efficace.

Il me semble qu'Uther a tout résumé avec cela. Je suis de mon côté persuadé que l'avenir (grand public) sera au tout-par-web, à la Chromebook. Pas que je pense que ce soit une bonne chose, mais c'est quelque chose qui aurait du mal à être évité.
La question est "quand ?". Ce qui ralenti encore l'arrivée de cette ère est justement Javascript : le langage, de base, est mauvais. Et conséquence indirecte, des tas de super-langages plus ou moins expérimentaux se greffent dessus sans qu'il n'y ait de véritable vainqueur. Le monde du JS est bien trop instable, peu se lanceraient dans une carrière basée sur un framework en particulier. L'arrivée de V8 et de HTML5 ont permis de très grandes avancées dans les applis web dès le moment où elles pouvaient fournir du contenu riche sans devoir se baser sur un plugin comme Flash, Java, Silverlight. Ce n'est pas tant l'optimisation des ressources qui est à discuter ici mais davantage "comment écrire l'appli ?". En backend, faire le site en PHP, Python, Rails, n'est pas un problème, ça fonctionnera avec tous. En frontend, on est forcé de faire du JS, mais on ne sait pas comment. Là au moins Flash, Java et Silverlight n'avaient pas tant ce problème.

(je sais pas pour l'avenir, mais pour le moment les Chromebooks ne rencontrent pas vraiment le succès. Bon, le positionnement marketing ne doit pas aider non plus)

En France, pas vraiment, mais au USA les ChromeBooks ce vendent déjà mieux que les MacBook.

Ah bon ? J'espère que ça se vend mieux que le Macbook (le truc 12" qui fait re-mourir Jobs de honte dans sa tombe tous les jours là) mais pas que les Macbook Pro, sinon y a du souci à se faire...

Uther (./2900) :
En France, pas vraiment, mais au USA les ChromeBooks ce vendent déjà mieux que les MacBook.

C'est assez récent comme phénomène, mais en effet, les ChromeBook se vendent bien maintenant (et matériellement, ils ont l'air plutôt pas mal)

Meowcate (./2898) :

Il me semble qu'Uther a tout résumé avec cela. Je suis de mon côté persuadé que l'avenir (grand public) sera au tout-par-web, à la Chromebook. Pas que je pense que ce soit une bonne chose, mais c'est quelque chose qui aurait du mal à être évité.La question est "quand ?". Ce qui ralenti encore l'arrivée de cette ère est justement Javascript : le langage, de base, est mauvais. Et conséquence indirecte, des tas de super-langages plus ou moins expérimentaux se greffent dessus sans qu'il n'y ait de véritable vainqueur. Le monde du JS est bien trop instable, peu se lanceraient dans une carrière basée sur un framework en particulier. L'arrivée de V8 et de HTML5 ont permis de très grandes avancées dans les applis web dès le moment où elles pouvaient fournir du contenu riche sans devoir se baser sur un plugin comme Flash, Java, Silverlight. Ce n'est pas tant l'optimisation des ressources qui est à discuter ici mais davantage "comment écrire l'appli ?". En backend, faire le site en PHP, Python, Rails, n'est pas un problème, ça fonctionnera avec tous. En frontend, on est forcé de faire du JS, mais on ne sait pas comment. Là au moins Flash, Java et Silverlight n'avaient pas tant ce problème.

Ça va être pratique pour faire des réseaux déconnectés

flanker (./2902) :
C'est assez récent comme phénomène, mais en effet, les ChromeBook se vendent bien maintenant (et matériellement, ils ont l'air plutôt pas mal)

Google a surtout investi lourdement dans la pub, particulièrement a destination des étudiants. Bref, ils ont battus Apple a leur jeu de prédilection.
C'est triste mais dans l'informatique comme ailleurs, la pub fait beaucoup plus le succès d'un produit que ses qualités intrinsèques

flanker (./2902) :
Ça va être pratique pour faire des réseaux déconnectés

Avec le HTML moderne Il y a des API pour stocker des éléments d'un site pour une utilisation offline.

Uther (./2903) :
Avec le HTML moderne Il y a des API pour stocker des éléments d'un site pour une utilisation offline.

Je parle d'un réseau qui n'est jamais connecté à internet ^^

flanker (./2904) :

Uther (./2903) :
Avec le HTML moderne Il y a des API pour stocker des éléments d'un site pour une utilisation offline.

Je parle d'un réseau qui n'est jamais connecté à internet ^^

Je vois pas ou est le problème. Les Applis Web peuvent marcher sans problème sur un réseau fermé.

Oui, quand tu peux les installer en interne. Comment fais-tu pour installer Google (enfin, de quoi faire fonctionner un Chromebook) en local ?

Google n'est pas le seul a a voir le droit de faire des appli web tu sais?

Uther (./2907) :
Google n'est pas le seul à avoir le droit de faire des appli web tu sais ?

Ah ?

Plus sérieusement, il y a de plus en plus un mélange d'applis lourdes avec des services web que tu ne peux pas remplacer (notifications, Office qui va chercher pas mal de choses en ligne, Siri/Cortana/GoogleNow de plus intégrés dans les OS et font de plus en plus de choses, la plupart des messageries récentes ou systèmes de synchro comme DropBox ne sont pas utilisables en local). Sans compter les pures applis web qui n'ont pas d'équivalent installables chez soi (Google Doc, pour revenir à Google).

Alors oui, on peut parfois trouver des équivalents, souvent bien pénibles à installer et beaucoup moins agréables à l'usage, qui ne seront de toute façon jamais correctement intégrés : une appli qui est faite pour utiliser DropBox pour la synchro ne permettra jamais d'utiliser Seafile ou Owncloud.

Actuellement, si tu installes un Windows ou un OS X sur un réseau déconnecté, tu perds un certain nombre de fonctionnalités, ce n'était pas le cas il y a 10 ans et le mouvement ne va pas diminuer.

Uther (./2903) :
C'est triste mais dans l'informatique comme ailleurs, la pub fait beaucoup plus le succès d'un produit que ses qualités intrinsèques

C'est clair, malheureusement. Un autre exemple est le succès inexplicable de Skype, alors que tout ce que ce logiciel apporte (VoIP (avec ou sans vidéo), messagerie) existait depuis des années dans des logiciels comme ICQ ou NetMeeting, ainsi que dans des logiciels libres interopérables avec eux. Même des ponts vers le réseau des téléphones physiques existaient déjà. Et contrairement à ces alternatives déjà existantes à l'époque, aucun autre logiciel ne peut interopérer avec Skype. Je ne vois aucun avantage technique de Skype, son succès était du pur marketing (et l'effet réseau a fait le reste, mais il fallait d'abord battre celui des alternatives établies).

Kevin Kofler (./2909) :
C'est clair, malheureusement. Un autre exemple est le succès inexplicable de Skype, alors que tout ce que ce logiciel apporte (VoIP (avec ou sans vidéo), messagerie) existait depuis des années dans des logiciels comme ICQ ou NetMeeting, ainsi que dans des logiciels libres interopérables avec eux. Même des ponts vers le réseau des téléphones physiques existaient déjà. Et contrairement à ces alternatives déjà existantes à l'époque, aucun autre logiciel ne peut interopérer avec Skype. Je ne vois aucun avantage technique de Skype, son succès était du pur marketing (et l'effet réseau a fait le reste, mais il fallait d'abord battre celui des alternatives établies).

Quand il a commencé à avoir du succès, c'était de loin la solution qui fonctionnait le mieux.