Discussion :

[Rémy d'Aprilli]

L'avènement du HTML 5, mise à jour marquante et fondamentalement nouvelle des spécifications d'une présentation Web pourrait bien changer la donne dans le développement du Web.

Peut-on penser que HTML5 risque d'éradiquer des applications de technologie RIA (Rich Internet Application) telles que Flash d'Adobe, Silverlight de Microsoft ou encore JavaFX de Sun ?

En effet, HTML 5 va combler ses lacunes (actuellement remplies par ces trois applications) après que le W3C (World Wide Web Consortium) ait constaté que les versions précédentes de HTML ne remplissaient pas toutes leurs exigences.

HTML 5 (HyperText Markup Language Version 5) est la prochaine révision du principal langage du World Wide Web, HTML. HTML 5 spécifie deux syntaxes d'un modèle abstrait défini en termes de DOM : HTML5 et XHTML5. Le langage comprend également une couche application avec de nombreuses API, ainsi qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non conforme. Le travail a été repris par le W3C en mars 2007 après avoir été débuté par le WHATWG. Les deux organisations travaillent en parallèle sur le même document afin de maintenir une version unique de la technologie.

Bien que sorti en 2008 en draft, HTML 5 qui est déjà partiellement appliqué dans des technologies de Canvas (dessin 2D sur une page web), Firefox 3.5 (support vidéo), dans la navigation AJAX de l'IE8 ou encore dans certaines fonction de Chrome de Google, l'achèvement de ce concept n'est pas pour demain et pourrait se faire attendre encore quelques années. Alors que Sun, Adobe, Microsoft ont leurs propres technologies pour implémenter le multimédia sur le web, HTML 5 a de quoi leur tenir tête en offrant des techniques web basées sur des standards industriels.

Lire aussi :
Spécifications HTML 5 (draft)
Différence de HTML 5 par rapport à HTML 4

Pensez-vous que les solutions RIA ont un avenir, ou alors que c'est à HTML 5 de fournir la solution ?

[longbeach]

Je pense pas.
En regardant les différences entre HTML 5 et HTML 4, on voit des nouveautés qui sont déjà présentes dans les solutions RIA telles qu'un composant de drag and drop mais il n'y a pas suffisamment de nouveaux tags pour pouvoir se passer des nombreux composants très sympas déjà présents dans Flex et qui en plus vont continuer à s'enrichir.

Je ne parle que pour Flex, je ne connais pas les autres solutions RIA mais j'imagine qu'elles sont aussi riches (ou presque) que Flex.

[benwit]

Pour ma part,

si je ne crois pas à la disparition des solutions propriétaires, je crois beaucoup au développement de GWT :

- Quand GWT est sorti, il faut bien reconnaître que c'était peu utilisé chez eux (contrairement à ce qui avait été dit à l'époque). Il y avait même des GWT septiques chez Google !
- Depuis maintenant 3 ans, leur produit s'est amélioré et a été amélioré par les autres produits de Google comme Google Wave qui a obligé GWT a apporté des améliorations.
- De plus en plus de produit google utilisent GWT ... Les derniers exemples en date sont Google Fusion Table et Google Wave.

GWT repose sur ces fondamentaux du web (js, css, html) et ne nécessite donc aucun installation de plug-in.
L'intérêt, c'est la couche d'abstraction qu'il propose. Ainsi une même librairie (gwt-diagrams) peut utiliser les canvas pour les navigateurs qui le supporte et vml pour le vilain petit canard

GWT permet de faire des applications web qu'on n'imagine pas faire sans un ria à plug-in (flash, silver, ..) : Voir gwt-uml en cours de dev ...

[Invité]

Le développement en HTML ne nécessite pas d'IDE ou de SDK payant, ni de module propriétaire installé. Simplement un navigateur moderne ; or ils sont de plus en plus nombreux et innovants dans ce secteur. J'ai envie de croire que le HTML5 constituera grâce à ses évolutions, une bonne alternative aux technologies RIA actuelles.

[F.Saad]

Le développement en HTML ne nécessite pas d'IDE ou de SDK payant, ni de module propriétaire installé. Simplement un navigateur moderne ; or ils sont de plus en plus nombreux et innovants dans ce secteur. J'ai envie de croire que le HTML5 constituera grâce à ses évolutions, une bonne alternative aux technologies RIA actuelles.

