Appli WEB hors ligne pour de vrai ?

[Xavier NOPRE]

Bonjour à tous,

On entend beaucoup parler de la tendance forte actuelle pour les applications WEB, HTML5, le fonctionnement hors ligne, etc ... [une idée de sujet pour une interview des CC ? ....]

Je viens de creuser le sujet, notamment HTML5, par rapport au besoin de fonctionnement hors ligne : mode "offline" et événements associés, cache, stockage local (localStorage ou IndexedDB), etc ...

Et ça confirme ce que j'avais en tête : les nouveautés apportées par HTML5 vont évidemment dans le bon sens et son prometteuses. Mais tout cela me semble très neuf (trop ?), encore mouvant (la spec IndexedDB a changé encore récemment), très orienté mobile (le "offline" ne fonctionne pas sur un ordi, du moins avec Firefox), et bien sûr, très bas niveau.

J'aimerai donc savoir s'il y a des personnes qui ont travaillé, "pour de vrai", sur de telles applications, des applis WEB client-serveur capables de fonctionner hors ligne (au moins un certain temps), et si oui, échanger sur les bonnes et mauvaises pistes, bonnes et mauvaises solutions, les libs intéressantes, etc ...

Merci

Xavier

[Jocelyn Lecomte]

Le cache offline est supporté par firefox depuis la version 3.5. Pour ce qui est des applications, tu as quand même du lourd avec les applications des chez Google:
http://techcrunch.com/2011/08/31/googles-new-html5-chrome-apps-for-gmail-calendar-and-docs-give-users-offline-access/

[Xavier NOPRE]

Salut Jocelyn,

Merci pour ta réponse,

Le cache offline est supporté par firefox depuis la version 3.5.

Oui, j'ai "joué" avec (d'ailleurs surprenant, attention les effets de bords ...), mais un cache de pages, ça ne fait pas tout, c'est un morceau indispensable du puzzle, mais pour que l'application fonctionne, il faut beaucoup plus, notamment du stockage local, etc ... 

Par exemple, mon idée est que si l'appli est offline, les opérations (de modifications de données) sont stockées localement puis dépilées vers le serveur dès que la connexion est rétablie. Et alors viennent les questions :

- quel stockage ? LocalStorage ou IndexedDB proposée par HTML5 ? Autre ?

- comment les utiliser ? en direct ? avec des sur-couches s'il ne existe (type lawnchair ou autre) ?

- comme "dépiler" les données au retour de la connexion ? Faut-il le faire "à la main" ou existerait-il déjà des solutions ? 

- etc ...

 

Pour ce qui est des applications, tu as quand même du lourd avec les applications des chez Google:
http://techcrunch.com/2011/08/31/googles-new-html5-chrome-apps-for-gmail-calendar-and-docs-give-users-offline-access/

Oui, mais cette solution, si je ne me trompe pas, se base sur les applis Chrome, donc spécifique à ce navigateur ...

Xavier

[Jocelyn Lecomte]

Effectivement, le cache offline n'est pas là pour faire du stockage de données côté client, mais pour permettre que l'application survive à une déconnexion. Tu connais visiblement les alternatives actuelles pour le stockage de données:

• Web Storage: simple stockage clé/valeur. Pas de requêtage possible.
  
• WebSQL: API morte-née qui ambitionnait de transformer en SGBD le navigateur, avec du bon SQL pour requêter. Je pense que l'on peut déjà l'écarter si on souhaite écrire un truc pérenne...
• Indexed Database: ici l'idée est de gérer une base de données dans laquelle on stocke des objets JS, que l'on peut ensuite retrouver en requêtant des propriétés. La notion de transaction est présente. Et effectivement, l'API est encore très jeune donc sujette à de nombreux changements, voire pire :)

Concrètement, je me vois mal écrire une application pour un client en utilisant autre chose que Web Storage pour l'instant (sauf à avoir prévenu le client de ce qui lui pend au nez). Et cette API est tellement simple que je ne vois pas l'intérêt d'une surcouche.
Pour ce qui est des problématiques de synchronisation des données entre le client et le serveur, il n'existe pas à ma connaissance d'autre moyen que de le gérer toi-même. Tu peux alle voir cette démo qui démontre sur un exemple simple (des todos) ce genre de synchronisation.

[Xavier NOPRE]

Salut Jocelyn,

Effectivement, le cache offline n'est pas là pour faire du stockage de données côté client, mais pour permettre que l'application survive à une déconnexion.

C'est néanmoins une brique indispensable !
 

Concrètement, je me vois mal écrire une application pour un client en utilisant autre chose que Web Storage pour l'instant (sauf à avoir prévenu le client de ce qui lui pend au nez). Et cette API est tellement simple que je ne vois pas l'intérêt d'une surcouche.

Effectivement, ce qui peut inquiéter, c'est la "jeunesse" de tout cela. Pourtant IndexedDB est pas mal du tout, et permet pas mal de chose en plus par rapport à LocalStorage, notamment les recherches avec le systèem d'index, etc ... Mais c'est clair, il faut voir de quoi on a besoin au cas par cas, dans le mien, le WEB storage peut suffire ...

Pour la surcouche, tout dépend là aussi des besoin, mais ça peut être intéressant. Il y a Lanwchair par exemple (non testé) qui semble abstraire le type de stockage.
 

Pour ce qui est des problématiques de synchronisation des données entre le client et le serveur, il n'existe pas à ma connaissance d'autre moyen que de le gérer toi-même. Tu peux alle voir cette démo qui démontre sur un exemple simple (des todos) ce genre de synchronisation.

Je vais voir cette démo de suite !
Pour la synchro, j'entends parler de solution à base de CouchDB mais je ne vois pas du tout comment ça peut s'articuler, en quoi ça consisterait ...... ?


Xavier

[Alexandre Ardhuin]

Pour la question du local storage, il y a un article intéressant paru récemment : http://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/

Alexandre.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[ehsavoie]

