Google veut toujours plus séduire les développeurs sur Android et Chrome

Google veut toujours plus séduire les développeurs sur Android et Chrome

Applications web, applications pas web

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

20/11/2015 6 minutes
22

Google veut toujours plus séduire les développeurs sur Android et Chrome

Google tenait cette semaine son Chrome Dev Summit pour faire le point sur les technologies proposées aux développeurs web. L'éditeur a également publié la version 1.5 de son Android Studio. Qu'il s'agisse d'applications web ou non, Google veut se tenir prêt.

En termes de développement, Google avait changé la donne en publiant son Android Studio. Plutôt que de s‘appuyer sur l’IDE (integrated development environment) Eclipse et ses multiples modules, la firme avait fini par proposer son propre environnement, conçu spécifiquement pour créer des applications Android, avec une interface évidemment dédiée. Depuis hier, Google propose la version 1.5 de Studio, avec de multiples améliorations à la clé, même si la plupart se situent sous le capot.

Android Studio 1.5 : fiabilité et détection des fuites

Google met donc en avant une plus grande fiabilité générale, de meilleures performances ainsi que la correction de certains soucis gênants. Parallèlement, quelques nouveautés bienvenues font quand même leur apparition, surtout pour simplifier le travail des développeurs. C’est particulièrement le cas du Memory Profiler qui effectue une analyse automatique du code pour signaler quand des fuites de données diverses pourraient avoir lieu. Bien entendu, un tel outil ne peut pas trouver tous les cas possibles, mais il devrait faire gagner du temps au développeur en lui indiquant au fur et à mesure les problèmes les plus courants.

Android Studio 1.5 introduit également de nouvelles vérifications pour l’analyseur syntaxique. Google ne les décrit pas toutes, mais aborde l’exemple d’un développeur qui essaierait d’outrepasser les ressources décrites dans le manifeste.

La mise à jour peut être téléchargée directement depuis Android Studio. Le poids dépend de la version déjà installée, mais ne devrait pas dépasser les 80 Mo. Ceux qui veulent se lancer dans le développement d’applications Android peuvent également récupérer l’environnement depuis son site officiel.

Conseils et bonnes pratiques pour les développeurs

Plus tôt dans la semaine, Google tenait également son Chrome Dev Summit, sa grande conférence dédiée aux développeurs et liée à Chrome. Même si le navigateur et le système Chrome OS étaient évidemment à l’honneur, plusieurs des annonces concernaient l’ensemble des développeurs, y compris ceux qui s’attèlent surtout à créer des jeux et des applications Android. La conférence montrait en effet que la boutique Google Play devait à présent être considérée comme une plateforme complète, et des décisions comme celle d’indiquer la présence de publicités n’est donc pas une surprise.

Google a par exemple publié la version 2 de son « playbook » destinée aux développeurs d’applications. La seconde édition de « The Secrets to App Success on Google Play » peut être récupérée gratuitement depuis la boutique et contient un ensemble de règles et de conseils pour maximiser les chances de succès. Augmentation de la qualité, règles de bonne tenue, conseils pour plaire aux utilisateurs et les retenir ou encore tout simplement pour augmenter les profits sont ainsi au programme.

L’éditeur propose également deux nouvelles vidéos pour aider les développeurs sur des thèmes particuliers. On retrouve par exemple une série de dix astuces pour maîtriser pleinement la Developer Console de Google Play. Dix vidéos sont prévues en tout et Google en publiera deux par semaine.

Pour Google, les applications web « progressives » sont une partie du futur

Mais Google joue sur deux tableaux à la fois. Les applications Android sont évidemment un élément très important, mais l’éditeur se concentre également sur les applications web. Chrome Dev Summit oblige, plusieurs annonces visaient ce deuxième environnement, Google se dirigeant vers des applications web « progressives » : bâties avec des technologies du web uniquement, elles se présentent comme des applications classiques. Et d’annoncer plusieurs nouveautés pour aider les développeurs à se diriger vers cette formule.

Google met ainsi en avant les service workers pour aider les applications web à être plus stables, surtout en cas de mauvaise connexion. Deux nouvelles bibliothèques ont donc fait leur apparition, sw-precache pour l’App Shell et sw-toolbox pour le contenu dynamique. Le modèle de développement RAIL est lui aussi poussé sur le devant de la scène pour mesurer les performances réelles des applications web.

