Reprise du message précédent :

 
Le vrai problème à la base, c'est Android pas foutu de fournir des perfs convenables. C'est surprenant de voir Google être constamment à la ramasse.
 
LinkedIn a le même soucis avec cette plateforme, alors que ça marche bien sur iPhone.

Vous avez de bonnes ressources pour débuter avec d3 ?

Tu veux faire quoi avec d3 ?
juste des graphs ? car tu as une lib qui permet de simplifier la génération de graphs avec d3 : http://nvd3.org/
Sinon pour du angular tu as angular nvd3 : http://krispo.github.io/angular-nvd3/#/
 
Mais tout ça pèse lourd en JS, si tu veux quelque chose d'alléger tu as chartist : https://gionkunz.github.io/chartist-js/
 
Après des ressources D3 c'est pas ce qu'il manque :  
https://www.dashingd3js.com/table-of-contents

Je veux surtout faire des graphes.
J'utilise ember, pas angular

Bah chartist pour du graph standard, essaye le tu m'en diras des nouvelles, j'ai pas eu le temps de tester, mais d3 c'est SUPER lourd.

C'est sûr que c'est le problème d'android .
Mais dans ce cas, bizarre que al solution soit côté code .

Les exemples sont géniaux

Je vais regarder

Je sais pas si c'est sérieux ou sarcastique ou pas, donc au cas où, c'est un problème reconnu de Chrome/Android, qui affecte également Angular (et probablement les webapps en général), quand le code est hautement polymorphique le navigateur optimise et déoptimise les mêmes fonctions sans arrêt: https://bugs.chromium.org/p/v8/issu [...] d=2935#c18

Un peu les deux, parcequ'on est vendredi.
Si tu as un problème qui touche entre 40 et 80% de ta population, tu le corriges  ou tu le contourne, même si il est lié a la plateforme sous jacente. Ton utilisateur s'en fout de savoir la cause , trello fonctionne, mais pas discourse alors que les deux sont des webapp
 
Au final, ça leur prendra de toute façon moins d'energie que de passer en natif et de maintenir plusieurs bases de code différentes dans des langages différents

 
Atwood trash pas mal sur Twitter à propos de la perf Android...d'ailleurs il ne blâme pas que le système, il blame surtout la perf monocore des CPU typiquement présent dans les téléphones Android

Ou tu considères que le ROI est pas là et tu abandonnes cette plateforme (Atwood a commenté en ce sens 2-3 fois dans ses divers posts sur les performances Ember/Android en 2015, qu'ils étaient partis du principe que les perfs web mobile allaient converger sur les perfs web desktop, et qu'ils pouvaient réviser ce principe ou ne supporter que les plateformes où il tenait)

 
Ember Charts

 
Si la plateforme n'évolue pas, tu es bien obligé de t'adapter. Ils vont pas se mettre à réécrire un OS mobile

C'est pas compatible avec les dernières versions d'ember et ember cli, non ?

meme sur un S6 , les persf web sont largement inférieur à un ios de génération précedente
 

Sauf que la part d'android ne baisse pas, et que les perfs ne progressent pas des masses non plus. Avoir une position tranchée, c'est bien, mais ce n'est pas toujours tenable.  
 
android a pris quasiment 8 points en un an sur mobile http://gs.statcounter.com/#mobile+ [...] 501-201601

D'un autre côté, safari a de meilleurs persf, mais traine sur l'implémentation de nouvelles fontionnalités qui pourront changer enormement de choses : service worker (enfin un ode offline bien pensé) webrtc ( visio) ,...

C'est pas en opposition, je note juste que sortir complètement de ce marché est une possibilité, qu'ils ont considéré Et si le marché te coute plus cher que ça te rapporte, c'est une option tout aussi tenable que l'inverse.

Autant faire du natif si tu réduis ton marché à IOS.