On vient de me pousser ca :
http://arandomurl.com/2012/03/27/pouchdb-is-couchdb-in-the-browser.html
via mon pingouin.

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

[Jocelyn Lecomte]

@Alexandre
Mouais. Se méfier des articles écrits sous la frustration du moment. Je note que l'auteur reste dans le vague et ne donne pas de benchmarks. Reste évidemment qu'on ne peut pas faire n'importe quoi avec Web Storage, envisager de stocker des milliers d'images dans une map clé - valeur est du suicide là comme ailleurs. There is no golden hammer...
@Emmanuel
Merci pour le lien, c'est intéressant de voir (déjà) des surcouches d'IndexedDb apparaitre. A suivre.

[Patrice Trognon]

Le 28 mars 2012 à 09:31, Jocelyn Lecomte a écrit :

@Alexandre
Mouais. Se méfier des articles écrits sous la frustration du moment. Je note que l'auteur reste dans le vague et ne donne pas de benchmarks. Reste évidemment qu'on ne peut pas faire n'importe quoi avec Web Storage, envisager de stocker des milliers d'images dans une map clé - valeur est du suicide là comme ailleurs. There is no golden hammer...

je n'ai rien dit pour pas passer pour le râleur de service une fois de plus.

mais +1000.

Par contre je me marre bien :)

Pat

[Nicolas Labrot]

Les commentaires du post sont eux même très parlant et semblent consensuels sur le fait que localstorage est limité sur les perfs.

Si même sur des milliers d'entrées d'une simple datatable les perfs en lecture sont minables l’intérêt s'en trouve très limité. Ca manque certes de chiffre...

2012/3/28 Patrice Trognon <ptro...@gmail.com>

[Patrice Trognon]

c'est surtout que je lis ce thread a la lumière d'une précédente discussion sur l'utilisation du mode web dans

les applies mobiles, et je me dis que le natif a encore de beaux jours devant lui :)

bref, totalement conforté dans mes choix de ces dernières années.

Pat

[Nicolas Labrot]

Justement non, JavaFX va sauver le monde!! :D

2012/3/28 Patrice Trognon <ptro...@gmail.com>

[Patrice Trognon]

hehe :)

Tu vois, amha le web, tout ce qu'on a vécu autour du web ces dernières années, ce qui était intéressant

c'était le fait de bénéficier d'un stockage de l'information centralisé et plusieurs moyens pour consommer

cette information, en opposition a des applies workstation qui ont leurs datas en local (word).

Coté centralisation des données, c'est top.

Par contre coté UI mon dieu quelle horreur, aucune techno ne s'est imposée pour l'UI sur le web depuis

qu'il existe parce que aucune techno client n'est un aboutissement en sois, elles sont toutes aussi

merdique les uns des autres. Et cela continue.

Aujourd'hui on a le cloud qui se développe de plus en plus, c'est quoi le cloud si ce n'est un anti-web,

tu peux stocker toutes tes données et les rendre accessible de n'importe quelle application, bref cela

va répondre en mieux a la problématique de centralisation de l'information.

Donc pourquoi garder le web ? Pourquoi se coltiner ces technos a coucher dehors totalement incompatible

d'un navigateur à l'autre ou d'une version a l'autre ?

On va enfin revenir a du vrai développement d'UI et nos UI 'natives' consommeront des données venant du

cloud.

je dis 'natives' entre quotes parce qu'une UI Java, disons Swing aujourd'hui, je la qualifie de 'native' en

opposition a 'web', native parce que je peux inter agir avec le window-manager de mon ordi quel qu'il

soit. Chez moi natif va devenir du Cocoa, chez toi du iLog, Qt, ou du Swing ou du Flex, que sais-je et 

peu importe.

Java se retrouve avec une vrai carte à jouer dans ce modèle, est ce que la solution est dans JavaFX je ne sais

pas, ne le codant pas je ne vais pas le juger. Mais que diable il faut une API d'UI en Java qui s'impose pour

les applies workstation de demain, parce que les jours du web remplaçant les applies workstation sont

comptés je pense (je l'espère en fait).

Je suis en train de coder du iCloud et du DropBox dans des applies de test pour voir, et franchement

c'est une tuerie, le coté de l'UI qui se refresh toute seule parce que le daemon de synchro a détecté

une mise à jour moi j'adore, par contre par les APIs de DropBox c'est un peu plus poillu vu qu'il

n'y a pas de daemon de synchro qui vient de réveiller si un fichier à été mis à jour.

Du reste le problème vient justement de cette notion de 'fichier' qui est à oublier et à remplacer

par une notion de document, un document cela se manipule dans un contexte cloud, un fichier 

c'est déjà beaucoup plus chaud car trop terre à terre.

Dans le monde parfait selon Pat il y aura des services web renvoyant de la data (REST), et

des applies 'natives' consommant ces services en partie pour s'alimenter, et utilisant du cloud

pour d'autres types de données, les documents.

Et exit les technos web coté client qui sont toutes a poubeliser.

Voili voilou, bref, j'ai un peu splitté la discussion.

Pat

[Patrice Trognon]

Yannick s'est emberlificoté avec son client mail et m'a répondu en direct,
je fais mes réponses a son mail ainsi il revient dans la liste :)
Le 28 mars 2012 à 14:03, Yannick Grenzinger a écrit :

> Que les applis natives soit plus performantes et plus "simples" à
> coder ok.
> Mais dire qu'elles sont vont remplacer les applis "web" (et qu'est ce
> qu'une appli web ? j'imagine qu'on parle du duo html 5 / javascript),
> y a vraiment un fossé que je ne m'amuserait pas à franchir même sur
> les cast trolleurs du vendredi :)
>

