07-09-2009, 02:49 PM
Alors pour ma part, j'ai déjà fait une application assez costaud avec ExtJs et, à l'époque, une grande partie du code javascript responsable de la génération des écrans était renvoyée directement par le serveur. C'est à dire qu'au lieu de créer mes composants et de les inclure toutes dans mon .html, puis de les appeler côté client, le code des composants était renvoyé par le serveur par les requêtes Ajax et exécuté côté client.
J'avais fait ça dans le but "d'encapsuler" ( notez les guillemets ) du code que je considérais comme sensible côté serveur. Bon vu que j'ajoutais à ça une compression du code js qui le rendait illisible par le commun des mortels, en fait c'était pas trop la peine...
Ça avait un certain côté pratique. Côté optimisation, du coup je n'avais pas créé autant de classes que j'avais de composants customs ( un composant correspond en gros à un écran avec formulaires, boutons, grilles...), tout était exécuté à la volée côté client. En revanche, j'utilisais eval() qui est très gourmand mais ça ne se ressentait pas.
Je n'avais aucun problème pour maintenir le code js car bien que renvoyé par le serveur, il était isolé dans mes vues ( MVC powa ), donc mes vues étaient des fichiers javascript, comme elles auraient pu être des fichiers .html.
Considérer que l'affichage = javascript = vue @ MVC, je trouvais ça logique.
Pour le jeu que j'avais commencé à faire full ajax par contre, j'avais pris le parti de créer des classes pour mes trucs personnalisés, et de les instancier le moment venu. Laisser le langage client au client, et le reste au serveur ( en gros, il renvoyait juste les paramètres pour les classes & fonctions js ). Peut-être qu'au chargement de l'application ç'aurait été plus long, mais je pense qu'à l'utilisation il n'y aurait pas eu de problème de lenteur particulière sous prétexte que beaucoup de code javascript eut été exécuté auparavant.
Y a qu'à regarder la lib d'Ext, elle est énorme, des dizaines de composants, un fichier .js qui pèse + d'1 mo quand il n'est pas minimisé et ça prend pas trois plombes au navigateur pour le charger.
J'avais fait ça dans le but "d'encapsuler" ( notez les guillemets ) du code que je considérais comme sensible côté serveur. Bon vu que j'ajoutais à ça une compression du code js qui le rendait illisible par le commun des mortels, en fait c'était pas trop la peine...
Ça avait un certain côté pratique. Côté optimisation, du coup je n'avais pas créé autant de classes que j'avais de composants customs ( un composant correspond en gros à un écran avec formulaires, boutons, grilles...), tout était exécuté à la volée côté client. En revanche, j'utilisais eval() qui est très gourmand mais ça ne se ressentait pas.
Je n'avais aucun problème pour maintenir le code js car bien que renvoyé par le serveur, il était isolé dans mes vues ( MVC powa ), donc mes vues étaient des fichiers javascript, comme elles auraient pu être des fichiers .html.
Considérer que l'affichage = javascript = vue @ MVC, je trouvais ça logique.
Pour le jeu que j'avais commencé à faire full ajax par contre, j'avais pris le parti de créer des classes pour mes trucs personnalisés, et de les instancier le moment venu. Laisser le langage client au client, et le reste au serveur ( en gros, il renvoyait juste les paramètres pour les classes & fonctions js ). Peut-être qu'au chargement de l'application ç'aurait été plus long, mais je pense qu'à l'utilisation il n'y aurait pas eu de problème de lenteur particulière sous prétexte que beaucoup de code javascript eut été exécuté auparavant.
Y a qu'à regarder la lib d'Ext, elle est énorme, des dizaines de composants, un fichier .js qui pèse + d'1 mo quand il n'est pas minimisé et ça prend pas trois plombes au navigateur pour le charger.