Je suis le seul a penser qu'utiliser des usines à gaz type angular pour du mobile est une erreur à la base?
J'ai l'impression qu'au lieu de limiter le nombre de couches logicielles il critique le processeur, qui, sur mobile, doit travailler le moins possible.

Bah non, c'est Desktop + iOS.

L'application n'est pas que mobile, le problème n'existe pas sur Safari/iOS, et comme cité un peu plus haut il y a 2~3 ans ils sont partis du principe que les perfs web mobile allaient grosso merdo rattraper les perfs web bureau de l'époque, ce qui était clairement un pari mais c'est maintenant le cas (à peu de chose près) sous iOS pour leur workload.

 
Justement, à partir de là ça me parait discutable comme choix. Soit parce que les mobiles n'embarquent pas des processeurs puissants pour augmenter l'autonomie, soit parce que on veut le solliciter le moins possible pour la batterie, ou les deux.

 
Ça arrive
 
Ça devrait pas demander trop d'effort à rendre compatible avec Ember 2.0 ( c'est déjà un Ember CLI addon )

 
Je ne vais pas parler d'Angular en particulier, mais contrairement à toi, je pense que c'est l'avenir ( mais pas une réponse à tout ).

 
Je pense aussi que c'est l'avenir malheureusement, les développeurs se facilitent toujours la tache si ils peuvent se le permettre.

Je suis sur un gros projet avec Ionic, étant dev mobile j'étais un peu sceptique, et franchement sur le devices récents je suis assez impressionné, aussi lourd que puisse être Angular. La version 2 est prometteuse.

Comme tous les framework si tu l'utilise mal, c'est une usine à gaz, sinon c'est juste un outil.
C'est pas parce qu'un techno est  largement et mal utilisée par le "garnd public des developpeurs lambda", que ca t'empeches, toi, de bien l'utiliser.

 
Mouais. De base ca rajoute du code donc des lenteurs incompressibles. Meme en supposant que ca gene pas, je choisis pas toujours les developpeurs qui bossent avec moi, et un outil que la plupart des devs vont mal utiliser ca me crispe de base. Actuellement je me heurte a des "ca marche comme ca" de la part de mes collegues qui font les trucs a minima. Et faire a minima quand on capte que dalle au mecanisme sous-jacent du framework ca donne des anti-patterns, des plats de spaghettis, etc...
Ca me gene aussi de penser que chaque framework ayant sa philosophie, il faut prendre le temps de lire toute la doc avant de toucher a la moindre ligne de code pour faire propre. Et ca, personne le fait quand t'es en rush OU que t'as pas l'envie de bien faire. Par experience, c'est ce qui arrive tout le temps.
Si je pouvais imposer un truc sur mon projet actuel ce serait pour la partie front de coder sans aucune lib en js pour toute la partie qui ne touche pas au DOM, de facon a forcer les devs a reflechir avant de coder a ce qu'ils ont vraiment besoin de faire. Un exemple concret: l'appli permet de trier une liste de donnees assez lourdes. Au lieu de reflechir a creer une liste avec les donnees utiles (un nouveau modele pour la couche logicielle en question quoi) et ne trier que ca, c'est tellement facile d'appeler lodash.pluck et recuperer le resultat sans se poser de question. Combien de code est execute? On en sait rien, mais comme on a eu juste a taper une ligne, ca va quoi. Et puis on va binder a la vue la meme liste bien lourde, osef de la conso memoire. Au final, ce genre de trucs ajoutes les uns aux autres donne des lenteurs chiantes sous android, et encore plus chiantes a corriger vu que c'est des tonnes de petites optims a retrouver a droite et a gauche.  
Avec leur bite et leur couteau, ils auraient ete obliges de se taper le code de lodash.pluck et se poser la question de si c'est pas un peu crade le code qu'ils sont en train de faire, et se seraient sans doute rendus compte que la vue n'a pas besoin de toutes ces proprietes. La avec angular et le binding automatique je suis meme pas sur que ce soit venu a l'esprit de qqun.
Bref les frameworks magiques c'est cool pour la productivite et les developpeurs kiffent pouvoir se concentrer sur le code metier, mais je trouve que c'est trop souvent au detriment des perfs et de l'experience utilisateur.