ah la la je poussais le trait bien sur.
Evidement les applies web ne vont pas disparaitre, je ne suis pas naïf
à ce point la.
Seulement aujourd'hui et depuis quelques années le mode web au niveau
UI me semble être la seule réponse toute prête a tous les problèmes
informatiques, alors que du natif permettrait d'y répondre plus proprement,
pour exemple un grand nombre des applies développées en interne
dans les entreprises en fait, sans reffléchir les reponsables partent sur
du web parce que c'est LA réponse à la mode.
Pour moi le frein pour qu'on se pose la question était le stockage, celui
ci étant solutionné autrement par le cloud il me semble légitime dans
les mois/années a venir qu'on se pose une minute la question :
est ce que une UI web est forcement la bonne réponse au problème posé.

Ceci étant dit je pense que Sun, pardon oracle j'ai encore du mal, devrait
mettre un peu plus le paquet sur un approche UI 'native' exploitant
un stockage cloud avec daemon de synchronisation, c'est à dire allant
un peu plus loin que DropBox qui reste assez basique comme cloud.

> Déjà les applis web avec les bons outils ça aide. Le meilleur exemple
> a mes yeux est Coffeescript qui peut tranquillement prendre la main
> sur JS.
> Puis il suffit d'aller voir ce qui se fait dans les démos HTML 5 pour
> se dire que les possibilités sont la.
> Deuxio l'apparition d'OS qui ne sont pratiquement plus qu'un
> navigateur : Chrome OS, Jolicloud, Windows 8 (?).
>
> J'ai vu du Swing, du Qt (et même WxWindows), du GWT, du Flex, du
> Wicket, du HTML/Jquery, de l'Android, du Cocoa iPhone (qui ne te
> permet rien en dehors des UI typées Apple) ... conclusion il n'y a pas
> de techno miracle. Par exemple impossible de sortir certaines UI qu'on
> trouve sur le web sur de l'iPhone.
>

+1, c'est juste la mono-réponse web qui me dérange depuis le début.

> C'est le drame de notre métier, on a des tonnes de problématiques, des
> tonnes de solutions pour chaque problématique et chaque solution a ses
> pièges. A nous de trouver la bonne.
>
> En fait j'y pense on a une possibilité de faire que de l'appli Native
> mais on l'a raté quand on a pas confirmé le monopole de Windows :D
> Rien que le nombre de plateforme à gérer laisse beaucoup de place à
> des solutions multiplateforme comme Java ou les applis "Web" html 5/
> JS.
>

et c'est moi qui troll ? :)

> Yannick

>>> 2012/3/28 Patrice Trognon <ptrog...@gmail.com>

>>> c'est surtout que je lis ce thread a la lumière d'une précédente discussion sur l'utilisation du mode web dans
>>> les applies mobiles, et je me dis que le natif a encore de beaux jours devant lui :)
>>
>>> bref, totalement conforté dans mes choix de ces dernières années.
>>
>>> Pat
>>
>>> Le 28 mars 2012 à 13:08, Nicolas Labrot a écrit :
>>
>>>> Les commentaires du post sont eux même très parlant et semblent consensuels sur le fait que localstorage est limité sur les perfs.
>>
>>>> Si même sur des milliers d'entrées d'une simple datatable les perfs en lecture sont minables l’intérêt s'en trouve très limité. Ca manque certes de chiffre...
>>

>>>> 2012/3/28 Patrice Trognon <ptrog...@gmail.com>

>>
>>>> Le 28 mars 2012 à 09:31, Jocelyn Lecomte a écrit :
>>
>>>>> @Alexandre
>>>>> Mouais. Se méfier des articles écrits sous la frustration du moment. Je note que l'auteur reste dans le vague et ne donne pas de benchmarks. Reste évidemment qu'on ne peut pas faire n'importe quoi avec Web Storage, envisager de stocker des milliers d'images dans une map clé - valeur est du suicide là comme ailleurs. There is no golden hammer...
>>
>>>> je n'ai rien dit pour pas passer pour le râleur de service une fois de plus.
>>>> mais +1000.
>>
>>>> Par contre je me marre bien :)
>>
>>>> Pat
>>
>>>>> @Emmanuel
>>>>> Merci pour le lien, c'est intéressant de voir (déjà) des surcouches d'IndexedDb apparaitre. A suivre.
>>

>>>>> Le 27 mars 2012 09:05, Alexandre Ardhuin <alexandre.ardh...@gmail.com> a écrit :
>>>>> Pour la question du local storage, il y a un article intéressant paru récemment :http://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-loca...

>>
>>>>> Alexandre.
>>
>>>>> Le 25 mars 2012 10:45, Xavier NOPRE <xno...@gmail.com> a écrit :
>>
>>>>> Salut Jocelyn,
>>
>>>>> Merci pour ta réponse,
>>
>>>>> Le cache offline est supporté par firefox depuis la version 3.5.
>>
>>>>> Oui, j'ai "joué" avec (d'ailleurs surprenant, attention les effets de bords ...), mais un cache de pages, ça ne fait pas tout, c'est un morceau indispensable du puzzle, mais pour que l'application fonctionne, il faut beaucoup plus, notamment du stockage local, etc ...
>>
>>>>> Par exemple, mon idée est que si l'appli est offline, les opérations (de modifications de données) sont stockées localement puis dépilées vers le serveur dès que la connexion est rétablie. Et alors viennent les questions :
>>>>> - quel stockage ? LocalStorage ou IndexedDB proposée par HTML5 ? Autre ?
>>>>> - comment les utiliser ? en direct ? avec des sur-couches s'il ne existe (type lawnchair ou autre) ?
>>>>> - comme "dépiler" les données au retour de la connexion ? Faut-il le faire "à la main" ou existerait-il déjà des solutions ?
>>>>> - etc ...
>>
>>>>> Pour ce qui est des applications, tu as quand même du lourd avec les applications des chez Google:

>>>>> http://techcrunch.com/2011/08/31/googles-new-html5-chrome-apps-for-gm...

[Yannick Grenzinger]

Merci Patrice :)

> ...
>
> read more »

[Nicolas Labrot]