parfaitement.
L'équipe de Mozilla ne nous a encore jamais vraiment déçu, j'ai envie d'y croire !
Si ce n'est simplement pour se débarrasser de FLASH, la vache a CPU.
J'ai déjà essayer le tag video, c'est révolutionnaire ! le ventilo de mon portable n'a même pas besoin de tourner !!!
Sans compter la flexibilité que cela offrirai au développeurs de site web mais aussi a l'utilisateur.Si ce n'est qu'en terme de format.
Tout ce qu'il faut c'est d'ajouter une sorte de lecteur ou de menu pour les video.
fonctionnalité deja disponible via plugin.

Mais ca risque de poser de sérieux problème pour les gens qui ont besoin de protéger leur contenue, c'est le seul inconvénient que je vois..

[Ar3s.]

Pour ces derniers je ne me fait pas trop de soucis, ce n'est pas parce qu'HTML5 permet de simplifier tes actions quotidienne qu'il pêche sur la sécurité.
(Et puis la liberté existait avant les cages donc de la même manière quelque soit les possibilités offertes par HTML5, les personnes qui ont des infos à protéger y arriveront toujours ^^)

[repié]

Pour ma part,
si je ne crois pas à la disparition des solutions propriétaires, je crois beaucoup au développement de GWT :

GWT n'est pas une solution RIA, il exploite simplement HTML, CSS, JS...
Donc GWT evolura avec HTML 5, ce qui apportera surement beaucoup d'avantages.

Personnelement, je ne connais pas trop les specs HTML 5, mais je souhaite vivement la disparition des RIA (surtout en ce moment ou ils se multiplient).

[benwit]

GWT n'est pas une solution RIA

On n'a pas la même définition de RIA alors !
Quelle est la tienne ? Toutes celles qui nécessitent un plug-in ? un plug-in propriétaire ?

Celle tirée de Wikipedia :

Les Rich Internet Applications (RIA) sont des applications web qui offrent des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. La dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces applications web.

De plus, je viens de lire "Developing with Ext GWT: Enterprise RIA Development"

Et d'après cette source :

Google est tranquillement en train d’intégrer de façon native ses propres technologies de RIA et de 3D. La stratégie de Google va (théoriquement) être de transformer son navigateur en un véritable environnement d’exécution d’applications hybrides (pouvant tourner en mode connecté ou non à l’aide de Gears) développées en Ajax, en Java (via GWT) ou en C++ (via NaCl).

[mon_nom_est_personne]

certe HTML5 est pas pour demain, mais quand je lis la spec w3c plus ce petit draft http://www.w3.org/TR/2009/WD-media-frags-reqs-20090430/ je me dis que ca va faire mal quand ca va sortir.

[repié]

On n'a pas la même définition de RIA alors !
Quelle est la tienne ? Toutes celles qui nécessitent un plug-in ? un plug-in propriétaire ?

Celle tirée de Wikipedia :


De plus, je viens de lire "Developing with Ext GWT: Enterprise RIA Development"

Effectivement, c'est une bonne definition. Mais dans ce cas la, je dirais que GWT + Gears est un RIA, mais GWT tout seul ne l'est pas.

Alors pour ce qui est de Gears, effectivement, GWT apporte un avantage considérable qui sera difficilement replacable par HTML 5

[berceker united]

Certe, GWT à l'air bien mais nécessite de connaitre Java. De plus, c'est dénué d'inconvénient.

Je ne pense pas que le HTML5 puisse rendre caduque les solutions RIA. Ces dernier (Adobe, Mozilla, Microsoft, OpenAzlo,...) ont l'avantage de pouvoir réagir bien plus vite que le W3C. Combien de temps va séparer le HTML4 et 5 ?
Dans cette période que s'est il passé au niveau du Web : beaucoup d'évolutions.
Le temps de réaction n'est pas le même.

[surfeurX]

