Discussion :

[benwit]

Bonjour,

Au départ, HTML a été conçu pour rédiger des documents. On fait de plus en plus d'application avec cette technologie qui n'est pas conçu pour à l'origine. Pour preuve la régression subie par les applications client riches portées dans un client web dans les années 2000.
Depuis trois ans, on compense ces limitations du mode déconnecté (HTTP est un protocole sans état) par l'AJAX et/ou l'hémergence de nouveaux plug-in pour le navigateur.

On en arrive à la situation où :
soit on intègre un "client riche généraliste" dans le client léger pour afficher son interface (Flash, Silverlight et cie ...)
soit on fabrique dynamiquement du code HTML côté serveur qui sera manipulé avec du Javascript pour modifier le DOM côté client.

Et comme dirait Clooney : What else ?
XUL semblait prometteur ... Je parle au passé car son manque de doc initial la à mon sens tué dans l'oeuf. Il y a 4 ans peut être mais aujourd'hui, je ne crois plus à son émergence surtout qu'on est bien obligé de constater que Microsoft (dont les part d'IE ne sont pas négligeable) n'y passera jamais (surtout s'il veut imposer son Silverlight face à Flash)

JavaFx ? Je n'y crois pas trop ? Sun veut juste résister face à la concurrence ...

Je me pose donc la question de l'avenir de la programmation web ?
Ne devrait t'on pas remettre tout à plat ? créer un protocole fait pour le dév d'application ? Quel avenir pour les navigateurs à l'heure ou certains veulent mettre le web sur le bureau (AIR, Prism ...) et d'autres votre bureau sur le web (les affreusement mal nommés WebOS) ?

Le but du débat n'est pas de comparer les technos existantes mais vous pouvez bien entendu en parler pour illustrer les avantages/inconvénients.
Si certains avaient des idées complètement originales, ça serait bien aussi.

A vos claviers ...



PS :
avant d'ouvrir ce débat, j'ai fait une recherche sur ce forum (car ma question ne se limite pas à une techno particulière Java, .Net, Flex, air, Siverlight, ...) avec les mots avenir et web.
je n'ai pas non plus posté dans le forum webmasters - développement web car pour moi, les webmasters, ça se limite aux sites web et je souhaite discuter d'applications web (même si ça se ressemble).

[Phelim]

L'avenir du web est confiné au limite des navigateurs actuellement.

Si on utilise du javascript c'est que pas le choix, ça reste la techno la plus facilement déployable. Seulement on commence à atteindre les limites.

Si on regarde un frameworks tel que DOJO, extremement puissant pour créer des interfaces (au sens du web), on casse complètement la structure du code xhtml, ça rustine de tous les cotés et c'est gros en taille. C'est en plus assez chiant à manipuler avec du code dynamique.

Pour les RIA, c'est une solution à condition de pouvoir les intégrer facilement au navigateur. La dessus, encore microsoft au milieu qui est à la fois arbitre et joueur.
Pour le moment, flou complet à ce niveau.

Installer manuellement une JVM ou un plug in flash ne reste pas une solution qui est viable pour le client.

En gros, on est parti pour un moment sur le protocole http.

Il reste l'approche de google qui est interessante : programmer du java et le convertir en javascript (je n'ai pas regardé ça en détail), malheuresement, le code risque de prendre rapidement du poids. Ca fait un peu bricolage au final.

Actuellement, je ne considère plus ça comme un problème technique, les techniques existent.
Dorénavant, c'est l'utilisateur qui fera la différence au travers de ses choix.

Les programmeurs doivent donc aujourd'hui y aller par parie pour choix comment développer leur application.

Le bureau sur le web y sera mais pas avec les technos actuels. C'est comme les suites offices déportés. D'ailleur ça fait un moment que j'en entends plus parler ^^.

Le web n'est pas fait pour ces applications, c'est du rustinage technologique.

Le gros avantage du web c'est justement son principal inconvénient : les navigateurs avec leur approche plus ou moins standarisé.

Et voila, la boucle est bouclé.

[benwit]

Merci pour ton point de vue.