2012/3/28 Patrice Trognon <ptro...@gmail.com>

hehe :)

Tu vois, amha le web, tout ce qu'on a vécu autour du web ces dernières années, ce qui était intéressant

c'était le fait de bénéficier d'un stockage de l'information centralisé et plusieurs moyens pour consommer

cette information, en opposition a des applies workstation qui ont leurs datas en local (word).

Coté centralisation des données, c'est top.

Par contre coté UI mon dieu quelle horreur, aucune techno ne s'est imposée pour l'UI sur le web depuis

qu'il existe parce que aucune techno client n'est un aboutissement en sois, elles sont toutes aussi

merdique les uns des autres. Et cela continue.

L'explication n'est elle pas plutôt à chercher sur le fait qu'in fine le couple HTML + JS est imba parce que justement suffisamment bas niveau pour permettre une liberté et une customisation poussée ?
Toutes technos UI tentant d'abstraire un tant soit peu imposent des limites et des contraintes à ce modèle. En ce sens JQuery est je pense l'exemple type d'une abstraction réussie. Développer un composant Swing n'est pas une partie de plaisir. En HTML + JS avec JQuery c'est autre chose...

Le HTML5 c'est quoi ? du "HTML standard", du SVG, du WebGL, de la video, du canvas ainsi que du JS. Quelle techno native peut se targer de gérer ce panel de fonctionnalités dans un même canevas d'affichage ?
 
 

Aujourd'hui on a le cloud qui se développe de plus en plus, c'est quoi le cloud si ce n'est un anti-web,

tu peux stocker toutes tes données et les rendre accessible de n'importe quelle application, bref cela

va répondre en mieux a la problématique de centralisation de l'information.

Donc pourquoi garder le web ? Pourquoi se coltiner ces technos a coucher dehors totalement incompatible

d'un navigateur à l'autre ou d'une version a l'autre ?

On va enfin revenir a du vrai développement d'UI et nos UI 'natives' consommeront des données venant du

cloud.

je dis 'natives' entre quotes parce qu'une UI Java, disons Swing aujourd'hui, je la qualifie de 'native' en

opposition a 'web', native parce que je peux inter agir avec le window-manager de mon ordi quel qu'il

soit. Chez moi natif va devenir du Cocoa, chez toi du iLog, Qt, ou du Swing ou du Flex, que sais-je et 

peu importe.

L'aspect natif ne me semble pas le cœur de la problématique. Le couple HTML+JS pourrait très bien interagir avec un window-manager ou plus simplement disposer d’événement spécifique au plateforme mobile.. Le coeur de la problème est plutôt à chercher sur la difficulté des "géant" du web à se mettre d'accord sur des standards ainsi qu'a surement leurs absences de volonté car n'entrant pas ou allant contre leurs business plan.
 

[Patrice Trognon]

Le 28 mars 2012 à 22:23, Nicolas Labrot a écrit :

2012/3/28 Patrice Trognon <ptro...@gmail.com>

hehe :)

Tu vois, amha le web, tout ce qu'on a vécu autour du web ces dernières années, ce qui était intéressant

c'était le fait de bénéficier d'un stockage de l'information centralisé et plusieurs moyens pour consommer

cette information, en opposition a des applies workstation qui ont leurs datas en local (word).

Coté centralisation des données, c'est top.

Par contre coté UI mon dieu quelle horreur, aucune techno ne s'est imposée pour l'UI sur le web depuis

qu'il existe parce que aucune techno client n'est un aboutissement en sois, elles sont toutes aussi

merdique les uns des autres. Et cela continue.

L'explication n'est elle pas plutôt à chercher sur le fait qu'in fine le couple HTML + JS est imba parce que justement suffisamment bas niveau pour permettre une liberté et une customisation poussée ?
Toutes technos UI tentant d'abstraire un tant soit peu imposent des limites et des contraintes à ce modèle. En ce sens JQuery est je pense l'exemple type d'une abstraction réussie. Développer un composant Swing n'est pas une partie de plaisir. En HTML + JS avec JQuery c'est autre chose...

Le HTML5 c'est quoi ? du "HTML standard", du SVG, du WebGL, de la video, du canvas ainsi que du JS. Quelle techno native peut se targer de gérer ce panel de fonctionnalités dans un même canevas d'affichage ?
 

vraiment bof, c'est l'arlésienne.

un pote me disait justement que les tps qu'il avait préparé pour html-5 ne fonctionnaient plus aussi bien sur les versions

plus récentes des navigateurs.

on a sans arrêt l'impression de revenir 10 ans en arrière avec les éternels problèmes de portabilité entre les

navigateurs / os.

La programmation swing, pour rester dans un exemple plus proche de cette ml mais je pourrai aussi dire

la même chose de la programmation Qt ou Cocoa, n'est pas si compliquée que cela si on veut prendre

la peine de rentrer dedans. Le ticket d'entrée dans un Swing, ou like, me semble bien moins élevé que

celui dans les innombrables technos web clientes, et surtout bien plus pérenne. comme je l'ai souvent dit

on n'en a que faire du dernier framework web qui sera remplacé dans 6 mois par le dernier des derniers

qui va tout tuer.

Je vois bien plus de stabilité dans une approche swing-like, peut être javaFx2 pas moi l'expert dessus, que

dans les approches pure web.

Ils vont mettre combien de temps a standardiser html-5. Ah oui les pocs sont magnifiques, en effet c'est

à tomber par terre, seulement fonctionnent ils aussi bien quand le navigateur évolue en l'absence

de vrai standard ?

Alors ensuite pour répondre a ta dernière remarque au dessus, pris simplement au rebond, de la visualisation

HTML + moteur JS + de la vidéo + un layer openGL, désolé mais Qt le fait, Cocoa aussi. Swing non tu vas me

dire mais forcement il n'y a pas eu d'effort de développement effectué dessus depuis un sacré bout de temps

par sun/oracle. 