Le html5 permettra de créer des intérfaces très intéréssante sans par passer par un tierce langage tel que flex ou autre, cependant il reste encore limité.
Pour le GWT je l'ai testé une fois avec une application pylons, et j'ai du codé nativement en javascript dans du java, sans parlé qu'on doit RESTifier toute l'application ce qui cause d'énormes risque des sécurité ... je sais que le GWT règle beaucoup de conflits mais il en crée autant, le bon choix dépend tout simplement de l'application, car on va pas mettre du GWT pour un blog, pour moi c'est une perte de temps.

[Orvinfait]

Pensez-vous que les solutions RIA ont un avenir, ou alors que c'est à HTML 5 de fournir la solution ?

Je pense plutôt qu'un lecteur vidéo SVG devrait voir le jour. Ceci dit nous ne pouvons pas opposer SVG et HTML5 car nous pouvons utiliser ces deux langages ensembles dans une même page. Il est possible de faire passer des informations d'un langage à l'autre donc d'utiliser les atouts des deux langages pour faire une application.

Pour ce qui concerne la vidéo j'ai écrit l'article : Pourquoi SVG est-il nécessaire à la Vidéo? http://www.orvinfait.fr/pourquoi_svg..._la_video.html

Si ma vision est exacte nous ne devrions pas tarder à le savoir (fin 2009 – début 2010) car je pense qu'un lecteur vidéo SVG pourrait être utile à Google pour réduire les frais de bande passante notamment pour Youtube (360 millions de dollars prévus pour 2009)

Faire fonctionner HTLM,SVG, Javascript et PHP via Ajax ensembles est aussi possible. Je l'ai fait avec un jeu de carte en réseau :

Voici l'adresse de la règle du jeu.
http://www.orvinfait.fr/jeu_tenter_pour_gagner.html
Le jeu est à
http://www.orvinfait.fr/svg/jeux/ten...ur_gagner.html
Pour ce jeu de cartes en réseau pas besoin de charger un logiciel ou de s'inscrire. Ce jeu se joue à deux mais il y a une option qui permet de tester le jeu seul. Dans ce cas deux onglets sont ouverts dans le navigateur et la personne joue pour les deux joueurs.


Pour ceux qui maîtrise JAVA je signale que SVG fonctionne aussi avec JAVA.

Vous trouverez d'autres exemples de SVG dans la discussion que j'ai lancé : SVG (Scalable Vector Graphics) peut-il remplacer Flash ?
http://www.developpez.net/forums/d60...mplacer-flash/

J'insiste encore sur le fait qu'il ne s'agit pas d'opposer HTML5 à SVG car l'erreur est souvent commise. Cette opposition est stupide puisque dans une même application nous pouvons utiliser les points forts des deux langages.

[Tommy31]

Pour ce qui concerne la vidéo j'ai écrit l'article : Pourquoi SVG est-il nécessaire à la Vidéo? http://www.orvinfait.fr/pourquoi_svg..._la_video.html

Mmm, je relève beaucoup d'incohérences dans ton article. Certes svg est un langage vectoriel, mais l'inclusion que tu fais d'une image raster produit le même effet qu'une inclusion html, il y a sur-échantillonnage de l'image (traitement des pixels).

