Flash : pourquoi il faut encore vous y faire

Arnaud de la Grandière |
skitched

Après la défection de Flash sur les plateformes mobiles, les partisans du HTML5 ont en ligne de mire le champ de bataille suivant : les ordinateurs (lire Occupy Flash : pour un web meilleur… et inversement). Cependant les choses sont loin d'être gagnées d'avances, car Flash conserve quelques avantages auxquels le HTML5 ne peut encore prétendre.

Ubiquité du moteur d'exécution

Si Flash a bénéficié d'une adoption aussi rapide sur les navigateurs et les sites web, c'est qu'il offrait une solution à un véritable casse-tête pour les développeurs web : il offrait un moteur d'exécution unique et universel sur tous les navigateurs, alors que le HTML nécessite souvent une adaptation à chaque navigateur. C'est le fameux "write once, run anywhere" (écrivez une seule fois, exécutez n'importe où) qui fut autrefois la promesse de Java, pleinement remplie par Flash, du moins jusqu'à l'apparition des plateformes mobiles.

Précisément, l'adoption massive de WebKit comme moteur de rendu sur les plateformes mobiles a rendu le même service pour les développeurs web. Pour peu que la version mobile d'un site s'affiche correctement sur un OS mobile donné, celle-ci fonctionnera à peu près de la même manière sur toutes. Et comme précisément Flash manquait à l'appel sur iOS, c'est donc le HTML5 qui fit œuvre de passerelle par le biais de WebKit.

La donne est cependant bien différente sur ordinateurs, dont les différents navigateurs se partagent entre plusieurs moteurs de rendu : WebKit pour Safari et Chrome, Gecko pour Firefox et nombre de ses déclinaisons, et Trident pour Internet Explorer. Il ne s'agit là cependant que d'un moteur de rendu, auquel il faut également ajouter le moteur d'exécution JavaScript qui diffère encore de navigateur en navigateur, tant en fonctionnalités qu'en rapidité d'exécution, y compris parmi ceux qui partagent le même moteur de rendu. Sans oublier que les navigateurs ne supportent le HTML5 que de manière encore parcellaire (Safari 5.1.2 s'en tire avec un score de 308 sur 450, contre 342 pour Chrome sur le haut du podium)

En somme, Flash a encore de nombreux services à rendre, ne serait-ce que pour simplifier la tâche des développeurs web.

Cauchemar audiovisuel

Les choses ne s'en tiennent pas là malgré tout. Bien que le HTML5 ajoute le support de la vidéo et du son, ceux-ci ne font pour l'heure qu'augmenter le casse-tête.

En effet, le W3C n'est pour l'heure pas parvenu à imposer un standard de format de fichier, les entreprises comme Apple et Microsoft pesant de tout leur poids pour soutenir le couple H.264/AAC qui sont propriétaires, et les partisans des formats libres, de la fondation Mozilla jusqu'à Google, soutiennent Ogg Theora, Ogg Vorbis, et WebM.

Chaque navigateur, selon les prises de position de ses instigateurs, ne soutiendra qu'un seul des deux camps, et compliquent la tâche des éditeurs de sites web. Ainsi, pour qu'une vidéo soit lisible nativement en HTML5 tant par Chrome que par Internet Explorer, il faudra l'encoder dans les deux formats. Là encore Flash fait œuvre de solution universelle, puisqu'il permet à n'importe quel navigateur de lire les vidéos, qu'elles soient encodée en H.264 ou en WebM.

Si le HTML permet de basculer sur une solution de repli pour l'affichage d'une vidéo en cas d'absence de la technologie visée par défaut (ou "fallback"), dans les faits cette capacité est encore peu mise en pratique, et dans la majorité des cas c'est Flash qui conserve la priorité. Ainsi, la version d'une page compatible iOS ne sera chargée que sur détection de l'agent utilisateur correspondant, et non sur le test de la présence du plugin Flash. Ainsi, YouTube comme DailyMotion permettent d'afficher leurs vidéos en HTML5, mais seulement sur demande explicite de l'utilisateur, et non en cas d'absence de Flash. Un petit nombre d'utilisateurs de Mac a choisi de retirer Flash (dont la version Mac est très décriée pour ses lourdeurs), en s'appuyant de manière occasionnelle sur le moteur Flash embarqué dans Chrome lorsque le besoin s'en fait sentir, mais nombre de sites qui disposent pourtant d'un contenu compatible HTML5 ne le présenteront que sur iOS, à moins de modifier l'agent utilisateur dans le menu développeur.

D'autre part, Flash intègre une fonctionnalité cruciale pour les éditeurs de contenus et les ayants-droits qui manque toujours à l'appel pour le HTML5 : le support de mesures techniques de protection (DRM). En effet, la diffusion de certaines œuvres audiovisuelles sur le web ne peut se faire contractuellement que si elles sont protégées par de telles mesures, et sans elles les services de télévision de rattrapage n'auraient tout simplement pas pu voir le jour par exemple.

Mais d'autres services en ligne dépendent d'autres fonction exclusives de Flash pour la vidéo, notamment la possibilité de faire de la vidéoconférence. Le support de Skype dans Facebook, la version web d'AIM, ou encore Chatroulette ne peuvent exister que grâce à Flash. Si HTML5 permet de diffuser de la vidéo en direct côté serveur par le biais notamment du HTTP Live Streaming (qui repose sur le H.264 et qui se limite pour l'heure à Safari sur Mac et iOS), il ne peut cependant pas accéder à une webcam ni au microphone côté client. Le W3C travaille actuellement à ce problème avec les Media Capture API, encore à l'état de brouillon.