Ensuite html-5 le fait comment ? de façon standard ? il ne me semble pas voir au dessus.

Bon aller, j'arrête.

Je ne rejette pas en bloc html-5, il a sa raison d'être, je pense juste que se jeter directement sur du tout web

ne me semble plus une si bonne idée maintenant, et que dans l'avenir il va falloir commencer a penser

un peu autrement car le 'natif' comme je l'appelais en opposition au tout web va revenir en force.

Et c'est a mon avis une très bonne chose.

Pat

 

Aujourd'hui on a le cloud qui se développe de plus en plus, c'est quoi le cloud si ce n'est un anti-web,

tu peux stocker toutes tes données et les rendre accessible de n'importe quelle application, bref cela

va répondre en mieux a la problématique de centralisation de l'information.

Donc pourquoi garder le web ? Pourquoi se coltiner ces technos a coucher dehors totalement incompatible

d'un navigateur à l'autre ou d'une version a l'autre ?

On va enfin revenir a du vrai développement d'UI et nos UI 'natives' consommeront des données venant du

cloud.

je dis 'natives' entre quotes parce qu'une UI Java, disons Swing aujourd'hui, je la qualifie de 'native' en

opposition a 'web', native parce que je peux inter agir avec le window-manager de mon ordi quel qu'il

soit. Chez moi natif va devenir du Cocoa, chez toi du iLog, Qt, ou du Swing ou du Flex, que sais-je et 

peu importe.

L'aspect natif ne me semble pas le cœur de la problématique. Le couple HTML+JS pourrait très bien interagir avec un window-manager ou plus simplement disposer d’événement spécifique au plateforme mobile.. Le coeur de la problème est plutôt à chercher sur la difficulté des "géant" du web à se mettre d'accord sur des standards ainsi qu'a surement leurs absences de volonté car n'entrant pas ou allant contre leurs business plan.
 

[Nicolas Labrot]

L'explication n'est elle pas plutôt à chercher sur le fait qu'in fine le couple HTML + JS est imba parce que justement suffisamment bas niveau pour permettre une liberté et une customisation poussée ?
Toutes technos UI tentant d'abstraire un tant soit peu imposent des limites et des contraintes à ce modèle. En ce sens JQuery est je pense l'exemple type d'une abstraction réussie. Développer un composant Swing n'est pas une partie de plaisir. En HTML + JS avec JQuery c'est autre chose...

Le HTML5 c'est quoi ? du "HTML standard", du SVG, du WebGL, de la video, du canvas ainsi que du JS. Quelle techno native peut se targer de gérer ce panel de fonctionnalités dans un même canevas d'affichage ?
 

vraiment bof, c'est l'arlésienne.

un pote me disait justement que les tps qu'il avait préparé pour html-5 ne fonctionnaient plus aussi bien sur les versions

plus récentes des navigateurs.

on a sans arrêt l'impression de revenir 10 ans en arrière avec les éternels problèmes de portabilité entre les

navigateurs / os.

Et ce n'est pas le cas avec les montées de version iOS / Android ?

N'utilisant pas les features du HTML5 je peux difficilement répondre. Hors HTML5 je rencontre rarement de problème sur les montées de version des navigateurs.

 

La programmation swing, pour rester dans un exemple plus proche de cette ml mais je pourrai aussi dire

la même chose de la programmation Qt ou Cocoa, n'est pas si compliquée que cela si on veut prendre

la peine de rentrer dedans. Le ticket d'entrée dans un Swing, ou like, me semble bien moins élevé que

celui dans les innombrables technos web clientes, et surtout bien plus pérenne. comme je l'ai souvent dit

on n'en a que faire du dernier framework web qui sera remplacé dans 6 mois par le dernier des derniers

qui va tout tuer.

Je vois bien plus de stabilité dans une approche swing-like, peut être javaFx2 pas moi l'expert dessus, que

dans les approches pure web.

Ils vont mettre combien de temps a standardiser html-5. Ah oui les pocs sont magnifiques, en effet c'est

à tomber par terre, seulement fonctionnent ils aussi bien quand le navigateur évolue en l'absence

de vrai standard ?

Alors ensuite pour répondre a ta dernière remarque au dessus, pris simplement au rebond, de la visualisation

HTML + moteur JS + de la vidéo + un layer openGL, désolé mais Qt le fait, Cocoa aussi. Swing non tu vas me

dire mais forcement il n'y a pas eu d'effort de développement effectué dessus depuis un sacré bout de temps

par sun/oracle. 

Aucun de ceux que tu cites ne le font avec une approche aussi intégrée.

 

Ensuite html-5 le fait comment ? de façon standard ? il ne me semble pas voir au dessus.

Sur beaucoup de choses oui sur d'autre non et c'est le problème.

 

Bon aller, j'arrête.

Je ne rejette pas en bloc html-5, il a sa raison d'être, je pense juste que se jeter directement sur du tout web

ne me semble plus une si bonne idée maintenant, et que dans l'avenir il va falloir commencer a penser

un peu autrement car le 'natif' comme je l'appelais en opposition au tout web va revenir en force.

Et c'est a mon avis une très bonne chose.

Mon job c'est de choisir la meilleur techno pour un besoin donné. Si a un instant T c'est du natif, amen!

 

[Patrice Trognon]

Le 28 mars 2012 à 22:58, Nicolas Labrot <nit...@gmail.com> a écrit :

L'explication n'est elle pas plutôt à chercher sur le fait qu'in fine le couple HTML + JS est imba parce que justement suffisamment bas niveau pour permettre une liberté et une customisation poussée ?
Toutes technos UI tentant d'abstraire un tant soit peu imposent des limites et des contraintes à ce modèle. En ce sens JQuery est je pense l'exemple type d'une abstraction réussie. Développer un composant Swing n'est pas une partie de plaisir. En HTML + JS avec JQuery c'est autre chose...

