Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?
Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).
Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.
Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.
Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.
Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?
Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.
J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).
Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.
Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.
Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs.
Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.
Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)
[^] # Re: Troll
Posté par groumly . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 5.
Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?
Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).
Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.
Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.
Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.
Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?
Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.
J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).
Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.
Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.
Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.
Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)