Enfin, le support du son est également encore incomplet dans le HTML5 : s'il est possible de lancer la lecture d'un son sur un événement utilisateur (clic de la souris ou pression d'une touche du clavier), il est encore difficile d'en faire autant de manière purement programmatique. Le mixage en temps réel de plusieurs pistes sonores consomme beaucoup trop de ressources, à tel point qu'Apple a désactivé le son dynamique sur iOS (officiellement pour éviter les abus de bande passante en 3G). Ainsi, nombre d'applications web réalisées en HTML s'appuient encore sur un module Flash pour gérer le son, par le biais d'une communication avec JavaScript. La performance tient donc plus de la démonstration technique que d'une réelle mise en application, car quitte à ce que Flash soit indispensable pour réaliser une application web, autant qu'elle soit intégralement développée en Flash. Au prix de lourds efforts, il reste possible de réaliser un jeu tout à fait correct entièrement en HTML, c'est en tous cas ce qu'Opera Software a démontré avec Emberwind, un jeu originellement sorti sur Windows, Mac OS X et iOS, dont les 100 000 lignes de code en C ont été portées entièrement en JavaScript.

D'autre part, s'il existe des API de bas niveau permettant de réaliser toute une panoplie d'effets sur le son en temps réel directement en JavaScript, celles-ci sont plus ou moins bien supportées (Web Audio API ne fonctionne que sur Chrome et les Nightly Builds de WebKit, tandis que Firefox supporte son propre système, bien évidemment incompatible, nommé Audio Data API).

La bataille de la 3D

Avec Flash 11, Adobe attaque le marché de la 3D en ligne, qui était jusqu'ici la chasse gardée de Shockwave dans son catalogue. L'annonce est de taille car Flash bénéficie toujours d'une base installée conséquente, à tel point que Unity, qui disposait jusqu'ici de son propre plugin, a décidé d'intégrer une sortie vers Flash à son IDE. Plus significatif encore, Epic Games a annoncé le portage du moteur Unreal Engine 3 en Flash.



Si HTML5 n'intègre pas de gestion de la 3D, un autre standard, WebGL, géré par le Khronos Group, permet d'exploiter les cartes 3D dans une page HTML. Depuis la finalisation de la version 1 en mars dernier, seuls Firefox (depuis la version 4) et Chrome (depuis la version 9) intègrent le support de WebGL en standard. Safari 5.1 n'en est qu'à un support expérimental qui est désactivé par défaut, Opera ne supporte WebGL que dans la beta de la version 12, et Microsoft n'a pas pour l'heure prévu de supporter cette technologie dans son navigateur. En cause, une sérieuse faille de sécurité (lire WebGL, maillon faible de la sécurité), suffisamment préoccupante pour que Microsoft n'envisage pas de s'y mettre (lire Apple et Microsoft jettent le doute sur la sécurisation de WebGL).

D'autre part, Flash propose d'ores et déjà une fonction appréciable qui manque toujours au HTML : le basculement en plein écran. Par ailleurs Adobe a également annoncé l'arrivée prochaine de la capture du curseur, une fonction indispensable pour nombre de contenus en 3D.

Protection des éléments

Le propre d'une page HTML c'est de contenir le lien HTTP vers chacun des éléments qu'elle contient : images, sons, vidéos, textes, code javascript et autres. Cela rend la protection des données et du code plus complexe, puisque par défaut il suffit d'afficher le code source de la page dans le navigateur pour retrouver ces éléments et les télécharger (lire Pas à pas : télécharger du contenu web).

JavaScript, le langage de programmation du HTML, et ActionScript, le langage de programmation de Flash, ont en commun de devoir être exécutables sur n'importe quelle famille de processeurs : le code ne peut donc être distribué sous forme compilée. C'est le moteur d'exécution (dans un cas le navigateur lui-même et dans l'autre le plugin Flash) qui interprétera le code pour envoyer les commandes nécessaires aux API du système et au processeur. L'inconvénient c'est que le code source doit être accessible au moteur d'exécution, ce qui l'expose potentiellement aux regards indiscrets.

Les développeurs JavaScript qui ne tiennent pas à dilapider leur savoir-faire ne peuvent recourir qu'à l'obfuscation du code. Ce procédé rend la lecture du code difficile pour un humain tout en étant exécutable par le navigateur, par le biais d'outils dédiés. Difficile, mais pas impossible, d'autant moins qu'il existe des "deobfuscateurs". Quant aux ressources tierces telles que les images, il est possible d'en empêcher le chargement en dehors de la page pour laquelle elles sont prévues, mais là encore au prix d'un développement supplémentaire côté serveur, et d'une exposition potentielle du secret partagé côté client.

Les choses sont plus simples concernant Flash, puisque le format SWF ne permet pas d'inspecter son contenu, du moins en théorie. Le code et les médias que les fichiers Flash recèlent sont relativement à l'abris des regards indiscrets, à ceci près qu'il existe également des outils permettant la "décompilation" des SWF. Il s'agit d'un abus de langage puisque le SWF n'est pas à proprement parlé compilé : le code est converti en langage intermédiaire (ou bytecode). Il est possible de convertir ce bytecode en ActionScript qui soit lisible, mais il ne sortira pas pour autant sous sa forme originale et sera plus ou moins exploitable tel quel.