Le HTML5 c'est quoi ? du "HTML standard", du SVG, du WebGL, de la video, du canvas ainsi que du JS. Quelle techno native peut se targer de gérer ce panel de fonctionnalités dans un même canevas d'affichage ?
 

vraiment bof, c'est l'arlésienne.

un pote me disait justement que les tps qu'il avait préparé pour html-5 ne fonctionnaient plus aussi bien sur les versions

plus récentes des navigateurs.

on a sans arrêt l'impression de revenir 10 ans en arrière avec les éternels problèmes de portabilité entre les

navigateurs / os.

Et ce n'est pas le cas avec les montées de version iOS / Android ?

iOS non.

Androïd pas moi l'expert je refuse d'y toucher question de religion.

Ah, je vais bien dormir grâce à cette remarque. 

Un peu plus d'ouverture ne peut que aller dans le positif.

C'est justement le choix dogmatique que je fustige, ma critique de html n'est qu'un moyen, en sois html je m'en contre fiche.

[Jerome Velociter]

Le mercredi 28 mars 2012 13:37:28 UTC+2, Patrice Trognon a écrit :

hehe :)

Tu vois, amha le web, tout ce qu'on a vécu autour du web ces dernières années, ce qui était intéressant

c'était le fait de bénéficier d'un stockage de l'information centralisé et plusieurs moyens pour consommer

cette information, en opposition a des applies workstation qui ont leurs datas en local (word).

Coté centralisation des données, c'est top.

Par contre coté UI mon dieu quelle horreur, aucune techno ne s'est imposée pour l'UI sur le web depuis

qu'il existe parce que aucune techno client n'est un aboutissement en sois, elles sont toutes aussi

merdique les uns des autres. Et cela continue.

Aujourd'hui on a le cloud qui se développe de plus en plus, c'est quoi le cloud si ce n'est un anti-web,

tu peux stocker toutes tes données et les rendre accessible de n'importe quelle application, bref cela

va répondre en mieux a la problématique de centralisation de l'information.

Donc pourquoi garder le web ? Pourquoi se coltiner ces technos a coucher dehors totalement incompatible

d'un navigateur à l'autre ou d'une version a l'autre ?

On va enfin revenir a du vrai développement d'UI et nos UI 'natives' consommeront des données venant du

cloud.

je dis 'natives' entre quotes parce qu'une UI Java, disons Swing aujourd'hui, je la qualifie de 'native' en

opposition a 'web', native parce que je peux inter agir avec le window-manager de mon ordi quel qu'il

soit. Chez moi natif va devenir du Cocoa, chez toi du iLog, Qt, ou du Swing ou du Flex, que sais-je et 

peu importe.

Perso j'entrevois aussi un futur ou pas mal d'applis desktop seront des hybrides web/natif, ou tu réalise tes UI avec les standards du Web et que tu enrobe dans un wrapper a la phonegap (pardon, il faut dire apache cordava maintenant). D'ailleurs je viens de le découvrir : il à déjà un wrapper pour Mac OS https://github.com/apache/incubator-cordova-mac chez cordava. Titanium fait la même chose (http://www.appcelerator.com/products/titanium-desktop-application-development/), et je serais pas surpris de voir de plus en plus d'initiatives dans ce sens. Autre fait intéressant: l'UI de Skype 5 sous mac est réalisée avec une approche de ce type, la raison officielle étant que c'est pour faire une UI plus facilement "skinnable".

Je vois pas mal d'avantages à cette approche en fait. La première, c'est qu'on a le meilleur des deux mondes : du "vrai natif" et du web sans les problèmes d'interopérabilité (puisque c'est un webkit qu'on connait à l'avance derrière) ; la seconde, c'est que ça simplifie quand même vachement le boulot d'UI, et amène la flexibilité du web, qui permet de faire des choses formidables assez simplement.

Bien sur cette approche ne correspond évidemment pas à tout les scénarios, il y a plein de bonnes raisons de vouloir faire autre chose, mais pour les applis "de base" qui ne font que consommer/publier de la data venant de l'exterieur, je suis personnellement assez convaincu.

Jerome

2012/3/28 Patrice Trognon <ptro...@gmail.com>

2012/3/28 Patrice Trognon <ptro...@gmail.com>

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Patrice Trognon]

Le 29 mars 2012 à 13:13, Jerome Velociter a écrit :

Le mercredi 28 mars 2012 13:37:28 UTC+2, Patrice Trognon a écrit :

hehe :)

Tu vois, amha le web, tout ce qu'on a vécu autour du web ces dernières années, ce qui était intéressant

c'était le fait de bénéficier d'un stockage de l'information centralisé et plusieurs moyens pour consommer

cette information, en opposition a des applies workstation qui ont leurs datas en local (word).

Coté centralisation des données, c'est top.

Par contre coté UI mon dieu quelle horreur, aucune techno ne s'est imposée pour l'UI sur le web depuis

qu'il existe parce que aucune techno client n'est un aboutissement en sois, elles sont toutes aussi

merdique les uns des autres. Et cela continue.

Aujourd'hui on a le cloud qui se développe de plus en plus, c'est quoi le cloud si ce n'est un anti-web,

tu peux stocker toutes tes données et les rendre accessible de n'importe quelle application, bref cela

va répondre en mieux a la problématique de centralisation de l'information.

Donc pourquoi garder le web ? Pourquoi se coltiner ces technos a coucher dehors totalement incompatible

d'un navigateur à l'autre ou d'une version a l'autre ?

On va enfin revenir a du vrai développement d'UI et nos UI 'natives' consommeront des données venant du

cloud.

je dis 'natives' entre quotes parce qu'une UI Java, disons Swing aujourd'hui, je la qualifie de 'native' en

opposition a 'web', native parce que je peux inter agir avec le window-manager de mon ordi quel qu'il

soit. Chez moi natif va devenir du Cocoa, chez toi du iLog, Qt, ou du Swing ou du Flex, que sais-je et 

peu importe.

