Applications JS

[nicolas_froidure]

Bonjour à tous,

Je serai à ParisWeb, mais je ne pourrais pas venir au meet-up JS.
Pourtant, un sujet m'aurait vraiment tenu à coeur : la création
d'interfaces riches en JS.

En effet, je pense que le futur des applications web est d'avoir un
service web RESTful côté serveur et une application cliente en JS côté
navigateur.

J'ai fais un peu le tour des frameworks permettant de réaliser ce type
d'applications et j'ai notamment sélectionné :
- ExtJS : http://www.sencha.com/products/js/
- MochaUI : http://mochaui.org/demo/ Il y a notamment un exemple
séduisant d'utilisation d'une API RESTful ici :
http://dev.sencha.com/deploy/dev/examples/restful/restful.html

J'aurai aimé savoir si certains d'entre vous ont une expérience de ce
type d'applications et plus particulièrement si l'exploitation de ces
deux librairies (ou d'autres) peuvent donner lieu à un outil
réellement utilisable en production et surtout de manière productive
pour l'utilisateur final.

J'hésite entre l'utilisation de ces outils et partir from scratch pour
éviter les problèmes, mais je dois avouer que mes recherches sur
Internet ne permettent pas de voir des applications fonctionnelles
réalisées avec ces outils ou d'autres du même type.

Voilà, hésitez pas à donner votre feedback, voire même à en parler au
meet-up et faire un compte rendu des discutions ici ;).

[Noëlie Amiot]

Nicolas,

ta question est vraiment pertinente, et c'est assez rare que le sujet soit évoquer dans mon entourage professionnel.

J'en profite donc pour intervennir, même si je risque de ne pas t'apprendre grand chose.

J'ai été confronté au développement d'un framework de composant d'interface, et j'avoue que la tâche est assez complexe.

Par expérience, voici le retour de mon cassage de dents : 

* Gérer ton appli en mode sandbox;

* Gérer la communication entre chacune de ces applications;

* Coté utilisateur : l'affichage de messages d'info : erreur, ou notifications;

* Coté développeur : test unitaire de ces applications, et de l'architecture.

Et j'en oublie certainement.

Je ne connaissais pas les framework que tu as cité : on entend beaucoup parlé des framework qui facilitent l'utilisation de JavaScript, mais non de framwork d'architecture.

Leur existence me rassure assez : ça prouve qu'il y a une réelle utilisation de javaScript, en dehors de ce qu'on peux demander couramment (carrousel, etc.)

Pour revenir à nos moutons, ces framework ont l'air de gérer l'architecture, et donc, je suppose, pourrait facilité la maintenabilité d'un application riche.

En effet, plus les applications grandissent en complexité, plus les risques de bug augmentent.

Pour cette raison, je pense que si un framework permet de gérer l'architecture d'une application, cela peux faciliter le développement de l'appli en elle même.

Si le framework croit en communauté, c'est elle-même qui gérera la maintenabilité du framework. les bugs structurels seraient alors remontés à la communauté, et non à la pauvre petite équipe qui gérerait son propre framework.

Je pense donc que choisir un framework peut être une sage décision : le problème étant de choisir le bon.

Ceci est purement théorique, et je sais que je ne réponds pas complètement à ta question en élaborant des hypothèses, 

mais je tenais à partager sur ce sujet. 

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Professionnels francophones du développement web.
Pour envoyer un message à ce groupe, adressez un e-mail à webd...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse webdevfr+u...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/webdevfr?hl=fr

--
Noëlie Amiot
www.no-way.fr

[samuel]

Bonsoir,

dans le genre de framework il y a aussi YUI, 

je l'uitilise en production pour l'admin d'un site, cependant je ne me sert que de certaines briques ( comme les datatable ).

On en parle assez peu je trouve par rapport à tout ce que permet ce framework, au niveau de la gestion des données côté client et des requêtes crossdomain  il était pas mal en avance à en moment.

[Frank Taillandier]

Je serai à ParisWeb, mais je ne pourrais pas venir au meet-up JS.
Pourtant, un sujet m'aurait vraiment tenu à coeur : la création
d'interfaces riches en JS.

Bonjour,

C'est justement le thème de conf' qu'on avait proposé cette année mais qui n'a pas été retenu par les organisateurs de PW  :s

 

J'aurai aimé savoir si certains d'entre vous ont une expérience de ce