En tout état de cause, rien n'empêche un concurrent indélicat de copier-coller votre code JavaScript dans sa propre page pour bénéficier de vos développements sans bourse délier, alors que la gestion cross-domain de Flash permet d'éviter ce problème. De manière générale Flash offre plus de latitudes pour protéger les investissements des développeurs et des ayants droits, puisqu'il permet d'ajouter une couche de protection supplémentaire par rapport au JavaScript : qu'on bloque les requêtes HTTP directes au fichier SWF, et tous les éléments seront hors d'accès. Il est également possible d'empêcher le stockage du fichier SWF dans le cache du navigateur.

En somme, les développements qui nécessitent de lourds investissements seront protégés avec Flash, et ouverts aux quatre vents en HTML. Une différence suffisante pour dissuader certains développeurs d'abandonner Flash.

Eco-systèmes

Les outils de développement dédiés au HTML5 sont encore relativement confidentiels. On peut citer notamment Hype, Sensha Animator, ou encore Adobe Edge actuellement en cours de développement. Du côté des jeux certains moteurs facilitent leur mise en œuvre comme par exemple Impact Engine. Mais nul ne rivalise encore avec le confort et la souplesse de Flash, d'autant moins qu'une quantité d'outils supplémentaires a vu le jour avec l'ouverture du format de fichier SWF.

skitched

D'autre part, les développeurs web eux-mêmes ont un savoir-faire incomparable avec Flash pour créer des contenus dynamiques et interactifs, alors qu'encore peu de développeurs ont eu l'occasion d'obtenir une réelle expérience en HTML5 au delà de la simple démo technique, sans oublier que chaque implémentation dans chaque navigateur fait figurer un certain nombre de bugs qu'il faut apprivoiser. Si l'on ajoute à cela le fait que c'est bien l'absence de Flash qui a motivé les investissements dans le HTML5 pour le mobile, il n'en va pas de même pour les ordinateurs : Flash reste le chemin de moindre résistance sur cette plateforme. Un jour prochain, la part des OS mobile, et la maturité du HTML5, pousseront sans doute certains sites à reconsidérer le double développement entre Flash et le HTML, mais il y a encore loin d'ici là.

Tags
avatar alainsl | 
Article vrai il y a 6 mois depuis les choses ont beaucoup évoluées et avant d'écrire un article comme celui-ci, il faut davantage se documenter. 1. Abandon de Flash Toutes les prochaines versions des plateformes mobiles seront sans Flash. 2 raisons à cela. Adobe qui a abandonné le développement d'une part, Microsoft pour Windows 8, Google pour Android, Apple pour iOS, RIM pour BBOS ont tous annoncés qu'ils ne supporteraient pas Flash. 2. HTML5 L'effet direct de cette annonce a été une avancée fulgurante du HTML5. Plusieurs labos se sont mis dessus, la ratification a accélérée... Et les derniers trous et obstacles se lèvent. Pour information, les recherches que je mène actuellement ont débouchées sur le développement d'un outil de capture et de streaming webcam avec html5 uniquement. Et tout cela en utilisant un serveur réseau en javacscript. Plusieurs labos et navigateurs sont déjà dessus et cela fonctionne !!!!
avatar Anonyme (non vérifié) | 
[quote=alainsl]Article vrai il y a 6 mois depuis les choses ont beaucoup évoluées et avant d'écrire un article comme celui-ci, il faut davantage se documenter. 1. Abandon de Flash [/quote] C'est rappelé dès la première phrase de l'article.
avatar Anonyme (non vérifié) | 
@alainsl L'abandon du Flash sur mobiles est surtout dû au fait qu'Adobe a dépensé beaucoup trop pour assurer le développement et le support sur tous ces terminaux et OS différents. "une avancée du HTML5 fulgurante" ... pour rappel la définition de fulgurant est : "Rapide, vif comme l'éclair". On doit pas parler du même HTML5 ... Tes projets labos et autres Beta qui fonctionnent sont certainement loins d'être si compatibles et opérationnels que ça à mon avis ...
avatar SteveGates | 
 Ça y est! Les ayatollahs du web standardisé et unique reprennent du service. Mais à vous lire on dirait que vous surfez encore sur des iMacs Indigo! Si certaines personnes estiment agréable un site en Flash, pourquoi pas? On dirait Orange Mécanique où on vous oblige a regarder des sites qui fond "fondre" votre processeur.... Arffff