Perso j'entrevois aussi un futur ou pas mal d'applis desktop seront des hybrides web/natif, ou tu réalise tes UI avec les standards du Web et que tu enrobe dans un wrapper a la phonegap (pardon, il faut dire apache cordava maintenant). D'ailleurs je viens de le découvrir : il à déjà un wrapper pour Mac OS https://github.com/apache/incubator-cordova-mac chez cordava. Titanium fait la même chose (http://www.appcelerator.com/products/titanium-desktop-application-development/), et je serais pas surpris de voir de plus en plus d'initiatives dans ce sens. Autre fait intéressant: l'UI de Skype 5 sous mac est réalisée avec une approche de ce type, la raison officielle étant que c'est pour faire une UI plus facilement "skinnable".

Je vois pas mal d'avantages à cette approche en fait. La première, c'est qu'on a le meilleur des deux mondes : du "vrai natif" et du web sans les problèmes d'interopérabilité (puisque c'est un webkit qu'on connait à l'avance derrière) ; la seconde, c'est que ça simplifie quand même vachement le boulot d'UI, et amène la flexibilité du web, qui permet de faire des choses formidables assez simplement.

mouaih, ces approches d'unification j'ai plutôt tendance a penser qu'elles sont le pire des deux mondes, du moins le plus petit dénominateur commun.

L'effet démo de ces outils est toujours très impressionnant, dès que tu veux l'utiliser vraiment faut sacrément rester dans leurs jalons si tu cherches

à en sortir tu commences a souffrir. donc quelque part tu en viens à devoir sacrifier les features pour éviter les pièges.

Pat

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/OAqprM8jDFUJ.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Xavier NOPRE]

Salut Emmanuel,

On vient de me pousser ca :
http://arandomurl.com/2012/03/27/pouchdb-is-couchdb-in-the-browser.html

Merci pour le lien, je vais regarder à l'occasion ...

Xavier
 

[Jerome Velociter]

Bof c'est pas tellement vrai. Phonegap te dis pas comment tu dois coder ton appli. D'ailleurs ils n'ont pas inventé le fait d'embarquer une webview, des développeurs faisait déjà ça avant que phonegap n'apparaisse. Eux t'apportent juste les API pour pouvoir exploiter les fonctions du téléphone depuis ton webkit. Mais il te forcent pas a faire 100% webview, tu peux mettre le curseur ou tu veux.

En fait ce que je veux dire pas meilleur des deux mondes, c'est :

* Du coté natif, c'est "du vrai natif" (par opposition a Java par ex.), et pour moi ca veux surtout dire un chrome de l'appli qui est bien intégré à l'OS, pouvoir exploiter des fonctions type système de notification, la possiblité d'aller distribuer sur les app store (d'après ce que je comprends ca n'est pas possible pour une app Java sur le store mac OS - mais je peux me tromper).

