atomusk a écrit :



Sans besoin de perf particulière, et si une des contraintes est de faire une app pour toutes les plateformes, les appli web sont la solution la plus pragmatique …



D’autant plus avec Firefox OS " />







c’est ce que je dis le départ, je comprend les avantages, je regrette le choix tout de meme.







Jean Sébastien Gwak a écrit :



Tu n’es pas le seul, je pense pareil. (Point de vue dev aussi)

C’est surtout le nombre de techno qui doivent être connu et qui bougent trop souvent qui me hérisse un peu.







" /> je pense exactement la meme chose, surtout que tu apprends un framework, avec un peu de chance tu as 6 mois pour que tes connaissances sur ce framework deviennent obsoletes, je caricature mais pas loin quand meme







ErGo_404 a écrit :



Je suis d’accord avec toi mais c’est quasiment toujours le temps et donc l’argent qui priment. Une webapp c’est plus rapide à coder, et une appli native n’est pas toujours la garantie d’un code plus sain/plus propre ni d’une appli plus stable.



C’est d’autant plus vrai pour les applis basées sur des services complètement en ligne.







Et oui malheureusement, on préfere aller vite que de faire bien (ce qui des fois pourrait aller plus vite que de faire vite mais certain ont du mal a intégrer que le temps de maintenance d’un projet mal foutu peut vite explosé …)



Peu importe les technos utilisées, rien n’assure qu’un code soit plus sain/stable de toute facon si ce n’est l’expérience et le bon sens et encore meme la ca depend de comment pense le ou les concepteurs de l’appli une bonne pratique pour l’un n’est pas forcément comme tel pour un autre, exemple: Rien que récemment, je me suis penché sur des technos comme entity framework en C# (j’ai du retard, je sais). Or ayant plutot une bonne connaissance des principes de bases du dévelloppement, je me suis dit, EF, c’est bien mais c’est une tres grosse dépendance a un framewrok spécifique quand meme … je me suis posé la question de comment résourdre ce probleme alors. Je suis tombé sur le pattern “repository”, qui n’est autre qu’une facade au final.



et la, le drame … le nombre de blog Pour et Contre ce pattern sont légion tous avec de bons et moins bons arguments et au final j’etais un peu perdu a la lecture de ces differents blog les pros te dise si c’est bien car ca cache EF au reste de l’appli, entre autre de le rendre Testable plus facilement etc… les contre te disent que EF c’est deja une abstraction de l’acces aux BDD et que y’a pas besoin d’abstraire plus … surtout que EF implémente deja le repository …



or, je suis contre les arguments “contre” car au final, apres mure reflexion, le repository n’est pas la pour abstraire EF mais l’isoler et donc le rendre dispensable au reste de l’appli si un jour tu change d’orm ou autre raison …. mais d’autre ne vont pas partager cette vison, donc difficle de dire qu’est-ce qu’un projet bien foutu au final. Désolé pour l’exemple long …







zogG a écrit :



Dans un monde où chaque constructeur va vouloir faire les choses à sa sauce, j’ai du mal à voir le soucis quand les devs (ceux qui font le boulot au final donc) cherchent à rationaliser le process.



Et pour les frameworks, je suis pas sûr de comprendre, le web c’est pas 50000 technos, surtout si on se focalise sur la partie “client”. Par contre des framework il y en a, mais pour du natif aussi il y en a. Tout le monde ne bosse pas de la même manière, chacun va avoir ses avantages/inconvénients, avoir le choix des outils, difficile de considérer ça comme un problème, non?



La seule question c’est la performance, pour le reste…