avatar rom54 | 
@ Quintus " flash ne peut se substituer à un développement applicatif, première nouvelle, va donc voir du côté de Flex" Relis donc mon intervention en totalite avant de dire des contresens! Je dis qu'il est stupide de confondre développement Web et applicatif et que vouloir produire une WebApp absolument la ou une vraie application est nécessaire c'est idiot dans le meilleur des cas et malhonnête dans le pire. J'ai bien conscience qu'ecrire une application ca demande des compétences de developpeur et qu'il faut aussi vouloir investir dans ce developpement, a fortiori si c'est du multiplateforme. Et je suis le premier a dire aussi que Flash (ou Director) sont de superbes outils d'authorware et que Flash peut servir de moteur pour nombre de jeux... pour des applications. Le probleme c'est que Flash permet a certains de croire qu'il va combler leur incompétence en developpement et leur permettre de developper des applicatifs au sein du navigateur. Certes Flash arrive a produire quelque chose qui fonctionne, mal, approximatif, en consommant 1000 fois plus de ressources que necessaire, en introduisant quantite de failles de securite. Le pire c'est que l'information (si il y en a....) ne sera pas indexable et surtout inutilisable si le client ne dispose pas de la bonne version de Flash. C'est pas un probleme sur 6 mois, mais au-dela d'une annee??? Il faut un peu réfléchir a ce qu'est Internet: un reseau planetaire! C'est pas un "cloud" OS. Il est fait pour faire circuler de l'information, point. L'information doit y etre disponible pour longtemps, gerable par des clients qui n'existaient peut etre pas lors de la mise en service et utilisable aussi par des vieux systemes clients. On n'est pas dans l'instantanéité: sur Internet l'information ne disparait pas! C'est un non sens de l'engorger inutilement avec des scories Flashises! Et il est stupide de faire une webapp en Flash qui va passer l'ecrasante majorite de son temps a tourner en local: c'est le role d'une application. Le but d'un site internet "riche" c'est de permettre une interactive forte et precise dans l'architecture client-serveur avec des flux de donnees précisément définis et geres. On peut développer des sites extrêmement complexes et puissants avec des framework telles Ruby On Rails,... et utiliser une interface riche masquant cette complexité derrière une ergonomie adaptée et durable, ce que permet HTML5. Maintenant, que va faire un jeu en Flash: tourner en local, et éventuellement balancer quelques données sur l'utilisateur sur le reseau a son insu. C'est stupide de faire ca en Flash, une application utilise mieux les ressources matérielles et l'utilisateur en a le total contrôle (il l'installe volontairement et en gère les droits)... Prenons maintenant un jeu en reseau: il interagit avec un serveur de maniere la plus legere et rapide possible, il doit exploiter au mieux les ressources de la machine locale. Il serait stupide de le developper en Flash dans un navigateur. C'est un travail d'une equipe de pro qui va créer le serveur et les applications clientes. Que va faire une pub en Flash: polluer le site Web, rendre son chargement plus lent, ne pas etre indexable et balancer les donnees utilisateurs sur le Web a son insu. Que va faire un "chat" en Flash: rien de plus que ce que ferait une application (et certainement moins), de manière bien plus energievore et inefficace, introduisant des failles de securite majeures (utilisation des ressource materielles). Apres on s'ettone de voir de telles cochonneries se mettre a balancer des images de l'utilisateur sur le net prise a son insu.... @SteveGates [14/12/2011 04:15] " Ça y est! Les ayatollahs du web standardisé et unique reprennent du service." Si le W3C a développé des standards, ouverts et libres, c'est pour éviter justement que des technologies propriétaires infeodent le Web a des firmes ou des regimes aux volontés hégémoniques et qu'il demeure un moyen d'échange d'informations libre et utilisable pour tous. Respecter les standards permet de garantir cette accessibilité tout en permettant une grande créativité. C'est ne pas connaitre les possibilités des CSS et de Javascript que d'affirmer le contraire. http://www.w3schools.com/ Il faut comprendre que sans ces standards la recherche de contenus sur Internet serait impossible. Et le talent d'un designer, d'un concepteur ou d'un developpeur c'est de savoir utiliser les standars...
avatar Zed-K | 
[quote=rom54]Le probleme c'est que Flash permet a certains de croire qu'il va combler leur incompétence en developpement[/quote] Moui, les ingés Flex sont de vrais buses en dév. A moins que tu parle des stagiaires qui copient/collent des bouts de code trouvés sur CCM. SPOILER: Ils feront la même chose en HTML5. [quote=rom54]Certes Flash arrive a produire quelque chose qui fonctionne, mal, approximatif, en consommant 1000 fois plus de ressources que necessaire, en introduisant quantite de failles de securite.[/quote] Pour la 396542ème fois (au moins), il y a une différence entre une techno et ce que les gens en font. Quant aux failles de sécurités, les navigateurs sont mis à jour régulièrement pour combler celles liées à leur implémentation des standards (l'article évoque les problèmes de WebGL, on peut aussi parler des WebSockets) ou à leur code même. Aucun soft n'est infaillible. Et même si Adobe [i]"c'est des branleurs"[/i], ils ne mettent pas 6 mois à combler les failles de leur player (référence au patch de sécu Java made in Apple...) Bref, désolé mais ce passage est un beau ramassis de clichés et autres idées reçues basées sur des "on dit". [quote=rom54]Et il est stupide de faire une webapp en Flash qui va passer l'ecrasante majorite de son temps a tourner en local: c'est le role d'une application.[/quote] Totalement idiot en effet : - les WebApps vantées par Jobs avant de se rendre compte (thx au JailBreak) qu'un store serait plus rentable - Chrome OS : toutes les applications sont online - Les WebApps, l'HTML5 offre la possibilité de créer des WebApps pouvant fonctionner offline [quote=rom54]Prenons maintenant un jeu en reseau: il interagit avec un serveur de maniere la plus legere et rapide possible, il doit exploiter au mieux les ressources de la machine locale. Il serait stupide de le developper en Flash dans un navigateur.[/quote] Les Sims Social, Dofus. En effet c'est parfaitement stupide, les 2 faisant un bide énorme...
avatar Zed-K | 
[quote=rom54]Que va faire une pub en Flash: polluer le site Web, rendre son chargement plus lent, ne pas etre indexable et balancer les donnees utilisateurs sur le Web a son insu.[/quote] Des pubs facilement bloquables et pas indexées ?? Quel scandale ! En plus elles remontent des données utilisateurs... accessibles grâce au navigateur en Flash comme en JS. Quels salauds ces flasheurs... [quote=rom54]Que va faire un "chat" en Flash: rien de plus que ce que ferait une application (et certainement moins), de manière bien plus energievore et inefficace, introduisant des failles de securite majeures (utilisation des ressource materielles). Apres on s'ettone de voir de telles cochonneries se mettre a balancer des images de l'utilisateur sur le net prise a son insu....[/quote] Comme dit précédemment, les applications sont nombreuses. Capture directe depuis la webcam sur Youtube, visio-conférence pour messagerie instantannée (Skype, Meebo et consorts), une hérésie en effet. A tel point que le W3C se penche sur la question de la gestion de la webcam et du micro en HTML5... et plus encore (jusqu'au système de fichiers). Attention en lisant le lien suivant, tu risque de faire une syncope, d'autant plus que ça provient du W3C itself : http://www.w3.org/2009/05/DeviceAPICharter
avatar tatouille | 
"Even as innovation continues, advancing HTML5 to Recommendation provides the entire Web ecosystem with a stable, tested, interoperable standard. The decision to schedule the HTML5 Last Call for May 2011 was an important step in setting industry expectations. Today we take the next step, announcing 2014 as the target for Recommendation. — Jeff Jaffe, Chief Executive Officer, World Wide Web Consortium" then first release planed for 2014. CQFD l'article tombe a l'eau tout comme l'auteur qui se noie dans la betise et un style deplorable, lame isn't it.
avatar rom54 | 
@Zed-K "Attention en lisant le lien suivant, tu risque de faire une syncope, d'autant plus que ça provient du W3C itself : http://www.w3.org/2009/05/DeviceAPICharter" Amusant comme tentative de reponse, mais helas, le premier chapitre demonte deja tout: "1. Goals In December 2008, the W3C held a workshop on Security for Access to Device APIs from the Web. The goal of this workshop was to gather information and experiences in the device API space, to start building community consensus about possible standardization work within W3C, and to gather requirements to guide such work. ... " Le W3C travaille a améliorer les standards du WEB en permanence et a les faire évoluer avec l'évolution technologique... Lorsque le W3C enterine la definition d'une API et d'un format WEB c'est apres en avoir pese les pours et les contres. Et avoir verifie que l'extension en question et pertinente et coherente avec la nature du WEB. L'acces aux fichiers de la machine est un exemple, il permet de repondre a un besoin réel (transférer une information -le fichier- entre le client et le serveur) sans pour autant permettre n'importe quoi. Toutes les definitions duW3C tourne autour des termes "robustness, consistency, implementability, to promote interoperability"! Pour etre explicite, la grosse différence entre l'approche de Flash et d'un standard W3C c'est que Flash outrepasse le cadre du navigateur (et du Web) permettant des passerelles directes avec le matériel, la est le danger. L'autre point c'est qu'en Flash ces accès sont mal optimises, alors que dans le cas d'un standard c'est le navigateur qui va faire appel aux API de l'OS et cela doit etre optimise et sécurisé dans l'environnement d'exécution du navigateur. La différence est majeure. Tu apportes des éléments contradictoires bases sur des exemples. Le faits qu'ils existent n'en démontre pas pour autant la cohérence, ni la pertinence (quand même citer Chrome OS comme exemple alors que c'est un fiasco -attendu et confirme- fallait oser) Quant a l'argumentaire que les Webapps HTML5 peuvent fonctionner offline, en quoi le fait de permettre a un système client serveur de pouvoir fonctionner en cas de déconnexion grâce a un cache est il un argument contradictoire? En ce qui concerne le revirement d'Apple, il est lie a l'identification des risques de securite et surtout aux pietres performances par rapport a du natif. La Apple s'était bien plante dans l'analyse, enfin etait surtout de mauvaise foi car elle utilisait en interne des API permettant de creer des applications natives. Cela a ete effectivement demontre par l'univers jailbreak qui a donne acces aux API privees d'Apple et qui a permis l'emergence de vraies app, performantes et depassant allègrement les limites des webapp. La rentabilite de l'appstore l'est en premier pour les auteurs et n'est donc pas un argument ayant décidé de cette transformation profonde... Maintenant il faut répondre sur le fond a la question suivante: quel est l'avantage d'un pseudo-logiciel réalisé en Flash comme un chat par rapport a une application native? Autre question du meme genre: quels sont les avantages en general d'une pseudo-app flash par rapport a une application native? Et finalement quel est l'avantage d'utiliser une technologie propriétaire (Flash) bloquant toute interoperabilite et empêchant une indexation du contenu informationnel au sein d'un système de gestion d'information client-serveur totalement ouvert (Web)?
avatar Fulvio | 
"Maintenant il faut répondre a la question suivante: quel est l'avantage d'un pseudo-logiciel réalisé en Flash comme un chat par rapport a une application native?" Ne pas avoir à se soucier de la compatibilité des protocoles et des clients utilisés par les correspondants. "Autre question du meme genre: quels sont les avantages en general d'une pseudo-app flash par rapport a une application native?" Ne pas avoir à installer l'application et gérer sa présence sur ton poste. Ca peut mener à des abus, certes, mais pour une petite application récréative, c'est très bien. Après, moi, je ne suis pas pro-flash, mais c'est idiot de rejeter ces avantages-là, surtout quand on sait qu'il viendront sur HTML 5.
avatar Zed-K | 
[quote=rom54]Amusant comme tentative de reponse, mais helas, le premier chapitre demonte deja tout[/quote] Je ne vois pas en quoi le passage cité "démonte" quoique ce soit. Ça prouve juste qu'ils évaluent une décision avant de la prendre, comme toute personne (physique ou morale) un brin sérieuse. Ils évoquent la problématique, c'est donc bien qu'elle existe et qu'elle répond à un besoin. [quote=rom54]la grosse différence entre l'approche de Flash et d'un standard W3C c'est que Flash outrepasse le cadre du navigateur permettant des passerelles directes avec le matériel, la est le danger. L'autre point c'est qu'en Flash ces accès sont mal optimise, alors que dans le cas d'un standard c'est le navigateur qui va faire appel aux API de l'OS et cela doit etre optimise et sécurisé dans l'environnement d'exécution du navigateur. La différence est majeure.[/quote] La différence est qu'avec le Flash Player, tu as une version par plateforme. Avec le W3C, une par plateforme ET par navigateur... ET par version du navigateur. Au final ça revient strictement au même, ce n'est pas le développeur web qui accède au hardware mais un "middleware" (terme pas vraiment adapté mais on se comprend). Mais c'est vrai, c'est tellement mal optimisé qu'Unity et l'Unreal Engine y sont portés... [quote=rom54]quel est l'avantage d'un pseudo-logiciel réalisé en Flash comme un chat par rapport a une application native? quels sont les avantages en general d'une pseudo-app flash par rapport a une application native?[/quote] Le fait qu'il n'est pas nécessaire d'installer quoique ce soit pour l'utiliser (Flash ou HTML5, peu importe la techno). Le principe même des WebApps : - utilisables sur un parc info interdisant l'installation de soft tiers - accessibles depuis n'importe quelle machine reliée au net - centralisées, donc toujours à jour niveau correctifs bugs et sécurité En suivant ta logique, GMail ou Google Docs ne présentent aucun intérêt. Combien d'utilisateurs à travers le monde ?
avatar Zed-K | 
[quote=rom54]En ce qui concerne le revirement d'Apple, il est lie a l'identification des risques de securite et surtout au pietre performances par rapport a[/quote] Ça a coupé ;) Si tu pense que Jobs a décidé de partir sur des applications natives pour des raisons de sécurité, désolé mais c'est à mourir de rire. - une WebApp sera toujours à jour comme dit plus haut, les seules failles exploitables pouvant provenir de Safari iOS - une application native a elle accès au hardware directement, et des failles sont régulièrement pointées du doigt (comme sur tout système quel qu'il soit hein, je n'incrimine pas particulièrement Apple, comme je l'ai dit précédemment aucun système n'est infaillible). Si Apple a lancé l'AppStore, c'est clairement pour des raisons de contrôle de leur écosystème... et de gros sous, ne soyons pas naïfs.
avatar rom54 | 
@Fulvio [14/12/2011 14:17] Ca n'a pas de sens. Par principe le chat est et doit définir un protocole (existant ou nouveau) et sur plusieurs niveaux. Apres on peut avoir de multiples interfaces de gestion, mais toutes respectent le protocole défini... L'inconvenient qu'il y a en plus c'est qu'en utilisant pas un port dedie, c'est que le flux va passer par le port 80 ce qui va surcharger le navigateur et creer une surcharge artificielle de ce port... En effet décharger l'utilisateur de sa responsabilité décisionnelle conduit a de nombreux problèmes. Exemple: les applications de chats des sites pour adultes..., les jeux tournant sur les PC de travail (servant accessoireement de keylogger ou de troyens),.... Si on a acces a la totalite de son PC on fait ce que l'on veut avec et on en est totalement responsable des conséquences de son pouvoir décisionnel en la matière. Si il y a une structure de gouvernance sur le PC (compte administrateur et utilistateur, domaine autorises, ports ouverts et fermes) c'est pour une raison. Soit elle est mauvaise et on la change, soit elle est bonne et tout systeme permettant de detourner le principe de gouvernance expose a des risques consequents, soi mais aussi les autres. "Après, moi, je ne suis pas pro-flash, mais c'est idiot de rejeter ces avantages-là, surtout quand on sait qu'il viendront sur HTML 5." Viendront ils sur HTML5? Rien n'est moins certain.
avatar BioSS | 
Rom54 t'es insupportable de mauvaise foi.
avatar Quintus | 
@rom54 Si tu pouvais m'éclairer sur le point suivant : pourquoi il y a de plus en plus d'application IOs développé sous Flex et de très bonne facture (celle de Rossignol pour n'en citer qu'une) qui ne sont même pas multi plateforme alors qu'elles pourraient l'être très facilement. Elles ont été développées par des buses incapables de faire de l'Objectif C et d'attaquer directement les API système ? L’avantage de ces "pseudo-app" est un temps de développement réduit avec une une excellente portabilité. L'AS3 n'est pas le meilleur langage comparé à C# ou Java mais c'est la crème comparé à Javascript qui est à pleurer pour un vrai développeur et ne t'y trompes pas, les copiés collé de code en HTML qui feront de mauvaises applications seront d'autant plus nombreux et facile que le code est accessible avec HTML5/JS c'est garanti.
avatar rom54 | 
@Zed-K [14/12/2011 14:34] [quote] Je ne vois pas en quoi le passage cité "démonte" quoique ce soit. Ça prouve juste qu'ils évaluent une décision avant de la prendre, comme toute personne (physique ou morale) un brin sérieuse. Ils évoquent la problématique, c'est donc bien qu'elle existe et qu'elle répond à un besoin. [/quote] Bien entendu qu'elle existe cette problématique. D'un cote on a une organisation qui a ete fonde pour maintenir les fondamentaux du Web: disposer d'un réseau ouvert et libre permettant un échange de flux d'informations interoperables dans le long terme et totalement décentralisé. De l'autre on a des firmes et états qui veulent pour des raisons commerciales ou politiques un systeme centralisé expurgé de toute interoperabilite et ou le décideur peut modifier (et supprimer) une information a tout moment. Les décisions d'implenter dans le standard une fonction depend de sa pertinance et de sa coherence avec les fondations du Web. En ce qui concerne Flash, c'est le marche (les firmes) qui fait pression et decide de ses possibilites.
avatar Fulvio | 
"Ca n'a pas de sens. Par principe le chat est et doit définir un protocole (existant ou nouveau) et sur plusieurs niveaux. Apres on peut avoir de multiples interfaces de gestion, mais toutes respectent le protocole défini... L'inconvenient qu'il y a en plus c'est qu'en utilisant pas un port dedie, c'est que le flux va passer par le port 80 ce qui va surcharger le navigateur et creer une surcharge artificielle de ce port..." Par principe, peut-être, mais dans les faits, si j'utilise un client Jabber et mon correspondant un client MSN, l'un de nous devra installer un logiciel et créer un compte quelque-part. Quant à surcharger le port 80, la limite de débit d'un port est celle de ta connexion, et non pas une limite qui lui serait propre. Ce n'est pas un sous-tuyau au diamètre inamovible, mais un drapeau sur la communication. De fait, il n'est jamais surchargé. "En effet décharger l'utilisateur de sa responsabilité décisionnelle conduit a de nombreux problèmes. Exemple: les applications de chats des sites pour adultes..., les jeux tournant sur les PC de travail (servant accessoireement de keylogger ou de troyens),.... Si on a acces a la totalite de son PC on fait ce que l'on veut avec et on en est totalement responsable des conséquences de son pouvoir décisionnel en la matière." Ben justement, une appli web (flash inclus) a un accès potentiel beaucoup plus restreint qu'une appli native. Ca ne restreint pas la décision de l'utilisateur.
avatar Zed-K | 
[quote=rom54]D'un cote on a une organisation qui a ete fonde pour maintenir les fondamentaux du Web: disposer d'un réseau ouvert et libre permettant un échange de flux d'informations interoperables dans le long terme et totalement décentralisé. De l'autre on a des firmes et états qui veulent pour des raisons commerciales ou politiques un systeme centralisé expurgé de toute interoperabilite et ou le décideur peut modifier (et supprimer) une information a tout moment.[/quote] Bref, en gros, tu change complètement de sujet. Tu disais que l'accès au hardware depuis le navigateur comme le fait Flash avec ses API d'accès aux webcams et micros était une aberration, tout en louant les mérites du W3C et des standards. Je te montre juste que le W3C réfléchi à faire de même, et là tu pars sur la distinction entre les standards et une techno propriétaire... le tout en prenant soin d'éluder les autres points sur lesquels j'ai pris la peine de te répondre.
avatar Fulvio | 
"Les décisions d'implenter dans le standard une fonction depend de sa pertinance et de sa coherence avec les fondations du Web. " Les fondations du Web, c'était juste du texte avec des hyperliens et un poil de mise en forme, donc bon.
avatar rom54 | 
@Zed-K [14/12/2011 14:34] [quote] La différence est qu'avec le Flash Player, tu as une version par plateforme. Avec le W3C, une par plateforme ET par navigateur... ET par version du navigateur. Au final ça revient strictement au même, ce n'est pas le développeur web qui accède au hardware mais un "middleware" (terme pas vraiment adapté mais on se comprend). Mais c'est vrai, c'est tellement mal optimisé qu'Unity et l'Unreal Engine y sont portés... [/quote] Si encore c'etait vrai. Flash a permis un moment de resoudre l'incoherence que posait la domination d'Internet Explorer qui ne respectait aucun standard (logique de Microsoft de faire un Web non interoperable et base sur des techno proprietaires), et permettait aussi aux designer de faire des sites ayant un aspect similaire entre les divers versions d'IE et aussi des autres navigateurs sans se casser la tete. Depuis qu'IE a perdu son monopole, cet argument ne tient plus. De plus, il courrant qu'un site Web soit tributaire d'une version specifique de Flash, ce qui oblige l'utilisateur a installer cette version. Aujourd'hui on voit que les terminaux mobile ne disposent (ront) pas de Flash. L'utilisateur est donc tributaire de l'existance d'une technologie propriétaire pour consulter une information qui se trouve sur un systeme pourtant ouvert et interoperable... Les definitions du W3C sont universelles, donc un standard qui doit donner la meme chose quelque soit le client. Je t'accorde qu'on a encore des progres a faire pour arriver a cela, mais le probleme, meme s'il diminue constamment, est de la responsabilite de l'editeur du navigateur. Et dans le futur, un navigateur x pourra lire sans probleme un site respectant les standards W3C, que ce soit dans un an ou dans 100 ans. Acceder aux ressources de la machines est tres different entre Flash et le W3C. Je le répète Flash outrepasse totalement le cadre d'exécution du navigateur, avec les conséquences que cela peut avoir.
avatar Quintus | 
@rom54 Ne te leurre pas à propos des standards et du marché, les grands bénéficiaires de cette marche forcée vers le HTML5, ce sont justement les grands éditeurs du marché qui vont pouvoir justifier des mises à jour pendant des années de leurs outils (qui étaient arrivé à maturité avec la techno flash et html/css classique) comme Dreamweaver, Flash (qui exportera de l'HTML5) etc. Elle est pas belle la vie. C'est beau d'avoir autant de certitudes, profite, cela ne dure jamais :-)
avatar Zed-K | 
[quote=rom54]...[/quote] Ta réponse n'a encore une fois aucun rapport avec le point que tu soulevais et auquel je te répondais. A chaque fois tu reviens sur ce débat standards VS proprio que je n'ai JAMAIS lancé, c'est complètement HS. De plus, je ne crois pas avoir défendu un web propriétaire, je précise juste qu'il faut rendre à César ce qui appartient à César et ne pas oublier à quel point le W3C a littéralement laissé le web s'embourber (et les plugins propriétaires proliférer pour combler les manques) pendant plus de 10 ans. [quote=rom54]Et dans le futur, un navigateur x pourra lire sans probleme un site respectant les standards W3C, que ce soit dans un an ou dans 100 ans.[/quote] Ahahah c'est beau d'y croire =) Le fait est que les navigateurs actuels ne sont toujours pas d'accord sur l'interprêtation de standards vieux de 5 ans ou plus (voire beaucoup plus pour certaines choses, notamment côté JS). Malgré cela, ils implémentent chacun de leur côté l'HTML5 à leur sauce, un standard qui n'en est pas un puisqu'à l'état de draft, ce pour encore plusieurs années, et donc voué à évoluer au fil du temps. Il va donc falloir attendre 2014 pour que l'HTML5 soit validé (ou pas), 5, 10, 15 ans pour que tous les navigateurs arrivent à quelque chose d'un tant soit peu homogène de l'un à l'autre (vu la guerre des navigateurs c'est mal barré, chacun voulant tiré la couverture à soit en intégrant la dernière fonction tip-top, c'est aussi pour ça que l'HTML5 buzz beaucoup, soyons lucides)... Et pendant ce temps, de nouveaux documents seront en étude... et déjà en cours d'implémentation prématurée dans les navigateurs. Je prie pour que ça ne continue pas comme ça, mais un web homogène et des [b]standards[/b] dont le nom a enfin un sens, on attend ça depuis la guéguerre IE versus Netscape... et ça a pas l'air de se calmer, loin de là.
avatar Quintus | 
@Zed-K +1 Tout à fait de ton avis, il y a du boulot, d'ici que l'on ait un javascript acceptable, une compatibilité et des fonctionnalités identiques sur tous les navigateurs, il va couler de l'eau sous les ponts
avatar BioSS | 
Non mais ce mec n'y connaît quedalle comme tous les terroristes de l'HTML5 / Flash, je sais même pas pourquoi vous vous faites chier à lui répondre. Les pionners étaient sur Flash, ils le sont encore et c'est les même qui sortent les meilleures démos HTML5, preuve du talent de cette communauté. Le web a encore besoin pour longtemps de Flash, quand on voit qu'un simple H264 en html5 pose problème selon les navigateurs pour des histoires de licence de codec… On s'en branle. On veut un truc qui marche. Flash ça marche. Point.
avatar Marc-Alouettes | 
@BioSS :"On veut un truc qui marche. Flash ça marche. Point." Qui est ON ? Tu dirais JE, OK mais perso j'ai erradiqué Flash et je m'en porte infiniment mieux depuis. (On est pas tous des "HardGamers, hein ?) J'ai l'impression que MacGé défend Flash "mordicus" du fait que c'est en grande partie, son gagne pain et c'est donc bien normal. Ce que je trouve très amusant, c'est que les anciens frères ennemis (MS et Apple) sont devenus copains comme cochons pour défendre html5 et H.264 !
avatar Marc-Alouettes | 
@BioSS: "On veut un truc qui marche. Flash ça marche. Point." Encore un Ayatholla du Flash. On s'en branle de ce tu voudrais nous imposer. On est pas tous des "HardsGamers" , hein ? Et si, tu pouvais admettre que pour beaucoup d'entre nous Flash est une merde sans nom qui nous bouffe tout le CPU au détriment de notre boulot ? Es-tu as même de comprendre cela ? Ce n'est pas pour autant que nous crachons sur Flash car beaucoup y trouvent leur compte. barre
avatar pol2095 | 
D'un côté tu as une Porsche (Flash), de l'autre une Dacia (le HTML5), la Dacia consomme moins, suivant l'utilisation chacun a sa place.
avatar Anonyme (non vérifié) | 
Pour tous les commentaires à propos de chatroulette il ne faut pas coller d'étiquette à ce système. Les "branlettes" c'est fini car il y a plusieurs chatroulettes alternatifs. En gros pour le chatroulette de rencontre il y a WizzCam pour ne citer que lui et pour le "chatroulette classique" vous verrez qu'on peut le considérer comme "tout public" maintenant. Donc : oui, le flash a encore tout son avenir pour ce genre de service et bien d'autres !...

Pages

CONNEXION UTILISATEUR