* Du coté web, c'est juste un webkit. Donc tu connais à l'avance les limitations, les problèmes, les APIs supportées, etc. (et d'ailleurs je trouve les problèmes de compatibilité en général un peu exagérés - au delà de IE6/IE7 bien sûr mais qui les supporte encore ?)

Bon après bien sur ca veux pas dire qu'il n'y a pas de problèmes, que ca conviens à tous les développeurs ou pour toutes les applis. Mais c'est pareil pour tout c'est un compromis à faire ou à ne pas faire en fonction de la situation, des gens, etc.

Adobe ne s'y est pas trompé en rachetant Nitobi, ils ont compris que le futur des runtimes du type AIR ca passait quand même par les technologies du web. Maintenant le run-time c'est webkit.

Aussi, je serais pas surpris si le jour ou Facebook sort un client lourd (si d'aventure ils le font), ça soit sur basé sur ce type de paradigme ; vu leur investissement dans HMTL5 pour les mobiles.

Jerome

[Thierry Chatel]

Ah, une discussion sur le mode déconnecté qui a dérivé sur un débat, intéressant lui aussi, applis natives contre applis web.

Pour avoir fait pas mal de Swing mais il y a longtemps, et depuis quasiment que de l'appli web, j'aime bien le côté design déclaratif de HTML, et beaucoup moins à peu près tous ses autres aspects qui en font une plate-forme pas du tout pensée pour faire de l'applicatif. J'aurais aimé avoir JavaFX quand je faisais du Swing il y a 10 ans, mais je pense qu'il est arrivé trop tard et trop buggé dans ses premières release pour connaître un jour le succès. En sur le web quand je touche aux CSS je regrette souvent la souplesse d'un bon vieux GridBagLayout.

Mais j'ai découvert il y a quelques mois le framework AngularJS et c'est certainement ce que j'ai vu de mieux toutes technos confondues pour faire un client riche avec des vues déclaratives, un code super concis, entièrement et très facilement testable (tests unitaires et scénarios de tests end-to-end), le tout par un système de data-binding bidirectionnel qui fait que les vues sont synchronisées automatiquement et en permanence sur les données du modèle, et que les contrôleurs n'interviennent que sur le modèle sans avoir aucune connaissance de la vue.

Alors évidemment ça reste de l'appli web avec un look web et pas natif, mais à mon avis ça repousse largement les limites de la productivité des développeurs sur du client applicatif. Attention par contre pour ceux qui voudraient faire plus qu'en regarder les concepts, le site angularjs.org présente encore la version beta 0.9, et il y a beaucoup de différences avec la première version finale qui doit sortir dans les prochaines semaines. Les docs de la version 1.0 (actuellement en release candidate) sont là : http://docs-next.angularjs.org/misc/started  par contre le tutoriel super bien fait de la version 0.9 est en cours de réécriture, et n'est pas encore dispo pour la 1.0.

[Xavier NOPRE]

Bonjour Thierry,

Merci pour ce partage, je ne connaissais pas AngularJS.

L'aurais-tu comparé à d'autres framework MVC JS, comme Backbone.js par exemple ? Ou d'autres ?

La foultitude de framework MVC en JS est intéressante, mais ne facile pas le "bon" choix pour le développeur ....

Xavier

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/S9Jxy9XmkKQJ.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Olivier Lamy]

Salut,
Perso j'utilise knockout depuis quelques temps et en suis bien content :-).
Il y a quelques temps quelqu'un avait posté
(https://groups.google.com/d/topic/lescastcodeurs/tlXjtQ2LjQU/discussion)
un lien vers un comparatif intéressant
(http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
)
IMHO un framework avec du data(ui)-binding facilite grandement la vie !

Backbone n'a pas celà. Mais knockback le nom veut tout dire :-) oui
(http://kmalakoff.github.com/knockback/ )

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

[Thierry Chatel]

J'ai utilisé AngularJS de façon assez approfondie ces derniers mois pour une appli perso, mais c'est le seul framework JS que j'ai utilisé, donc je ne peux pas faire de comparaison d'expérience avec les autres.

Mais je sais pourquoi j'ai choisi AngularJS, et quels sont pour moi ses principaux avantages, et en quoi je le trouve vraiment bluffant :

- le niveau d'abstraction du framework est celui d'une application web, on écrit juste la logique de présentation, sans faire de manipulations de DOM ni gérer des événements, le code à écrire est très bref

- les templates sont déclaratifs, c'est du HTML auquel on ajoute des directives pour le binding

- le binding est bi-directionnel, c'est de la "live view" : un changement dans le modèle est reflété automatiquement dans la vue, une saisie de l'utilisateur dans la vue impacte automatiquement les données du modèle

- les contrôleurs sont sont de simples constructeurs JavaScript, qui n'ont aucune connaissance de la vue : du coup ils peuvent être créés et manipulés en l'absence de toute vue, ce qui rend très simple l'écriture des tests unitaires

- le framework n'a aucun état global, ça aussi pour les tests unitaires c'est le pied

- il est organisé en modules et services, et incite à structurer ainsi son appli, et gère l'injection de dépendances à tous les niveaux, et là encore dans les tests unitaires on peut faire un mock d'un service et l'injecter dans un contrôleur pour vraiment le tester de façon isolée

- il fournit tout ce qu'il faut pour les test unitaires, comme un backend interceptant les requêtes HTTP et renvoyant des données en dur, et franchement pour tester unitairement toute la logique d'une interface utilisateur, on attend le nirvana ;-)

- AngularJS fournit aussi un outil d'exécution de scénarios de tests fonctionnels automatisés, qui comprend un DSL pour agir sur le navigateur et la page web, et surtout qui par son intégration avec le framework permet de masquer totalement l'asynchronisme des tests d'interface utilisateur : on écrit un scénario très simple et complètement linéaire, l'outil d'exécution est prévenu par le framework quand la vue est rafraîchie pour passer à l'étape suivante

- le framework fournit pas mal de services prêts à l'emploi pour simplifier divers usages : récupérer en 2 lignes les données d'un web service (et si c'est du JSON AngularJS le détecte et renvoie le résultat déjà parsé), gérer la navigation dans le cas d'appli multi-page, faire des opérations CRUD sur des ressources REST, gérer l'historique du navigateur, etc.

- c'est un projet full open source hébergé sur GitHub, en licence MIT ; le framework est développé par une équipe de 3 ingénieurs de Google, qui abattent un boulot incroyable tout en étant disponibles et réactifs

Le fait que les applis AngularJS soient aussi facilement testables n'a rien d'un hasard, c'est clairement l'objectif du framework, son auteur est un gourou des tests automatisés qui en connait un bout sur le sujet (voir ici ou là). On pourrait presque dire que le fait que le framework simplifie à ce point l'écriture d'une appli web n'est qu'un (très gros) bénéfice collatéral ;-)

Deux petites démos avec AngularJS que j'ai mises sur jsfiddle : 

http://jsfiddle.net/tchatel/H2y5r/ 

http://jsfiddle.net/tchatel/4FNeB/ 

Et une autre qui n'est pas de moi, où AngularJS est utilisé pour faire du SVG :

http://sullerandras.github.com/SVG-Sequence-Diagram/ 

Je connaissais la page sur le Top 10 des frameworks JavaScript. Mais elle est sans doute approximative, au moins en ce qui concerne AngularJS, puisqu'il est marqué qu'il ne permet pas les vues composées, alors qu'il propose à la fois la composition de vues, un système de templates basé sur le service de routage pour les applis multi-pages, et la possibilité de créer ses propres widgets.

Le seul commentaire que j'ai vu de quelqu'un ayant réellement utilisé AngularJS et d'autres frameworks concurrents est au bas de cette page, mais il est plus que bref, j'aurais bien aimé que le gars développe un peu.

[Sebastien Bordes]

J'ajoute mes 10 centimes à la conversation,

La future version de JavaFX (actuellemnt on en est à la 2.2);nommée JavaFX 8.0 car elle sera diffusée avec la JDK 8.0; va apporter une grosse amélioration du moteur de rendu (déjà performant).

Selon Richard Blair (fxexperience.com)

JavaFX 8.0 performance was improved for almost all benchmarks. In particular performance was improved for:

• more than 50% in Charts
• more than 100% in some Controls
• up to 30% in DirtyArea
• more than 20% in FXFire
• up to 30% in Guimark2.Bitmap and Guimark2.Vector
• up to 30% in JFXPanel-GUIMark2.Bitmap and more than 100% in JFXPanel-GUIMark2.Vector
• more than 30% in Layout
• up to 20% in WebNode.Guimark2-Text

Pour rappel la version 2.2 vient d'ajouter plusieurs choses très intéressantes :

• Media H.264 and AAC support

• Linux support (including plugin and webstart)

• Canvas
  

• New controls: Color Picker, Pagination

• HTTP Live Streaming support

• Touch events and gestures

• Image manipulation API

 Vivement le JavaOne pour en savoir plus !!!

Tchô.