Discussion :

[Invité]

c'est plus une notion super-abstraite qu'une existence réel ?

C'est pourtant ce que tu vas présenter à l'utilisateur, non? Une interface formée de "composants" qui peuvent avoir des données, recevoir des sollicitations clavier ou souris (ou tout autre périphérique de saisie), et s'afficher.

Ces composants devront bien avoir une existence dans le système, des types paramétrés probablement (puisqu'on ne les fait pas descendre d'un superWidget). Mais l'implémentation de leurs données, de leur dessin, et de leur interaction saisie seront déléguées, en vertu de la séparation...

C'est peut être juste moi, mais j'ai beaucoup de mal à imaginer un modèle d'IHM qui n'utilise pas des widgets (quelqu'autre nom qu'on leur donne), ou alors on tombe dans l'interface "totalement dessinée" des jeux vidéos, qui s'apparente davantage à une vidéo calculée en runtime qu'à une IHM (et qu'on pourrait même considérer, dans un modèle à widget comme un widget unique).

Peut être est ce un point sur lequel on peut statuer assez vite, d'ailleurs.

Y a-t-il d'autres options? En veut on?

Francois

[epsilon68]

En terme de look, oui, mais en terme de logique applicative, surement pas... En gros, ce qui fait la qualité d'une appli desktop (on a le moteur de calcul sous la main, on peut faire plein de petits calculs vite fait), est complètement différent de ce qui fait l'intéret d'une appli web (données décentralisées et uniques, sécurité des accès, mais contrainte sur la bande passante des échanges).