type d'applications et plus particulièrement si l'exploitation de ces
deux librairies (ou d'autres) peuvent donner lieu à un outil
réellement utilisable en production et surtout de manière productive
pour l'utilisateur final.

Nous (enfin surtout Sébastien notre architecte logiciel) avons refondu l'interface d'Automne, notre CMS open-source à l'aide d'ExtJS, en faisant le même constat que toi il y a 2 ans sur les interfaces riches dans le navigateur.

Tu peux voir un exemple du résultat sur la démo en ligne :

http://demov4.automne.ws/automne/admin/ 

user : redacteur

pwd : automne

On a vraiment apprécié les progrès en terme de traitement JS de la dernière génération de navigateurs.

... euh par contre pour REST c'est pas encore ça :s

--
Frank Taillandiier

[Julien Wajsberg]

2010/10/5 Frank Taillandier <frank.ta...@gmail.com>:

> ... euh par contre pour REST c'est pas encore ça :s

Pour info, sur une plate-forme J2EE, on utilise le couple CXF/Jackson
pour faire du pur REST avec du vrai JSON (pas la sérialisation toute
moche de jettison), et ça marche très très bien.

Pour traiter tout ça, j'utilise du pur Javascript, avec du jquery (un
peu UI) pour la partie graphique, et ça nous suffit bien.

Le problème de ExtJS et Sencha, c'est leur licence (<troll>et le
problème de MochaUI, c'est MooTools</troll>).

--
Julien

[jpvincent]

Je bosse pour un site qui s'est transformé en 2 ans au fur et à mesure
des besoin en demie application Web. Je m'étais basé sur YUI qui est
une librairie plus qu'un framework, il me restait donc à coder
l'architecture et le code métier, ce qui point de vue code représente
2 tiers de PHP et un tiers de JS
Hors on ne s'était pas rendu compte immédiatement que ce que nous
voulions nécessiterait beaucoup plus qu'une simple architecture
modulaire : au début chaque composant JS était dans son coin, mais on
n'a jamais vraiment formalisé les relations entre eux, on se retrouve
donc avec des composants qui s'appelle entre eux, ce qui marche mais
qui est difficilement maintenable sur le long terme
En fait on a sauté une étape primordiale qui est un controller central
qui gèrerait tous ces évènements, un peu comme le code de l'ancien et
du nouveau twitter

du coup je n'ai pas l'expérience des librairies que tu cites, mais en
regardant chacune de leurs specs, j'avais vu qu'elles te "forçaient" à
énormément structurer ton code, et avec le recul je pense que c'est
primordial lorsque tu abordes pour la première fois une application
Web en JS.

Après c'est le même débat qu'en PHP : si tu as le niveau et que tu es
sur de toi, tu finis par jeter les frameworks contraignants pour coder
rapidement un framework spécifique à ton application (tout en
utilisant des librairies comme PEAR ou Zend framework) : il sera
d'autant plus léger et maîtrisé par l'équipe
Si tu débutes, prends n'importe lequel des frameworks que tu cites, de
mémoire ils sont généralistes.

Perso en voyant la somme d'erreurs qu'on a faites et qui nous servent
malgré tout d'expérience, je partirais sûrement sur une architecture
custom. Mais si tu crées plusieurs applications d'affilé, mieux vaut
investir sur un framework :)

[jpvincent]

On 5 oct, 19:30, Julien Wajsberg <fel...@gmail.com> wrote:
> Le problème de ExtJS et Sencha, c'est leur licence (<troll>et le
> problème de MochaUI, c'est MooTools</troll>).

tu peux expliciter ? ça m'intéresse (pour une prochaine fois) :)

[merle]

Hello,

Je travaille actuellement sur une l'évolution d'une grosse appli
métier (Java) intranet/extranet :
Nous avons choisi de partir sur un "framework" maison JS + CSS basé
sur Struts / Tiles / jQuery.
Le framework est packagé en un fichier jar (les dev java comprendront
^^) qui contient :
- tous les fichiers js et plugins jQuery (plugins public et maison, un
petit peu de jQueryUI).
- les templates principaux en Tiles (inclusion des fichiers de base
css et js)
- sa documentation (exemples et snippets de code pour les dev)
- des process de build et optimisation (minification et compression
des js et css)
- un process de création de nouvel écran (page "hello world" de
documentation) dans l'appli.

Dernièrement j'ai un peu joué avec requirejs : http://requirejs.org/
et sammy : http://code.quirkey.com/sammy/