Concernant GWT, j'ai regardé et si l'approche m'a séduit, je crains comme toi la taille du code généré. Je travaille à une solution qui prendrait le meilleur des 2 mondes (code javascript généré et code fabriqué par le serveur)

Même si ça fonctionne, mon questionnement par justement du constat :
Je code du Java qui sera compilé en Javascript qui sera interprété par le navigateur pour fabriquer le DOM HTML qui sera interprété pour afficher le rendu ... Ouf !

[pmithrandir]

Hello

Je me souviens de mon premier stage dans le service info de l'iut ou j'étais.

L'ingénieur qui avait un peu de bouteille avait mis en place une installation centralisée de linux. Tout était sur le serveur, et presque rien sur les postes clients.

Comme je m'étonnais un peu de ca(surcharge du réseau, qui était en plus en 10Mbits) il m'avait expliquer que l'on avait mis en place ce genre de système avec les console utilisateurs dans le passé.

Le problème qui se posait était clairement celui du débit réseau(local et internet) et de la puissance serveur.

Comme ces deux variables ne cessent de croitre, je pense que l'on reviendra à terme sur ce genre de système.

Donc après un passage de transition ou l'on ne fait du logiciel console sur application web, on passera à nouveau à des clients lourds, hébergés uniquement sur le serveur.

Bien sur, je parle la de gros parcs informatiques dans un premier temps, puis de parc de plus en plus réduit au fur et a mesure que des solutions clef en main seront proposées par des entreprises spécialisées.

[benwit]

Ton intervention est intéressante.

Revenir au client lourd, peut être ?

Du coup, qu'est ce qui les sépare encore des applications par client léger ?

Avantages du client léger :
+ pas d'installation sur le poste client (à moins de considérer que le cache du navigateur joue ce rôle)
+ plus de sécurité (le navigateur joue le rôle de bas à sable), l'application n'accèdera pas à nos ressources à moins de l'y avoir autorisé. (Mais c'est plus un argument d'informaticien)

En faisant l'analogie suivante :

Document <--> Application
HTTP <--> ???
Navigateur <--> ??? (une sorte de "méta" application "libre" (plusieurs implémentation mais une même spécification) qui ferait tourner des applications "web" riches, et qui permettrait de paramétrer les niveaux d'accès)

[skaalf]

Hello,

Pour avoir pas mal bossé sur du web "ajaxisé", c'est clair que le model actuel du serveur qui génère du (x)HTML sur lequel on ajoute du JS pour l'ergonomie (Drag'n Drop etc...) à vécu...
C'est lourd à dev, chiant à maintenir et lent à l'exécution, de plus, on arrive assez vite à complètement pourrir le navigateur avec tous ces script.

Je ne parlerais même pas des fonction X ou Y qui fonctionnent de manières différentes sur chaque navigateur, voir qui n'existe pas du tout (c'est du vécu)

Il me parait clair que les applications vont sortir du navigateur à court terme, (AIR par exemple) par contre ça implique une installation ce qui devient vite chiant.

Lors du javaone de cette année, une démo à lieu avec une feature que j'ai trouvé assez géniale: une applet JavaFX était lancé dans le navigateur, et en été "extraite" par un simple drag'n drop de l'application sur le bureau, le navigateur pouvais ensuite etre fermé et l'application continue a tourner.
Ca ouvre des perspectives vraiment sympa, surtout si le programme est capable de détecter l'événement "sortie du navigateur"

On pourrais par exemple imaginer que dans ce cas l'applet se sauvegarde automatiquement dans un repertoire dédié, on fusionne le RIA et le RDA en quelques sorte.

Je ne pense pas que AIR soit capable de faire la même chose car les applis web flash et AIR ont des runtimes différentes.

Quelqu'un sait si silverlight permet ce genre de chose ?

Jusque la j'était assez peu convaincu par JavaFX, mais rien que pour ça, je suis déjà plus optimiste.

En ce qui concerne le retour au mode terminal, je n'y crois pas trop.
Que se passe t'il si le réseaux tombe, ou si on a pas de réseaux du tout (dans le train par exemple) ?


A vos clavier