Tempête sur les RIAs

Ceci n’est pas un billet de fond mais un appel à commentaires :

De l’autre coté des serveurs les utilisateurs raffolent de ces applications enfin ergonomiques et qui fonctionnent sur les vieux coucous des services administratifs du CAC 40 équipé du bon vieil IE.

Que devons-nous faire en phase de choix :

  • Revenir à du JS le temps que la tempête passe ?
  • Miser sur la communauté pour assurer l’avenir de Flex et de GWT ?
  • Miser sur les alternatifs : Vaadin,…?
  • Traverser la tempête vitesse grand V et mettre du HTML5 partout ?

A vos commentaires.

TwitterFacebookGoogle+LinkedIn
  • http://twitter.com/sliard Samuel Liard

    Depuis 1999 je vous dis qu’il faut faire des Applets ! ;)

  • Florent DUVEAU

    Je mise sur HTML5 & DART !

    • http://twitter.com/geoffray_ippon Geoffray Gruel

      Oui c’est sur que quand on s’appelle Google on peut se lacher en HTML5/Dart pour les applis grand public. Le problème c’est que nous on s’appelle Ippon et qu’on doit déployer des applis métiers dans des grandes banques ou industries françaises pour qui “Chrome” est une option chez BMW et “Firefox” un dessin animé du matin sur CanalJ. Moralité pour du 100% HTML5 il faudrait qu’on arrête les applis métiers pour ne faire que du BtoC. C’est une piste ;->

      • http://www.next-presso.fr Antoine Sabot-Durand

        Tu peux aussi pousser pour installer le plugin chrome frame sur les postes IE6. C’est pas plus bete que le plugin Flash et ça te permet de supporter HTML 5 sur les vieux coucous des DSI dinosaures

        • http://twitter.com/geoffray_ippon Geoffray Gruel

          Ouais mais on en revient toujours au problème Google : le gars de la “DSI Dinausaure” il veut bien installer Flash car derrière il a Adobe en support. Si tu lui demandes d’installer Chrome il va demander du support à Google et il va attendre longtemps. Et dans tous les cas il ne prendra JAMAIS le risque de le supporter lui-même ;-<

          • Bruno Leroux

            Normalement l’offre Chrome for Business est là pour répondre à ce problème : http://www.google.com/apps/intl/en/business/chromebrowser.html , mais je ne suis pas spécialiste de la question

            Il faut voir le bon côté des choses : si seul HTML 5 est viable, les grands comptes n’auront plus d’autre choix que de migrer vers des navigateurs modernes :-)

            Pour ceux qui ne connaissent pas ce site : http://www.ie6countdown.com/, il serait bon de le montrer à vos ‘gars de la DSI dinausaure’ pour les informer que même Microsoft attend avec impatience la mort définitive d’IE6 … en espérant qu’ils fassent ensuite les mêmes sites pour ie7 et ie8 :-)

  • Nicolas GUERRIER

    Idem HTML5 & DART (compilé par du GWT :) )

  • http://twitter.com/szerement SZEREMENT Alexandre

    J’espère seulement que le dont du SDK flash à l’Open Spoon Foundation va donner quelque chose.
    J’aurais vraiment l’impression de régresser si il n’était plus possible de faire des IHM web sans pouvoir compiler mon code.

    Remarque : Je note que “Java FX”  n’est même pas dans la discussion

    • http://www.next-presso.fr Antoine Sabot-Durand

      Je viens de voir une conf JavaFX, ça à lair vraiment pas mal et justement permet de faire du HTML 5 + Javascript hors du browser (avec des webview comme sur les applis mobiles). Mais bon ça reste une appli à déployer côté client…

      • http://www.jroller.com/dmdevito/ DominiqueD.

        J’ai l’impression – comme exprimé dans un post http://www.jroller.com/dmdevito/entry/javafx_is_swing_2_0 – qu’avec JavaFX, Oracle rebâtit (ou pourrait rebâtir) une stack proche de celle de Adobe AIR:
        - Java (à la place de ActionScript)
        - WebKit intégré au sein de JavaFX (idem AIR)
        - possibilité de définir des vues dans un langage XML-based : FXML pour JavaFX
        - Runtime à part du navigateur (idem AIR)
        - open source (idem AIR)
        - etc.

        Bref, avec le possible déclin de Flex et de Silverlight, Oracle aurait une carte à jouer.
        Ce pourrait être comme le retour de HotJava, soit un des tout premiers navigateurs tout en Java : http://www.jroller.com/dmdevito/entry/hotjava_may_come_back_due

        En fait, SUN a voulu combattre directement HTML avec Java (les applets Java) et a été écrasé par ce rouleau compresseur (i.e. HTML) : http://www.jroller.com/dmdevito/entry/html_the_juggernaut_of_our
        L’approche JavaFX semble être héritière de la leçon de l’échec des applets : Oracle ne cherche plus à affronter directement HTML, mais mixe les forces de HTML et de Java à travers JavaFX (puisque le runtime JavaFX contient notamment WebKit). Ce pourrait être la souche permettant de faire refleurir les applis Java sur le poste client, pour la création du bureau métier.

  • http://www.next-presso.fr Antoine Sabot-Durand

    JSF 2 + Primefaces : standard et s’appuyant sur jQuery. 

  • Pxzk54w582idz7r

    Pourquoi ne pas donner ça chance à Eclipse RCP :
     - Plateforme de client riche
     - Outillage complet (build, deploy, update)
     - Repose sur l’écosystème java
     - Nombreuses ressources disponible sur le net

  • Gwennael Buchet

    Le gros avantage de Flex et de Silverlight c’est aussi d’avoir une séparation entre le code et l’interface (xaml/c# et mxml/as3).
    En HTML/javascript les composants “évolués” (entendons par là plus évolués qu’une balise ) sont insérés en code et non tous en balise.
    Du coup on n’a pas du tout la même souplesse dans le code.
    Les interfaces Wysiwyg HTML5/JS sont encore assez pauvres et on va devoir attendre encore un peu avant d’arriver au niveau d’un FlashBuider.

    2eme point très important aussi c’est la fluidité de l’application que l’on a en Flex et SL et pas vraiment en JS (que ce soit via GWT, Eclipse RCP ou un framework JS). Dès qu’on a une appli un peu complexe, les explorateurs montrent leurs limites. 
    On est sur des pages web et non plus sur une appli bien structurée en arborescence. Du coup on n’a pas la même réactivité entre les différentes vues (même si des frameworks comme ExtJS4 proposent le mode appli MVC).

    Je n’ai aucun doute que Flex et SL vont mourrir, mais ne pas pouvoir profiter pleinement des designs comme l’IOC, le MVC et autres c’est une belle régression. Il va falloir du temps, à mon avis, pour que des frameworks + IDE vraiment complets et rapides n’arrivent au niveau de Flex et SL.
    Et puis le HTML5 n’est toujours pas sec…

  • http://twitter.com/olamy olamy

    “Revenir à du JS le temps que la tempête passe ?”.
    Perso je dirais oui. Pour des raisons de performances et en plus il y maintenant beaucoup de framework javascript mvc (knockout, javascriptmvc, backbone, sproutcore etc..) qui facilitent la vie. 
    En plus l’avante d’écrire ses services métiers en REST pour leur consommation via l’appli js permet aussi de les partager avec d’autres applications.

  • http://twitter.com/wdrai William Draï

    Avant tout je précise que je travaille sur le projet GraniteDS d’intégration Flex/Java mais je vais essayer d’être aussi objectif que possible.

    Flex et Silverlight ont apporté plusieurs choses essentielles :
    1. Une architecture RIA avec un client riche qui appelle des services, et plus le concept de pages et de navigation qui ne convient pas à la plupart des applications d’entreprise
    2. Des librairies de composants graphiques complètes et faciles à étendre
    3. Un développement industriel avec des outils, des frameworks et autres
    4. La possibilité d’être déployé sur tous les navigateurs actuels, IE6 y compris, grâce à un plugin déjà présent un peu partout (sauf Silverlight cela dit)

    Pour le 1, c’est parfaitement possible à faire avec du HTML/JS mais ce n’est pas encore la ‘mode’. En tout cas c’est TRES eloigné de ce qui se fait avec JSF, Spring MVC, ou n’importe quelle autre techno à base de templates HTML. Et c’est bien dommage parce que ça permet d’avoir une architecture vraiment propre et de séparer clairement la couche présentation de la couche service (et donc d’éviter d’être à la merci des évolutions de toutes ces technos Web).

    Pour le 2, hormis peut-être ExtJS, je ne vois pas trop d’équivalent à Flex/Silverlight pour les composants graphiques riches et la qualité visuelle. Avec GWT, on a l’impression que chaque composant un peu complexe est une victoire technologique incroyable pour une armée de hackers. C’est sympa mais pour faire une vraie application j’ai pas envie de chercher partout des composants plus ou moins bien réalisés.

    Pour le 3, ben j’attends encore de voir des choses pour HTML/JS mais il y en a peut-être. GWT est probablement ce qui se rapproche le plus de Flex de ce côté-là.
    Pour le 4, rien de plus à dire. Le jour où je verrai un Chrome, un Firefox (sans même parler d’un Chrome Frame sous IE) chez un grand compte, je changerai peut-être d’avis. Mais après avoir lutté pendant des années avec des incompatibilités HTML/CSS/JS entre IE, Firefox, Safari sur Windows, Mac et autres, Flex était réellement une bouffée d’air frais.

    Le 5, c’est que Flex c’est fun et ça redonne vraiment plaisir à développer. On peut faire des trucs faciles à utiliser sans se demander à chaque fois si c’est possible en JS ou comment hacker la css pour mettre un encadré bleu. Après il y a des gens qui adorent hacker du jQuery et qui font des choses excellentes mais bon… pas moi.

    Pour résumer, avec Flex et GraniteDS, vous avez le 1, le 2, le 3, le 4 et le 5 et en plus comme notre architecture n’implique aucune dépendance ni à Flex ni à GraniteDS vous pourrez switcher joyeusement vers HTML5 quand le besoin s’en fera sentir sans rien toucher au serveur.
    A noter également que Flex est une couche au-dessus de Flash et qu’il pourrait finir par être possible de compiler du Flex en HTML5/JS plutôt qu’en Flash/AS3.