Pour une appli un tant soi peu compliquée (en termes de volumes de calculs ou de données), une même appli web et desktop, c'est la garantie d'un truc inefficace dans les deux domaines. (C'est un peu ce qui condamne AIR, chez Adobe)

A mon avis, un framework d'IHM est ici un framework desktop. On peut lui donner un "look web", mais c'est tout ce qu'il aura de web.

Je ne suis pas d'accord.
bon je ne parle pas d'opengl ou de gerer 150'000 objets
mais d'une interface de gestion de données.

afficher des tables, masque de saisie, presentation de données etc
et bien la c'est tout a fait possible et c'est rapide.
Je le fais deja avec Qt webkit.

d'ailleurs Qt fait toutes les approches:
1. la standard (widgets / layout / signal-slot)
2. QML (XAML, XUL etc)
3. webkit (html css javascript)

je suis plus dans la 3ieme solution, et ca marche vraiment bien.

[koala01]

Je crois qu'il serait temps de recommencer à faire les bonnes choses avec les bons outils...

L'utilisation de webkit n'a vraiment de sens que dans l'optique d'une application... utilisant le réseau...

C'est un système génial, il faut bien l'avouer, mais, il n'en demeure pas moins que c'est prévu pour... déléguer une partie de la gestion au serveur qui se trouve à l'autre bout.

Commencer à utiliser webkit alors que tout se trouve sur le même ordinateur, dans le même dossier (ou tout comme) est proche de l'aberration, pour ne pas dire de l'hérésie.

[epsilon68]

Je crois qu'il serait temps de recommencer à faire les bonnes choses avec les bons outils...

L'utilisation de webkit n'a vraiment de sens que dans l'optique d'une application... utilisant le réseau...

C'est un système génial, il faut bien l'avouer, mais, il n'en demeure pas moins que c'est prévu pour... déléguer une partie de la gestion au serveur qui se trouve à l'autre bout.

Commencer à utiliser webkit alors que tout se trouve sur le même ordinateur, dans le même dossier (ou tout comme) est proche de l'aberration, pour ne pas dire de l'hérésie.

encore une fois pas d'accord.
webkit est un moteur d'affichage, rien de plus.

si tu comprend XAML alors tu comprends que HTML est aussi un langage descriptif, et qu'il faut dans les deux cas un moteur d'affichage. Et bien pour l'html, j'en connais au moins un: Webkit

[koala01]

J'ai honnêtement l'impression que je perdrais mon temps si j'essayais de te faire comprendre que HTML est, certes, un langage descriptif, mais qu'il a été créé pour une raison précise, afin de résoudre une problématique précise, et que c'est, entre autres, parce que l'on avait atteint les limites de ce que l'on pouvait envisager avec HTML que l'on a mis XML au point.

Vouloir utiliser HTML dans un domaine autre que celui pour lequel il a été conçu revient, peu ou prou, à vouloir utiliser SQL Server pour... gérer les options de configuration d'une application...

Les deux sont possibles, mais les deux sont particulièrement inadaptées à l'usage qui en est fait.

Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées

[Lavock]

Ok, je vois, il s'agit donc de tout séparer dans l'implémentation, pour présenter des "bêtes" widget à l'utilisateur du framework.

Mais du coup, je vois mal en quoi, pour l'ulisateur, c'est innovant. Il s'agit toujours de penser en widget, ça, j'aime pas trop.

Sans tomber dans le jeux vidéo et le moteur graphique, il y a peut être moyen de faire "entre les deux"... Ou comment pensée une ihm de la même façon qu'on penserez l'ui d'un jeux vidéo => c'est, à près tout, de ça que c'est inspiré Klaim.

Après tout, il y a des exemples d'ihm pas banal dans le jeu vidéo : Expérience 112 pour ne citer que lui.

Est-il a ce point étrange de penser qu'on peux trouver mieux que le cadre poser du widget ? Peut importe la façon dont il est amené d'ailleurs (non, je suis franchement pas fan du webkit).

Je veux dire, tant qu'à les séparer à l'implémentation, pourquoi l'utilisateur ne pourrait pas en profiter pleinement ?
Et quel est donc l'intérêt suprême du widget qui m'échappe à ce point ?

Dans la bassitude de ma compréhension, j'espère que je fais au moins un peu avancer le débat >< ! Sinon, j'en suis vraiment désolé.

[metagoto]

Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées

Et bien pour le coup, je comprends la position et les arguments de epsilon numéro 68.

C'est un moteur de rendu après tout (je parle de webkit). En plus il embarque javascript core (toujours sympa à avoir sous le coude) et il gère html et svg. A vrai dire, webkit résout à lui seul toute la problématique sachant qu'il est open source, cross platform et son api est en c++.

C'est tout naturellement que Qt a su tirer partie de ce toolkit.

Tient d'ailleurs je suis en train de penser: Chrome OS n'utiliserait-il pas webkit pour son interface ?

A propos des widgets: je vois ça comme une entité résultante d'une part de données et d'autre part de leur représentation sur un support quelconque. C'est du Model-View. Tout comme fcharton j'ai du mal à me débarrasser de la notion de widget, à commencer par le fait que l'appli toute entière peut être considérée comme un widget.

[epsilon68]

entre autres, parce que l'on avait atteint les limites de ce que l'on pouvait envisager avec HTML que l'on a mis XML au point.

rien à voir, mais absolument rien.

par contre ils ont "essayé" de faire XHTML pour profiter des parseurs XML.
ca a plus ou moins été un coup dans l'eau, et ils sont reparti dans HTML 5.

[epsilon68]

Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées

merci beaucoup pour ta remarque (ironie)

[koala01]

Et bien pour le coup, je comprends la position et les arguments de epsilon numéro 68.

C'est un moteur de rendu après tout (je parle de webkit). En plus il embarque javascript core (toujours sympa à avoir sous le coude) et il gère html et svg. A vrai dire, webkit résout à lui seul toute la problématique sachant qu'il est open source, cross platform et son api est en c++.

C'est tout naturellement que Qt a su tirer partie de ce toolkit.

Tient d'ailleurs je suis en train de penser: Chrome OS n'utiliserait-il pas webkit pour son interface ?

A propos des widgets: je vois ça comme une entité résultante d'une part de données et d'autre part de leur représentation sur un support quelconque. C'est du Model-View. Tout comme fcharton j'ai du mal à me débarrasser de la notion de widget, à commencer par le fait que l'appli toute entière peut être considérée comme un widget.

Comme navigateur internet, ou pour créer un navigateur webkit est exactement ce qu'il faut, mais nous parlons ici de tout à fait autre chose:

Javascript n'est... qu'un langage de script, et HTML n'est qu'un langage de mise en forme de texte.

Dans certains cas (entre autres, lorsque tu envisages une architecture client / serveur), HTML + javascript est parfaitement adapté, et dans d'autres, ce n'est pas le cas.

Forcer l'utilisation d'une telle architecture dans les cas où elle est inutile est purement et simplement aberrant.

[yan]

Comme navigateur internet, ou pour créer un navigateur webkit est exactement ce qu'il faut, mais nous parlons ici de tout à fait autre chose:

Javascript n'est... qu'un langage de script, et HTML n'est qu'un langage de mise en forme de texte.

Dans certains cas (entre autres, lorsque tu envisages une architecture client / serveur), HTML + javascript est parfaitement adapté, et dans d'autres, ce n'est pas le cas.

Forcer l'utilisation d'une telle architecture dans les cas où elle est inutile est purement et simplement aberrant.

Alors pourquoi parler d'adobe asl???
Car j'ai beau regarder depuis tous à l'heure et c'est la même philosophie.... Ou alors j'ai raté un truc...
T'as un langage déclaratif (Html <=> adam&eve) qui définie l'ihm et du fait du binding pour que le langage déclaratif puisse appeler tes fonctions.

Par contre je n'ai pas compris où est le renderer de l'ihm...

Le webkit permet en plus d'y ajouter un peu de code JS pour controller le tous.

Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées

Dsl mais je ne comprends vraiment pas pourquoi tu lui dit cela... Tu devrais réfléchir sur son point de vue (que je partage)...

Pour info, sur les mobiles le webkit commence à être utilisé pour l'ihm des appli en java, objectif-C,...
Et quand tu regarde, ce n'est pas aussi abérant. Une même ihm et un code source spécifique à chaque plateforme.
http://www.appcelerator.com/
http://phonegap.com/

Il en existe d'autre

[Invité]

afficher des tables, masque de saisie, presentation de données etc
et bien la c'est tout a fait possible et c'est rapide.
Je le fais deja avec Qt webkit.

C'est possible. Mais le truc, c'est que quand le volume des données ou la complexité des traitement, le desktop et la web application ne se "scalent" pas de la même façon.

En gros, sur une application internet, la bande passante (les volumes échangés entre le moteur et l'interface) coute cher, le calcul moteur pas. Sur une appli desktop, c'est l'inverse... (on est bien moins patient)

Du coup, si tu a un volume raisonnable de données, mais dont le calcul est long, en web tu fais tout en une fois, en desktop, tu fais plutôt à la demande (tu calcules seulement ce que tu as besoin d'afficher, par exemple).

Inversement, sur un très gros tableau lu directement, tu peux tout calculer d'un coup en desktop (et après tout va vite), alors qu'en web, il va falloir jouer du cache (et ca complique singulièrement l'appli)

Dans pas mal de cas, cela va changer en profondeur l'architecture de l'appli.

Ajoute à cela que l'attente de l'utilisateur n'est pas la même : 10 secondes d'attente dans une appli web, pas de souci, 10 secondes d'attente en desktop, ca parait nettement plus long.

Maintenant, je suis d'accord avec tes remarques sur le moteur de rendu. Je ne suis pas certain que html soit assez puissant, mais si on disposait d'un standard permettant de modéliser toute UI, web ou desktop, ce serait effectivement incontournable... (et on écrirait un "interpréteur" pour ce langage dans le cadre du framework desktop, pas besoin de navigateur pour ca).

[EDIT] je ne suis pas certain que les UI déclaratives répondent à cette question, ceci dit, j'ai l'impression que, comme leur nom l'indique, elles répondent davantage à la question de la définition de l'interface qu'à celle du rendu, et, à mon avis, ce sont des choses différentes[/EDIT]

Francois

[koala01]

HTML: Hyper Text Marked up Language : langage balisé de liens hypertexte.

Il s'agit d'un langage merveilleux en ce qui concerne la description de la manière dont un texte doit être affiché, mais son rôle (et ses objectifs) s'arrêtent là.

On peut avoir des IHM déclaratives, mais il n'y a rien à faire: avec ses (environs) 120 balises très (trop ) spécialisées, HTML n'est pas suffisant pour rejoindre l'ensemble des cas que l'on risque de rencontrer dans la création d'une IHM.

Contrairement à HTML, XML (qui est le langage utilisé par ASL) est beaucoup plus souple quand aux informations qu'il permet de représenter.

Il ne faut donc pas baser une argumentation sur le fait que XML est fort proche (du fait des balises) de HTML pour dire que l'on peut utiliser HTML pour tout et n'importe quoi...

[Invité]

Je veux dire, tant qu'à les séparer à l'implémentation, pourquoi l'utilisateur ne pourrait pas en profiter pleinement ?
Et quel est donc l'intérêt suprême du widget qui m'échappe à ce point ?

Dans la bassitude de ma compréhension, j'espère que je fais au moins un peu avancer le débat >< ! Sinon, j'en suis vraiment désolé.

Surtout pas! Depuis le début, je pousse pas mal cette discussion sur les widgets, parce je crois que c'est le coeur du débat... Si on arrive à une idée nouvelle, et qu'on s'entend dessus, on a les bases d'un projet. Si on n'y arrive pas, je ne crois pas que ce sont les questions d'implémentation, ou les listes de courses, qui nous sauveront.

Le problème du widget, pour moi, c'est moi "à quoi ca sert" que "comment s'en passer"...

Pour permettre à l'utilisateur de définir son IHM, et au framework de la transformer en code, il faut la définir, la modéliser, si tu veux. Et pour l'instant, dans toute cette discussion, même si on dit qu'on aimerait bien larguer les widgets, on parle toujours de boutons, de menus, de souris qui passe au dessus, de clics sur des éléments d'interface... bref, de widgets...

C'est ce qu'on disait ce matin avec El Pedro : quelque part, on se dit que le widget est probablement réducteur, et qu'on peut faire des tas de choses dans une interface qui ne se résument pas à des boutons, et des cases à cocher... Mais voila, on en revient toujours à nos boutons, nos listes, nos menus,... nos widgets !

Le discours de Qt, dans la video postée par yan, essaye d'étendre le débat, en parlant de "zones" sur l'interface... Mais je ne suis pas certain qu'il renouvelle le genre.

Maintenant, il y a une chose qu'on peut modifier, c'est cette idée d'une interface formée d'un composite de widgets : une appli contient des fenetres, qui contiennent des panels, qui contiennent des boutons et d'autres panels qui contiennents des listes, avec dedans des boutons...

Mais, une fois de plus, elle est quand même drolement pratique, cette vision arborescente de l'interface. Alors, si on la remplace, c'est par quoi?

Francois

[metagoto]

HTML: Hyper Text Marked up Language : langage balisé de liens hypertexte.

Il s'agit d'un langage merveilleux en ce qui concerne la description de la manière dont un texte doit être affiché, mais son rôle (et ses objectifs) s'arrêtent là.

A HTML il faut en fait ajouter css + javascript + DOM

Ce "power trio" tend à s'affranchir du simple cadre des navigateurs web pour déferler sur les autres platforms/hosts. Pensons à XUL ou les trucs de Qt ou encore les trucs d'Adobe AIR/flex.
Et ça sera pire avec HTML5 dans quelques années.

Je ne dis pas qu'il faut adopter webkit, je pense juste que cette approche n'est pas dénué de bon sens.

[koala01]

A HTML il faut en fait ajouter css + javascript + DOM

Au niveau des CSS, on ne peut déjà modifier qu'un certains nombres d'attributs clairement défini pour chacune des balises...

Tout ce qu'elles font, c'est simplement de permettre de modifier... la manière dont le texte est mis en forme.

d'un autre coté, les deux seules balises qui seraient, éventuellement, utilisables dans HTML (et encore), ce sont div et span, car il y a des restrictions très fortes sur l'utilisation des autres (bon, je ne parle pas de la possibilité d'imbriquer des tableau pour forcer à la mise en page, car c'est une technique réprouvée par toute la communauté du développement web )

enfin, javascript est très bien en cela qu'il s'agit d'un langage (principalement) événementiel, mais, encore une fois, il ne peut pas fonctionner seul (il aura régulièrement besoin de renvoyer une ou l'autre requête à un serveur pour pouvoir aller plus loin)...

Et, qu'il s'agisse de javascript ou d'ajax, on tourne toujours toujours autour d'une architecture client / serveur

Ce "power trio" tend à s'affranchir du simple cadre des navigateurs web pour déferler sur les autres platforms/hosts.

Mais toujours sous la forme d'une architecture client / serveur...

Pensons à XUL ou les trucs de Qt ou encore les trucs d'Adobe AIR/flex.

Si ce n'est que XUL et toutes les autres techno déclaratives sont beaucoup plus proches de XML que de HTML...

Ce n'est pas parce que les balises sont représentées entre < et >, ni parce que leur fermeture est représentée par </ > qu'il faut en déduire que c'est du HTML amélioré.

Si c'est le raisonnement que tu suis, d'accord, nous pouvons utiliser des balises indiquées entre [ et ] ou entre... ^ ^, pourquoi pas (après tout, du moment que l'on défini un caractère d'ouverture et un de fermeture...)

Je ne dis pas qu'il faut adopter webkit, je pense juste que cette approche n'est pas dénué de bon sens.

L'approche qui consiste à avoir un arbre composé d'une racine commune, de noeuds et de feuille et de pouvoir situer facilement la fin de chacune de ces parties est excellente...

Mais HTML ne pourra en aucun cas suffir... et là est tout le problème

[koala01]

Surtout pas! Depuis le début, je pousse pas mal cette discussion sur les widgets, parce je crois que c'est le coeur du débat... Si on arrive à une idée nouvelle, et qu'on s'entend dessus, on a les bases d'un projet. Si on n'y arrive pas, je ne crois pas que ce sont les questions d'implémentation, ou les listes de courses, qui nous sauveront.

Le problème du widget, pour moi, c'est moi "à quoi ca sert" que "comment s'en passer"...

Pour permettre à l'utilisateur de définir son IHM, et au framework de la transformer en code, il faut la définir, la modéliser, si tu veux. Et pour l'instant, dans toute cette discussion, même si on dit qu'on aimerait bien larguer les widgets, on parle toujours de boutons, de menus, de souris qui passe au dessus, de clics sur des éléments d'interface... bref, de widgets...

C'est ce qu'on disait ce matin avec El Pedro : quelque part, on se dit que le widget est probablement réducteur, et qu'on peut faire des tas de choses dans une interface qui ne se résument pas à des boutons, et des cases à cocher... Mais voila, on en revient toujours à nos boutons, nos listes, nos menus,... nos widgets !

Le discours de Qt, dans la video postée par yan, essaye d'étendre le débat, en parlant de "zones" sur l'interface... Mais je ne suis pas certain qu'il renouvelle le genre.

Maintenant, il y a une chose qu'on peut modifier, c'est cette idée d'une interface formée d'un composite de widgets : une appli contient des fenetres, qui contiennent des panels, qui contiennent des boutons et d'autres panels qui contiennents des listes, avec dedans des boutons...

Mais, une fois de plus, elle est quand même drolement pratique, cette vision arborescente de l'interface. Alors, si on la remplace, c'est par quoi?

Le fait, c'est:

• que widget, par définition, un terme totalement abstrait, pour la simple raison qu'il représente... un type tout à fait abstrait
• que, quoi que nous fassions, quelle que soit la manière dont on en parle de manière générale, on en reviendra toujours (parce que c'est "dans notre culture") à parler de fenêtre, de menu, de bouton, de... widget... parce que ce sont les termes dont nous avons l'habitude

Maintenant, faut il *réellement* que toute surface que l'on peut tracer dérive systématiquement de manière publique d'une classe mère unique

C'est, certainement, la pratique dont on a le plus l'habitude, mais je ne suis pas convaincu pour la cause que ce soit la *seule* manière de voir.

Comment pourrait on s'en passer en travaillant sur plusieurs politiques clairement distinctes: le tracé (moteur de rendu), la "gestion du contenu" (les données que chacun est susceptible de représenter), la "connexion de signaux" et la gestion des "caractéristiques intrinsèques" (couleur, taille, ...)

[Luc Hermitte]

Contrairement à HTML, XML (qui est le langage utilisé par ASL) est beaucoup plus souple quand aux informations qu'il permet de représenter.

Que nenni.
Pas de XML dans Adobe.ASL. Mais deux langages spécialisés qui ressemblerait plus à du JSON (sans en être) qu'à du XML.

Et +1 à la maigre sémantique derrière l'HTML. Si c'est si suffisant que cela, on ne verrai pas apparaitre des choses comme GWT/GXT.
(Je vous invite à jouer avec Adobe.begin. Il permet de faire glisser des paires de fichiers Eve+Adam sur une appli qui les rend aussitôt. Ce qui permet de prototyper les IHMs sans rien recompiler. Cela donne une bonne idée des possibilités et des limitations de leur approche)

[dtrosset]

Le fait, c'est:

• que widget, par définition, un terme totalement abstrait, pour la simple raison qu'il représente... un type tout à fait abstrait
• que, quoi que nous fassions, quelle que soit la manière dont on en parle de manière générale, on en reviendra toujours (parce que c'est "dans notre culture") à parler de fenêtre, de menu, de bouton, de... widget... parce que ce sont les termes dont nous avons l'habitude

Non seulement de ce dont nous avons l'habitude, mais également ce que nous voulons montrer.

Maintenant, faut il *réellement* que toute surface que l'on peut tracer dérive systématiquement de manière publique d'une classe mère unique

Là on est dans le cœur du problème si j'ai bien compris. À quoi peut bien donc servir cette classe mère commune*?

Tout d'abord à la gestion de la mémoire. En effet, quand un widget est ajouté à un widget parent (pas dans le sens héritage de classe, mais dans le sens hiérarchie de zones à l'écran*: fenêtre, groupe, bouton, texte), c'est le parent qui en devient propriétaire et qui se charge de le désallouer lorsqu'il sera lui même désaloué. Si on doit le faire à la main, ce sera peut-être plus difficile. Toutefois, si ces widgets enfants pouvaient être des membres du parent, membres directs j'entends, sans pointeur, la gestion serait faite toute seule.

Ensuite à la gestion de la surface gérée. C'est à dire que le widget va s'occuper de dessiner à l'écran une certaine surface, habituellement rectangulaire. Son widget parent ne s'en occupe pas. Mais pour cela, un widget parent a besoin de savoir où sout placés ses enfants, et pour cela, il fait appel à des fonctions ou variables membres connues, habituellement définies dans la classe widget mère commune. Cependant, en utilisant les templates pour effectuer ce layout, il doit être possible de se passer de la mère.

Enfin, le widget est utilisé pour tout un tas de paramètres plus ou moins communs à différents types de widgets*: la visibilité, la police utilisée, la possibilité de focus clavier,*… Qui pourraient être ajoutés à chaque widget qui en a vraiment besoin.

C'est, certainement, la pratique dont on a le plus l'habitude, mais je ne suis pas convaincu pour la cause que ce soit la *seule* manière de voir.

Comment pourrait on s'en passer en travaillant sur plusieurs politiques clairement distinctes: le tracé (moteur de rendu), la "gestion du contenu" (les données que chacun est susceptible de représenter), la "connexion de signaux" et la gestion des "caractéristiques intrinsèques" (couleur, taille, ...)

Je reste assez proche de l'implémentation parce qu'au final, il faudra bien l'implémenter en C++.

Pour finir, une petite remarque sur la distinction librairie et framework. Dans ma conception de ces deux notions, la librairie est un composant que je peux ajouter à mon programme pour l'y utiliser. Le framework, à l'opposé, c'est mon programme qui vient s'insérer à l'intèrieur. La différence, énorme, entre les deux, c'est que si je veux utiliser 2 ou 3 librairies différentes dans mon programme, c'est possible. Par contre, créer un programme qui utilise plus d'un framework, ce n'est pas possible.

Et donc dans cet esprit, je souhaiterais qu'un tel projet reste une librairie. L'IHM n'est pas forcément l'élément qui doit apporter le framework.

[Klaim]

De même, je préférerai juste une bibliothèque, qui soit très spécialisée et du coup très efficace dans son domaine, plutot qu'un framework.