Les développeurs sont invités à surveiller certains paramètres particuliers, comme des temps de réponse qui ne devraient jamais dépasser les 100 ms, des animations qui devraient toujours se faire à 60 images par seconde, ou encore des temps de pause qui devraient être mis à contribution pour réaliser en arrière-plan des tâches secondaires, réparties par tranches de 50 ms.

Google indique que le fait de se concentrer sur un seul de ces critères peut parfois améliorer l’expérience utilisateur de manière très importante, avec une satisfaction pouvant grimper jusqu’à 16 %. Notez que le modèle RAIL est l’un des points sur lesquels se concentre la bibliothèque Polymer, dédiée justement aux applications web « progressives ».

Conseiller et former les développeurs de demain

Les progrès se font également sur les ressources disponibles pour les développeurs. Google continue d’enrichir ainsi ses Web Fondamentals, mais abreuve toujours le Mozilla Developer Network, qui rassemble une très copieuse documentation sur tout ce qui touche aux technologies du web.

En outre, Google s’est associé à Udacity pour proposer un nouveau programme d’apprentissage baptisé Nanodegree. Il n’ouvrira ses portes que le 8 décembre, mais on sait déjà qu’il se destinera surtout aux étudiants pour s’initier puis parfaire leur savoir-faire dans la création d’applications web. Le programme est copieux puisqu’il est conçu pour proposer 8 à 10 heures de travail par semaine sur une période allant de 9 à 12 mois. Le contenu de ce programme sera plus ou moins chargé en fonction de la formule retenue, qui peut être gratuite comme payante. Service workers, composants web, Gulp et autres font partie de ce cursus.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Android Studio 1.5 : fiabilité et détection des fuites

Conseils et bonnes pratiques pour les développeurs

Pour Google, les applications web « progressives » sont une partie du futur

Conseiller et former les développeurs de demain

Commentaires (22)


« Plutôt que de s‘appuyer sur l’IDE Eclipse et ses multiples modules, la firme avait fini par proposer son propre environnement […] »



Vous êtes sûrs ? Il me semble qu’Android Studio est construit par-dessus IntelliJ. Ou alors j’ai mal compris la phrase.


Y’a que moi qui a les poils qui ce hérissent des qu’on me parle de faire des appli web au lieu de faire des applis natives ??? <img data-src=" />



Je comprend que y’ai des avantages etc … mais franchement le “web” a toutes les sauces c’est du n’importe quoi je trouve … surtout avec 50000 technos differentes pour faire des trucs qui en natif ne te demande pas plus d’un ou 2 technos/framework …. bon c’est sur c’est plus “portable” mais quand meme, le web c’est a la base une techno statique a laquelle on a ajouté 50 layer pour faire du dynamique dans tout les sens, c’est degueu par moment je trouve. Enfin, c’est que mon opinion de dev …


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 <img data-src=" />



Quand on parle d’application web, c’est comme pour Firefox os ? Genre des appli codé en HTML ? Ou alors des appli qui nécessitent une connexion web ? (Ps : J’y connais rien et j’me disais que si c’est comme les applis Firefox ça peu avoir du bon, genre portages faciles).








Lafisk a écrit :



Y’a que moi qui a les poils qui ce hérissent des qu’on me parle de faire des appli web au lieu de faire des applis natives ??? <img data-src=" />



Je comprend que y’ai des avantages etc … mais franchement le “web” a toutes les sauces c’est du n’importe quoi je trouve … surtout avec 50000 technos differentes pour faire des trucs qui en natif ne te demande pas plus d’un ou 2 technos/framework …. bon c’est sur c’est plus “portable” mais quand meme, le web c’est a la base une techno statique a laquelle on a ajouté 50 layer pour faire du dynamique dans tout les sens, c’est degueu par moment je trouve. Enfin, c’est que mon opinion de dev …





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 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.


Des applis codées en HTML+javascript+ tout un tas de frameworks scotchés par dessus qui permettent de se rapprocher d’un comportement natif (gestion de notifications, cache des données et calculs en local, etc).


Oui c’est le cas, mais pour Eclipse ils avaient bidouillé un simple plugin alors qu’Android studio est plus une grosse surcouche à IntelliJ.



Et puis IntelliJ est quand même nettement meilleur !


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 <img data-src=" />-)