(et pour les perfs, Facebook sort React Native, qui permet de faire du natif à partir des technos web -je simplifie un peu " />-)







Aucun soucis avec le fait de rationnaliser … au contraire, c’est les techno web qui me gene perso. Y’apas 50000 technos ? Tu fais beaucoup de web ? j’en fait en c# et aujourd’hui c’est asp.net mvc, jquery/javascript, entity framework, angular, knockout …. et la c’est le minimum de la plupart des projet/annonce de job … en client lourd, je suis désolé mais j’ai besoin de WPF (ou Winform) et entity framework pour faire la meme chose (sauf le coté multiplateforme évidemment)

et au final, en programmant par layer et une archi SOA tu dois pouvoir facilement faire du multiplateforme en ayant ton business layer et ton data access layer dans une techno particuliere exposé via un service et ensuite un UI layer spécifique a chaque plateforme qui attaque le service … tu devras apprendre aussi pas mal de langage mais au final tu as une appli plus performante, mais ce scenario ne couvre peut etre pas tout les cas, je te l’accorde.

zogG a écrit :



Tu n’as pas “besoin de”, tu “utilises”, c’est différent.

Et je pense que tu te places dans un contexte qui n’est pas celui de Google, tu parles de clients lourds, Google vise les clients legers, D’où le besoin de proposer le contenu en offline, même sur une “webapp”. Dans ce contexte utiliser des technos web est quand même logique (au moins au niveau du concept, et techniquement) puisque c’est exactement ce a quoi répondent ces technos.



Evidemment les deux soucis sont : les performances (mais à mon avis ça sera très vite de l’histoire ancienne) et l’UX. Le “un pour satisfaire tout le monde”, je n’y crois pas.



Pour du client qui ne fait que consulter des données sur un service lambda, réinventer la roue sur chaque plateforme où tu veux poser tes valises, c’est quand même une perte de temps et d’argent monumentale. Le Web a quand même été fait pour ça. Qu’il existe des centaines de frameworks, c’est une bonne chose, pour du client lourd aussi il existe des centaines de languages/frameworks/outils…. et? C’est très bien.



edit: Enfin je veux pas avoir l’air de défendre ces technos par rapport au natif, les deux ont leur avantages, perso si j’ai le choix je préfère le natif, mais le choix de faire du web ne me choque pas, loin de là.









Client lourd ne veut pas dire déconnecté … tu peux tres bien faire du client lourd en ayant des echanges entre applis. D’ailleurs des applis mobiles en natif, pour moi, c’est du client “lourd” pas du léger. Apres peut etre que je fais un mauvais amalgame entre client leger = web tu me diras …



Et non, c’est bien “besoin” aujourd’hui, en client lourd (donc poru moi WPF/Winform ou autre) tu veux faire un affichage asynchrone, tu n’en en aucun cas besoin d’une techno supplémentaire pour que cela fonctionne en client léger (web) si …



Apres, effectivement meme en client lourd tu peux etre amené a utilisé des paquet nuget, par exemple pour faire du MVVM mais c’est relativement light, je n’ai jamais vu de projet “client lourd” ayant autant besoin de techno pour etre opérationnel qu’un projet web, apres certain framework en web sont peut etre du luxe et pas indispensable pour avoir une appli équivalente en terme de possibilité sauf que tu dois réinventé la roue comme tu dis, je suis d’accord mais cela t’oblige a connaitre tout ses framework aussi et c’est bien ce qui me gene car du cote client lourd toutes ces fonctionnalités sont deja incluses de base voir elle ne sont meme pas une veritable question (par exemple l’affichage asynchrone n’a rien de special en WPF.



Je ne dis pas que cela me choque, je dis que ca m’herisse le poil " />



On fait du web parce que c’est hype, et pour moi c’est une techno qui a la base n’etait pas faite pour ce quoi elle est utilisée aujourd’hui c’est comme une roue de vélo qui aurait 50 rustines … il aurait mieux fallu avoir une nouvelle technos plus “universelle” cote natif, un peu comme java mais … “mieux” si tu vois ce que je veux dire, un peu comme le C presque qui si je ne m’abuse est compris par toute les plateformes mais un peu plus dev-friendly a la sauce c#