J'aurais bien aimé les utiliser pour le projet décrit plus haut :)
ça a l'air très prometteur et intéressant, comme approche. Là pour le
coup, on n'est pas limité à un seul langage serveur (hormis javascript
si on veut utiliser le process de build de Require.js)).
ça pose des infrastructures légères, coté client, pour du organiser et
gérer une appli JS de façon souple :

Sammy est un bloc REST pour JQuery : il permet de définir des routes
pour la navigation. Pour un exemple :
http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-an-introduction-to-sammy-js/

Require.js lui est un gestionnaire de dépendances javascript,
permettant de charger des modules entiers à la volée. Il inclut
également un outil de build et d'optimisation (concaténation,
minification et gzip des *.js). Voir la page consacrée à son usage
avec jQuery.(http://requirejs.org/docs/jquery.html)... Dommage que
pour l'utiliser avec jQuery, il faille un build spécifique de la
dernière version de jQuery.

Enfin, les licences de ExtJs et Sencha me posent aussi problème ^^
Sans compter que ces outils risquent de mal vieillir... enfin c'est
mon sentiment.



On 5 oct, 13:37, nicolas_froidure <nicolas_froid...@elitwork.com>
wrote:

> Bonjour à tous,
>
> Je serai à ParisWeb, mais je ne pourrais pas venir au meet-up JS.
> Pourtant, un sujet m'aurait vraiment tenu à coeur : la création
> d'interfaces riches en JS.
>
> En effet, je pense que le futur des applications web est d'avoir un
> service web RESTful côté serveur et une application cliente en JS côté
> navigateur.
>
> J'ai fais un peu le tour des frameworks permettant de réaliser ce type
> d'applications et j'ai notamment sélectionné :
> - ExtJS :http://www.sencha.com/products/js/

> - MochaUI :http://mochaui.org/demo/Il y a notamment un exemple

[Loic Giraudel]

> Sans compter que ces outils risquent de mal vieillir...

Il me semble que ExtJS a d'ailleurs subit pas mal de remous entre la
version 2 et la version 3 justement parce que l'équipe de dev avait
changé un peu trop en profondeur le framework, si bien que songer à
migrer une appli était presque utopique.

J'ai eut pour ma part l'occasion de bosser pendant prés d'un an sur du
ExtJS (v3) afin de réaliser un "portail de gadgets" et il faut
reconnaître que c'est plutôt bien foutu pour gérer certaines briques
potentiellement délicates (la gestion d'un layout non-figé avec
panonceaux rétractables ou redimensionnables, la conservation d'état,
la gestion de l'historique de navigation, la création de datastores
alimentés en ajax, etc). J'ignore ce qui se passera le jour où il
passeront à une v4 mais la v3 est vraiment bien.
Aujourd'hui, dans le cadre d'un autre projet, je n'utilise plus que
les datagrid de ExtJS qui sont relativement riches par rapports à ce
qu'on peut trouver à côté.

Le principal risque avec les frameworks de composants c'est la
difficulté à créer de nouveaux composants adaptés à ses propres
besoins. Même si nous n'avons pas cherché à créer des composants ExtJS
re-exploitables dans le cadre de mon projet, nous avons pu sans
problème créer du contenu riche dans l'application : un de nos panel
contenait une étiquette énergétique (http://fr.wikipedia.org/wiki/
%C3%89tiquette-%C3%A9nergie), un autre contenait un synoptique
signalant des évènements remontés via une technologie Ajax Push comme
cometD (http://cometd.org/). Bref, on ne s'est pas limité aux
composants de ExtJS et nous n'avons pas rencontré de difficultés de ce
côté là.

Cela dit des frameworks de composants il y en a un paquet, même si la
plupart sont payants. J'ai eut l'occasion de bosser avec DHTMLX
(http://dhtmlx.com/), j'ai un peu approché Bindows (http://
www.bindows.net/), le plus dur est de trouver celui qui est le plus
adapté aux besoins fonctionnels.

Bon il faut bien reconnaître que mon côté bidouilleur fou préfère
redévelopper un composant riche que d'utiliser quelque chose de tout
fait mais il faut admettre qu'en terme de productivité ces frameworks
apportent énormément.

--
Loïc

> pour la navigation. Pour un exemple :http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-an-introd...

>
> Require.js lui est un gestionnaire de dépendances javascript,
> permettant de charger des modules entiers à la volée. Il inclut
> également un outil de build et d'optimisation (concaténation,
> minification et gzip des *.js). Voir la page consacrée à son usage
> avec jQuery.(http://requirejs.org/docs/jquery.html)... Dommage que
> pour l'utiliser avec jQuery, il faille un build spécifique de la
> dernière version de jQuery.
>
> Enfin, les licences de ExtJs et Sencha me posent aussi problème ^^
> Sans compter que ces outils risquent de mal vieillir... enfin c'est
> mon sentiment.
>
> On 5 oct, 13:37, nicolas_froidure <nicolas_froid...@elitwork.com>
> wrote:
>
>
>
> > Bonjour à tous,
>
> > Je serai à ParisWeb, mais je ne pourrais pas venir au meet-up JS.
> > Pourtant, un sujet m'aurait vraiment tenu à coeur : la création
> > d'interfaces riches en JS.
>
> > En effet, je pense que le futur des applications web est d'avoir un
> > service web RESTful côté serveur et une application cliente en JS côté
> > navigateur.
>
> > J'ai fais un peu le tour des frameworks permettant de réaliser ce type
> > d'applications et j'ai notamment sélectionné :
> > - ExtJS :http://www.sencha.com/products/js/

> > - MochaUI :http://mochaui.org/demo/Ily a notamment un exemple

[nicolas_froidure]

Bonjour et merci à tous pour vos réponses.

C'est en fait tout ce que j'ai à dire vu que je n'ai tjrs pas fait de
choix (framework ou pas, si oui lequel), j'ai encore un peu de temps
devant moi.

J'ai pas la contrainte du IE compatible vu que mon client a un parc
maîtrisé avec Linux+FF sur toutes les bécanes. C'est ce qui me fait
dire que pas mal des fonctionnalités de ces outils seraient pas ou peu
utiles et que je pourrais gagner énormément en vélocité. Je tenterai
bien le XUL vu que je connais bien, mais difficile d'y voir clair au
niveau du sort que lui réserve Mozilla.

Dans le même temps, partir de zéro, ça sous entend une bonne tapée de
devs à réinventer la roue (moins que si je devais être IE compatible).
Quelqu'un connaît une lib orientée HTML5 et nouveaux navigateurs ?

Bref, merci pour vos retours, décidément cette liste est bien
fréquentée, c'est autre chose que les forums.

++

> (http://dhtmlx.com/), j'ai un peu approché Bindows (http://www.bindows.net/), le plus dur est de trouver celui qui est le plus

> > > - MochaUI :http://mochaui.org/demo/Ilya notamment un exemple

[jpvincent]

> Quelqu'un connaît une lib orientée HTML5 et nouveaux navigateurs ?

il n'y a aucune librairie unique à ma connaissance qui te permet
d'accéder aux fonctionnalité HTML5, il y a juste un paquet de petites
librairies qui le font chacune visant une fonctionnalité en
particulier. Mais à la limite, si tu maîtrises le parc, accède
directement aux APIs du DOM, ou mieux : fais toi une classe façade qui
te permet d'y accéder, ça te permettra de réagir rapidement en cas de
modification des specs puis des implémentations navigateur.
Ce qui te prendra du temps ce sera de toute façon le code métier, pas
les fonctionnalités elle même (ex: accéder à localStorage, c'est
facile, gérer une synchronisation client/serveur, c'est autre chose)

si tu veux plus général, HTML5 ou pas, je sais qu'aujourd'hui je
partirais sur du YUI3 (je suis resté à YUI2 et la migration demande un
gros effort) ou sur du ExtJS / Sencha (très bonne qualité, mais
payant) car ce sont des projets que je regarde depuis longtemps, qui
sont solides et sérieux et qui sont orientés performances,
réutilisabilité, modularité, et qui possèdent nombre de widgets qui
pris indépendamment prendraient des semaines à coder
bref tout ce qui fait un framework moderne

[Loic Giraudel]

Personnellement j'ai tendance à préférer une approche modulaire plutôt
que de choisir un framework unique et m'y tenir. Ca alourdit
potentiellement le tout mais ça permet de réagir plus facilement aux
changements demandés par le client.

En ce moment je mélange allègrement jQueyUI + ExtJS, je suis assez
content du résultat surtout après avoir uniformisé le design pour ne
pas avoir trop de disparités entre les composants venant des deux
frameworks.

Le Flex c'est pas mal aussi pour faire des applications web. Le projet
de portail de gadgets fait en ExtJS, je l'ai ensuite porté en Flex
sans grosses difficultés, tout en conservant les petites
particularités du projet (par exemple la techno ajax push).

Il faudrait que je me repenche sur YUI. J'ai tendance à le considérer
comme un framework bas niveau mais c'est vrai qu'il a également un
paquet de composants graphiques...