Pour du dev d’appli métier, news, réseaux sociaux, c’est essentiellement des listes d’objets, avec éventuellement un formulaire. Il n’y a aucun besoin de faire du natif.

C’est tout de suite différent quand on parle de jeux, accès à la caméra, ou dès qu’on a besoin d’un service persistent…








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 <img data-src=" />







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.







<img data-src=" /> 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 <img data-src=" />-)







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.










Lafisk a écrit :



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.





J’ai meme oublié les tellement basique HTML, CSS, bootstrap aussi dans la liste … au final tu melanges tout ca, tu obtiens une bouillasse degueu la plupart du temps voir doit coder ou recoder des trucs qui ne devrait etre gerer que par un seule partie … genre tu geres tes acces données avec 2 technos différentes car l’une est pour la partie “asynchrone” et l’autre pour la synchrone etc…









Lafisk a écrit :



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)







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.



Je vois vraimetn pas la différence entre du XAML/.NET (pour prendre le cas de Windows 10 par exemple)



Que tu charges des libs tierces pour te faciliter le boulot, quel est le problème ? Si c’est un problème il suffit de ne pas les utiliser. Tu fais une webapps avec AngularJS ou EmberJS, ça reste du JS/HTML/CSS (3 technos donc <img data-src=" />) du début à la fin, tu peux y ajouter 600 plugins parce que t’as pas envie de recoder tel ou tel truc, comme avec n’importe quel techno. Tu dois bien faire la même chose sur tes projets .NET non?



Et aujourd’hui il y a de très bons outils pour gérer les dépendances sur des webapps, sur le même principe qu’un NuGet sur VS.



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à.








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 <img data-src=" />



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#









Lafisk a écrit :



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#







Bah le truc c’est qu’il n’y a pas besoin de nouvelle techno “universelle”, enfin… c’est justement ce que propose l’HTML/JS/CSS. Tu sais bien que ce n’est pas possible de mettre au point une nouvelle techno universelle, regarde déjà comme les avancées de l’HTML sont délicates, alors mettre en place la même chose mais en natif… enfin… avec le webassembly on y vient un peu il me semble. L’exemple du JAVA est bon et représente bien ce qu’est une web app, un truc qui tourne partout, mais pas toujours au mieux (perf, UI/UX etc.).



La différence c’est que sur le web il n’y a pas une entreprise qui décide pour les autres, sûr que ça donne l’impression d’un petit bordel, mais finalement c’est pas plus le bordel que si tu regardes le dev natif dans son ensemble (des centaines de langues, d’outils, lib, etc). Sauf qu’il y a un bordel qu’on connait bien depuis plus de 1520 ans, donc c’est un petit bordel organisé qu’on maitrise <img data-src=" />



Tout ce que font ces boites, et Google, c’est tenter de rendre tout ça plus mature. (quand tu reprends la chronologie des langages “natifs” c’est quand même aussi le bordel <img data-src=" /> à l’époque où tout le monde y allait de son truc)









zogG a écrit :



&nbsp;

Tout ce que font ces boites, et Google, c’est tenter de rendre tout ça plus mature. (quand tu reprends la chronologie des langages “natifs” c’est quand même aussi le bordel <img data-src=" /> à l’époque où tout le monde y allait de son truc)





Pas mieux, pas mal d’acteurs essayent d’amener de nouvelles technos/façons de faire dans le web pour le rendre&nbsp;plus efficace (performance, sécurité, stabilité des techno - et donc des sites web fait avec - dans le temps…).



Le web est jeune, le reste n’en est que la conséquence. La natif n’a pas été différent, y a quelques dizaines d’année.









Lafisk a écrit :



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



De quel choix tu parles en fait? Le web apporte un contexte réellement multiplateforme, facilement accessible (pas d’install cote utilisateur), correctement sandboxé, qui n’est pas assujettis au desir d’une seule entreprise et avait deja le merite d’etre tres populaire avant tout ça…



Donc ouais ça a des inconvénients (pour moi c’est pas les perf, mais le trio de merde html/css/js), mais toutes les techno populaires aujourd’hui en ont…

&nbsp;Et ça me semble pas complètement irresponsable comme choix, surtout aujourd’hui, où les gens passent 90% du temps sur leur navigateur en utilisant des OS de plus en plus hétérogènes…









Lafisk a écrit :



Y’a que moi qui a les poils qui ce hérissent des qu’on me parle de faire des appli web au lieu de faire des applis natives ??? <img data-src=" />



Je comprend que y’ai des avantages etc … mais franchement le “web” a toutes les sauces c’est du n’importe quoi je trouve … surtout avec 50000 technos differentes pour faire des trucs qui en natif ne te demande pas plus d’un ou 2 technos/framework …. bon c’est sur c’est plus “portable” mais quand meme, le web c’est a la base une techno statique a laquelle on a ajouté 50 layer pour faire du dynamique dans tout les sens, c’est degueu par moment je trouve. Enfin, c’est que mon opinion de dev …







Je partage votre opinion.









vloz a écrit :



De quel choix tu parles en fait? Le web apporte un contexte réellement multiplateforme, facilement accessible (pas d’install cote utilisateur), correctement sandboxé, qui n’est pas assujettis au desir d’une seule entreprise et avait deja le merite d’etre tres populaire avant tout ça…



Donc ouais ça a des inconvénients (pour moi c’est pas les perf, mais le trio de merde html/css/js), mais toutes les techno populaires aujourd’hui en ont…

 Et ça me semble pas complètement irresponsable comme choix, surtout aujourd’hui, où les gens passent 90% du temps sur leur navigateur en utilisant des OS de plus en plus hétérogènes…







Le choix de passer par les technos web qui comme je l’ai dit, n’est pas “propre” a mon avis. Oui comme certain l’ont expliqué, c’est encore “jeune” comme techno et cela explique un peu le bordel des technos web mais c’estle choix privilégié aujourd’hui quand on veut faire une appli smartphone multiplateforme au détriment des applis natif qui son, a mon avis bien mieux en terme de dev et comme je l’ai expliqué, en architecturant bien son projet, on peut “facilement” n’avoir a dev que l’UI layer sur chaque appli …









Lafisk a écrit :



Y’a que moi qui a les poils qui ce hérissent des qu’on me parle de faire des appli web au lieu de faire des applis natives ??? <img data-src=" />



Je comprend que y’ai des avantages etc … mais franchement le “web” a toutes les sauces c’est du n’importe quoi je trouve … surtout avec 50000 technos differentes pour faire des trucs qui en natif ne te demande pas plus d’un ou 2 technos/framework …. bon c’est sur c’est plus “portable” mais quand meme, le web c’est a la base une techno statique a laquelle on a ajouté 50 layer pour faire du dynamique dans tout les sens, c’est degueu par moment je trouve. Enfin, c’est que mon opinion de dev …







C’est clair que les technologies web, c’est de plus en plus n’importe quoi. Quand on mesure les ressources CPU qu’ils arrivent a bouffer pour des animations minables, il y a de quoi pleurer. Et encore, je parle du meilleur des cas, c’est à dire quand ça fonctionne.



Au train ou vont les choses, il y a de quoi avoir peur. Dans quelques années et quelques couches supplémentaires, faudra t’il acheter un supercalculateur et 3 centrales nucléaires pour surfer sur le web ?



Et depuis que les développeurs ont découvert Ajax, c’est carrément le festival de l’apothéose.



Comme tu dit, toutes leur tas de spaguettis technologies dynamique tsoin-tsoin codées avec les pieds ne peuvent qu’hérisser les cheveux de tout programmeur sérieux. Il suffit d’ailleurs de constater le nombre de sites qui déconnent.



Mais bien sûr c’est de votre faute : d’abord, vous n’aviez qu’a avoir le même navigateur dans la même version, sur le même système et le même écran que le développeur. Non mais….



J’avoue en avoir mare de prier à chaque achat en ligne de peur que le système de commande se mette à foirer, juste parce que le programmeur s’est cru très intelligent de mettre de l’ajax et des animations partout. Les mots “gestion des cas d’erreur” ne semblent plus évoquer grande chose à la nouvelle génération de saboteurs développeurs.



Certains se demanderont peut être si mon message est un troll.



Hélas, non….



J’aurais plutôt dis rageux :-) Y’a du vrai la dedans, mais ça ne s’applique pas qu’au web, mais à tous les devs, d’un erp bancale à un jeu vidéo en passant par un soft de graphisme. C’est pas le langage qui fait le mauvais code hein, c’est ce qu’il y a entre le clavier et le fauteuil!