Le gain svg se situe pour les images qui sont vectorielles, et pas trop complexe (sinon la définition de l'image peut peser plus que le rendu). Dans le cadre d'une vidéo, je ne peux pas envisager une telle issue.

[Orvinfait]

Mmm, je relève beaucoup d'incohérences dans ton article. Certes svg est un langage vectoriel, mais l'inclusion que tu fais d'une image raster produit le même effet qu'une inclusion html, il y a sur-échantillonnage de l'image (traitement des pixels).

Je me suis certainement très mal exprimé. Il faut que je revoie cela. Je ne suis pas assez clair sur ce que peux faire SVG.

SVG reconnaît trois types d'éléments graphiques :
-Les formes
-Le texte
-Les images pixels

SVG sait traiter ces trois éléments graphiques. Il possède des instructions permettant d'intervenir sur ces trois éléments. La norme SVG ne concerne donc pas seulement le dessin vectoriel mais aussi le texte et des images pixels. Je répète car cela est très important. Beaucoup de personnes ne comprennent pas l'intérêt de SVG car ils connaissent pas ou mal ce langage.

Sur la page que tu cites j'ai voulu montrer qu'un visionneur SVG conforme était plus adapté pour afficher une image jpg grossie que html. Sur cette page j'affiche deux agrandissements d'une image raster l'un avec HTML et l'autre avec SVG. Pour moi la différence est nette. Bien sûr si tu as utilisé un navigateur incapable d'afficher une image SVG correcte tu n'as pas pu voir la différence. Pour moi cette caractéristique fait que l'on peut envoyer des images plus petites avec SVG qu'avec HTML pour les grossir ensuite. Donc avec SVG il est possible de gagner en bande passante par rapport à HTML et l'élément video est présent dans la norme SVG 1.2

Pour illustrer les possibilités de SVG sur des images pixels tu peux voir par exemple avec opera (mais il est possible que cela fonctionne aussi avec Firefox 3.5 et Chrome)
http://pilatinfo.org/english/filters/etude.htm

SVG peut être utilisé pour faire du montage photo. Par exemple à http://www.orvinfait.fr/tarot.html tu pourras voir que j'ai fait un dos de cartes dans lequel j'ai inséré une photo dont je ne fais apparaître que la fleur. Dans ce dos de carte la fleur est en format pixel et le reste en vectoriel.

Pour faire facilement le contour de découpe de cette fleur j'ai créé un outil de découpe en SVG. J'ai mis cet outil à http://www.orvinfait.fr/svg/outils/d..._de_photos.php

Avec cet outil est aussi possible de faire des montages de photos au format JPG. Avec SVG il n'est nul besoin de vectoriser une image pour l'utiliser.

Le gain svg se situe pour les images qui sont vectorielles, et pas trop complexe (sinon la définition de l'image peut peser plus que le rendu). Dans le cadre d'une vidéo, je ne peux pas envisager une telle issue.

Je ne l'affirme pas non plus au bas de ma page j'indique :
"Il s'agit peut-être là d'une piste pour gagner encore en bande passante." et je renvoie vers une autre page où il y a ma photo de vectorisée. Je connais donc le poids d'une image complexe vectorisée mais je n'ai pas souhaité écarter cette hypothèse même si effectivement elle me paraît peu probable.

[Tommy31]

Sur la page que tu cites j'ai voulu montrer qu'un visionneur SVG conforme était plus adapté pour afficher une image jpg grossie que html. Sur cette page j'affiche deux agrandissements d'une image raster l'un avec HTML et l'autre avec SVG. Pour moi la différence est nette.

Je vois aucune différence. C'est pixélisé dans les 2 rendus, et ce pour les navigateurs firefox 3.1, 3.5 ainsi que Chrome, sous vista.

Quel navigateur utilises-tu ?

Pour moi cette caractéristique fait que l'on peut envoyer des images plus petites avec SVG qu'avec HTML pour les grossir ensuite.

Les fonctionnalités de mise à l'échelle sont présentes dans les deux normes, mais aucune d'elles ne précise l'algorithme mis en jeu pour la satisfaire. Ainsi, il est tout à fait envisageable que le visualiseur svg soit moins bon, égal, ou supérieur à celui du html, selon les navigateurs.

Ce qui fait que pour la problématique de la réduction de la bande passante des images rasters, la bataille opposant svg ou html n'a pas de vainqueur.

Avec SVG il n'est nul besoin de vectoriser une image pour l'utiliser.

Oui tout à fait.

[Orvinfait]

Je vois aucune différence. C'est pixélisé dans les 2 rendus, et ce pour les navigateurs firefox 3.1, 3.5 ainsi que Chrome, sous vista.
Quel navigateur utilises-tu ?

Le problème ce n'est pas le navigateur. J'ai fait des tests avec plusieurs Opera, Firefox 2, Internet Explorer 6 avec plug-in SVG et j'ai bien cette différence de rendu d'où mon erreur d'appréciation. C'est du à mon ancien système d'exploitation : Windows 98. Je viens de vérifier l'affichage sur un autre ordinateur avec plusieurs navigateurs mais sous Windows XP et là les deux images sont identiques.


J'essaye de rester objectif. Donc, comme je l'ai déjà dit mon propos n'est pas d'opposer HTML5 à SVG cela n'a pas de sens mais d'essayer de voir dans quelle direction nous allons.