Merci pour ce retour hyper rapide : )
Par overhead j'entendais sur-consommation cpu, et donc latence côté device au lieu du traditionnel network.
C'est un peu litigieux comme remarque de ma part car cela concerne uniquement les dinosaures de cet environnement, aka * != webkit (trident et gecko inclut…). Mais bon c'est une réalité tout à fait présente aujourd'hui et pour encore quelques années at least car on ne passe pas à côté de 10% d'audience parce que le projet est beau techniquement.
la chaîne de compilation de Nanoko agrège l'ensemble des librairies et composants de votre application au sein de votre unique fichier HTML index.html
OK. Si je me mets dans le cas où mon appli sert des contenus variés et nombreux, je ne m'imagines pas une seconde tout mettre dans le même fichier HTML. Donc, il faut passer par un système de transition de page à page ? En un sens il faut réinventer la roue de la balise < a >, de HTTP ?
Quid du SEO dans cette configuration ? Dans le fichier index j'aurais trop de donnée, dans les autres fragments, probablement pas assez.
Nanoko est orienté développement client et non serveur
Oui j'ai bien compris. Mais je croit qu'il faut que je teste par moi même car je n'envisage pas ce type de dév sans le déploiement d'un serveur web. Dès lors de deux choses l'une, soit c'est compliqué et ce sera fais par un spécialiste sur un serveur centrale partagé à l'ensemble des dév, soit ce sera fais par chacun des développeurs car le gap technique est faible ou acceptable.
Et par ailleurs à parler de serveur, quid de la couche business (tout le foutoir en json pour rapatrier de la donnée personnalisée à l'utilisateur) à rajouter dans ce genre d'architecture ?
Fournissez vous des clues ou des bonnes pratiques avec votre package ?
Bon sinon j'aimes bien, si j'avais rien d'autres à foutre je crois que j'aurais volontier mis la main à la pâte de votre projet car at least nos objectifs convergent en certains points. Sait on jamais..
Par contre je sais que je hais les réseau sociaux, donc il est peu probable que je suivent vos aventures en ces lieux de débauche :°)
[^] # Re: Intéressant
Posté par maboiteaspam . En réponse à la dépêche Nanoko, un framework JavaScript open source pour applications web & mobiles. Évalué à 3. Dernière modification le 18 février 2013 à 13:22.
Merci pour ce retour hyper rapide : )
Par overhead j'entendais sur-consommation cpu, et donc latence côté device au lieu du traditionnel network.
C'est un peu litigieux comme remarque de ma part car cela concerne uniquement les dinosaures de cet environnement, aka * != webkit (trident et gecko inclut…). Mais bon c'est une réalité tout à fait présente aujourd'hui et pour encore quelques années at least car on ne passe pas à côté de 10% d'audience parce que le projet est beau techniquement.
OK. Si je me mets dans le cas où mon appli sert des contenus variés et nombreux, je ne m'imagines pas une seconde tout mettre dans le même fichier HTML. Donc, il faut passer par un système de transition de page à page ? En un sens il faut réinventer la roue de la balise < a >, de HTTP ?
Quid du SEO dans cette configuration ? Dans le fichier index j'aurais trop de donnée, dans les autres fragments, probablement pas assez.
Oui j'ai bien compris. Mais je croit qu'il faut que je teste par moi même car je n'envisage pas ce type de dév sans le déploiement d'un serveur web. Dès lors de deux choses l'une, soit c'est compliqué et ce sera fais par un spécialiste sur un serveur centrale partagé à l'ensemble des dév, soit ce sera fais par chacun des développeurs car le gap technique est faible ou acceptable.
Et par ailleurs à parler de serveur, quid de la couche business (tout le foutoir en json pour rapatrier de la donnée personnalisée à l'utilisateur) à rajouter dans ce genre d'architecture ?
Fournissez vous des clues ou des bonnes pratiques avec votre package ?
Bon sinon j'aimes bien, si j'avais rien d'autres à foutre je crois que j'aurais volontier mis la main à la pâte de votre projet car at least nos objectifs convergent en certains points. Sait on jamais..
Par contre je sais que je hais les réseau sociaux, donc il est peu probable que je suivent vos aventures en ces lieux de débauche :°)