Ton raisonnement est tout à fait logique pour un site pas trop compliqué avec une equipe de développeur assez restreinte.
 
Pour le reste, il y a Ember

Chuis d'accord avec youmoussa : pas la peine de sortir les gros fw sur les petites app
 
Mais passée une certaine taille, il devient difficile de tout faire a la main, ca crée plus de pb que de solutions

Je travaille sur une app ecrite par 5 devs front sur 2 ans. Donc pour moi une grosse app.  
Du coup vous feriez quoi vous pour ce genre de projet, si vous deviez travailler avec des devs faineants?

Mise en place d'un versionning (GIT au moins)
Mise en place des Pull Request, une feature, un bug, etc.. est développé dans une branche, et une PR est obligatoire pour que la branche puisse être mergée dans la branche master, donc les mecs seront limités dans la merde qu'ils feront
Mise en place d'un process agile, faire un daily meeting tous les matins.
 
etc...

Tout ca est deja en place Mais y'a pas de lead technique, donc toute le monde committe ce qu'il veut Du coup en debut de projet je me fais jeter lors des codes review, ils voient pas l'interet de faire bien du moment que "ca passe". Ou alors ils ont pas la meme vision que moi de la qualite du code, j'en sais rien en fait. Et quand on entre en phase de maintenance comme maintenant, c'est le drame...

Je te suggère de prendre le pouvoir et de les virer. Je suis sérieux.

Edit pour être un peu plus complet: certaines personnes sont influençables et si elles étaient avec des collègues sérieux, elles se prendraient au jeu de l'élitisme de la qualité, donc tu n'as pas forcément besoin de virer tout le monde pour améliorer les choses, juste ceux qui tirent le plus vers le bas, et recruter quelques uns qui tirent vers le haut.

 
Tu as donc la réponse à ta question
 
On dirait l'expérience d'un pote à moi en ce moment.
 
L'autre option est de prendre tes jambes à ton cou.

C'est tes commits qui se font jeter ? Je sais pas si c'est pire que les mecs qui débarquent avec un "LGTM" alors que tu sais pertinemment qu'ils ont regardé le truc de loin.

Si ca se trouve, vous faites tous de l'over engineering.

 
Non c'est mes remarques qui se font jeter. Je me fais encore chambrer un an plus tard parce que je leur avait demande de rendre des objets immutables, juste apres leur avoir explique ce qu'etait un objet immutable. Tuez moi ptain.

 
fuis

C'est comme d'hab : soit tu peux avoir l'appui du management et/ou des users (via le PO par exemple) parce que l'appli devient de plus en plus bordélique à gérer (typiquement, un gros ratage après une mise en prod peut t'aider), soit t'as rien et tout le monde s'en fout d'aller dans le mur.
Dans le dernier cas, t'es dans un environnement toxique et tu peux songer très sérieusement à aller voir ailleurs.
 
Vécu y a 1 an, heureusement y a un connard d'ici qui m'a filé un coup de patte pour m'en sortir

Yo!!
 
Je fais le front d'un site sous Symfony 2, du coup j'apprends les joies du Twig jusqu'ici j'avais fait que du WP (Et du Drupal 7 mais j'ai abandonné avec ce CMS daubesque, d'ailleurs le 8 est sous SF2/Twig faudra que je teste ça.. bref)
 
Là je sèche sur un truc, vous pouvez surement m'aider. Suivant où je rajoute du code HTML, j'ai droit à un plantage, enfin pas vraiment un plantage, c'est juste localhost qui loade dans le vide... et mon BrowserSync me sort un "[proxy error] parse error"
 
Pourtant voilà ce que je rajoute:

 
quand je vire <section>lol</section> ça fonctionne... je comprends pas.. on ne peut pas rajouter du code HTML à certains endroits ?