En tant que développeur de bureau de longue date qui envisage de faire notre première application Web à grande échelle, quels sont les avantages et les inconvénients du développement Web?

Le développement d'une application Web est-il bien pire que le développement d'une application de bureau? Par exemple, est-ce plus fastidieux ou ennuyeux? Le temps de commercialisation est-il bien pire? La plate-forme Web est-elle excessivement limitative? Si la réponse à l'une de ces questions est oui, alors pourquoi?

(Et comment le développement d'une application Flash ou Silverlight se compare-t-il?)

Non

C'est douloureux si vous ne savez pas ce que vous faites ou si vous ne planifiez pas correctement, mais c'est vrai pour tout développement. Il est plus facile d'embouteiller l'application dans une application de bureau, mais vous perdez ensuite l'accessibilité fournie par le codage d'une application Web.

Je ferais le choix entre le bureau et le web en fonction de l'utilisation souhaitée. Je vois de nombreuses applications écrites sur le Web qui ne devraient pas l'être car elles ne savent pas coder les applications de bureau. Je ne vois cependant pas beaucoup d'applications de bureau qui devraient être basées sur le Web, et je pense que c'est quelque chose à considérer. Si vous avez besoin du stockage centralisé, de l'accessibilité à distance et des caractéristiques de l'interface utilisateur, assurez-vous .

Je ne peux pas commenter Flash ou Silverlight car je n'utilise ni l'un ni l'autre.

Comme mentionné par d'autres, c'est une question de compromis et d'avoir la bonne connaissance.

Le seul écueil que vous voudrez peut-être considérer est le suivant: vous mentionnez dans votre question que vous considérez le Web comme un "multiplateforme" comme un avantage. Mais est-ce vraiment le cas? Pensez-y de cette façon: si vous développez quelque chose pour le bureau, vous devez définir la liste des plates-formes et leurs exigences à prendre en charge.

Ne vous y trompez pas, c'est pareil pour le web. Et même si c'est déjà beaucoup plus simple qu'auparavant, si vous concevez une application publique large, vous devrez gérer toutes les versions possibles de tous les navigateurs Web. Et s'il s'agit plus d'une application d'entreprise, préparez-vous et préparez-vous à rédiger très précisément les exigences de vos plates-formes de navigateur prises en charge.

Ne pensez pas que vous éviterez d'avoir des hacks spécifiques à la plate-forme ici et là si vous construisez quelque chose d'important.

Et puis les parties amusantes. Quel est le meilleur? Les navigateurs qui se mettent à jour de manière quasi transparente très régulièrement comme Chrome? Ou ceux qui déploient des mises à jour de sécurité uniquement mensuellement et des fonctionnalités majeures à chaque âge de pierre (comme IE)? La réponse n'est pas aussi évidente que vous pourriez le penser, car certaines de ces mises à jour fréquentes "transparentes" peuvent casser votre code, et vous devrez suivre cela et réagir rapidement. Ou gardez un œil sur les pré-versions bêta et dev lors du développement et des tests. Pour tous les navigateurs, vous avez stupidement dit que vous vouliez soutenir (bonne chance).

Oh et n'oublions pas les considérations d'interface utilisateur. Vous aussi face à la joie de décider si vous voulez une interface utilisateur cohérente ACROSS toutes vos plates - formes cibles, ou une interface utilisateur cohérente AVECplate-forme cible de chaque hôte. Voir tous ces petits boutons que vous pouvez afficher sur les pages Web? Voulez-vous qu'ils soient exactement les mêmes partout ou s'intègrent à l'environnement utilisé par votre utilisateur? Bien sûr, ce problème n'est pas nouveau et existait pour d'autres modèles de développement, mais il semble être plus important ici, et dépend du type d'utilisateurs que vous ciblez et de ce qu'ils attendent. L'utilisateur final public aurait tendance à vouloir que vous vous intégriez à sa plate-forme - mais il voudra toujours que vous "wow!" les avec des trucs de fantaisie - tandis que l'utilisateur d'entreprise voudra quelque chose qui ressemble à une application de bureau. Et les plateformes mobiles avaient une nouvelle dimension à tout cela.

Pour les 2 derniers paragraphes, une idée courante consiste parfois à emballer un navigateur Web préconfiguré avec votre programme d'installation, qui se connecte ensuite à votre application Web (hébergée localement ou sur le Web). C'est génial car vous contrôlez la fréquence de mise à jour et vous pouvez "geler" l'état et vous savez exactement sur quoi prendre en charge et tester. De plus, vous pouvez ajouter des trucs sympas comme des extensions utilisateur dédiées. Par exemple, empaqueter un Chrome "gelé" avec de petites extensions Chrome que vous avez développées pour faciliter l'utilisation de votre application web pour différents types d'utilisateurs peut être extrêmement agréable. D'un autre côté ... vous êtes désormais responsable si une violation de sécurité se produit parce que vous avez gelé le cycle de publication, et votre application ne bénéficiera pas d'améliorations de vitesse (le cas échéant).

Comme beaucoup de choses, c'est une hache à double tranchant.

Remarque: J'ai un fort parti pris contre le Web pour être essentiellement un gros tas de technologies à moitié cuites (et je suis poli ici), jusqu'aux couches OSI, sur lesquelles nous continuons d'ajouter des couches de merde cachant les problèmes en dessous sans vraiment résoudre ou les réparer.

Cela étant dit, je suis en faveur du Web pour sa nature omniprésente en tant que plate-forme. Je pense que la décision de votre entreprise est (probablement) la bonne. Cela dépend de votre marché cible et des plates-formes que vous visez, évidemment. Si vous souhaitez exposer quelque chose en tant que service, vous êtes probablement prêt à partir (même si ce n'est pas nécessaire non plus). Si vous ne le faites pas, il n'y a peut-être pas tant de raisons à cela.

Hmm, et attendez-vous à des développements amusants à l'avenir maintenant que davantage de variantes légères des systèmes d'exploitation existants continuent de se reproduire pour les environnements mobiles (netbooks, smartphones, PDA, tablettes, eBooks ...), avec plus d'accent sur l'utilisation de navigateurs intégrés légers. .. mais avec toute leur nouvelle part de problèmes de rendu de l'interface utilisateur.

En ce qui concerne les technologies basées sur les plugins ... je dirais de les éviter. Ils amélioreront la puissance de votre application, mais limiteront sa pénétration sur le marché. Dans certains cas, vous le verrez comme un avantage en termes de support multiplateforme, jusqu'à ce qu'une nouvelle plateforme refuse soudainement de les prendre en charge. Les normes Web sont là pour une raison (faites attention à ne pas trop vous exciter pour tout dans HTMl5, sinon cela pourrait vous exploser au visage).

EDIT: d'autres choses à considérer ...

Recrutement

Il est extrêmement difficile de trouver des développeurs Web compétents. On pourrait penser qu'il y en a un troupeau, mais ils sont perdus dans un énorme pool de personnes, enfin, assez incompétents qui pensent avoir réussi à écrire 700 lignes de JavaScript / ECMAScript pour implémenter une validation dans leurs formulaires est la fin et tout ce qui peut être réalisé en termes de compétences de haut niveau.

Je ne plaisante pas, dernièrement, ma première question pour toutes les interviews de développement Web est de savoir comment déclarer une variable, puis s'il y a une différence entre l'utilisation varou non (selon la façon dont ils répondent). C'est déprimant. Je trouve qu'il est beaucoup plus difficile de trouver un développeur Web moyen ou avancé que de trouver un développeur de bureau moyen ou avancé.

la perception

Personne ne vous considérera jamais sérieusement lorsque vous dites «je suis développeur Web». C'est pour une sous-classe de programmeurs, développeurs, n'est-ce pas? Ceux que vous ignorez et raillez de loin, et ne rejoignez pas quand ils vont chercher du café. :)

C'est évidemment faux, mais cela revient au fait que vous développez pour un environnement qui est principalement géré pour vous. Les navigateurs corrigent votre balisage vissé, vos styles vissés, et même corrigeront vos scripts vissés pour certains d'entre eux, et l'optimiseront pour vous si vous le souhaitez. Et si vous êtes un développeur Web, les gens ne supposeront pas que vous avez une idée de la programmation de niveau inférieur, vous devez donc être un idiot complet, non?

Et puis ils réalisent à quel point ECMAScript peut être incroyablement complexe, mais refusent de revoir leur opinion. Parce que c'est le web. Nous ne l'aimons pas intrinsèquement, nous aimons juste ce qu'il nous permet de faire.

En tant que personne qui a traité avec les deux (plus de bureau que de web cependant): de loin mon plus gros reproche est le sentiment de "maladresse générale" dans le développement web. Même avec les meilleurs outils et frameworks, les abstractions sont toujours très fuyantes et vous devez constamment faire face au fait que vous utilisez un protocole sans état.

Une autre gêne connexe est le mélange de technologies utilisées pour mettre en œuvre des applications Web. Il n'y a pas d'environnement ni de langage modulaire, monolithique et agréable dans lequel tout peut être fait.

Donc, comme réponse générale: OUI , c'est vraiment si mauvais. Au moins si vous venez d'un arrière-plan de bureau traditionnel où vous avez l'habitude de coder les choses dans un environnement propre et transparent, en utilisant une technologie et une plate-forme où tout est assez linéaire et bien défini. La meilleure façon est de ne pas essayer de le considérer comme le même domaine. Si vous vous attendez inconsciemment à ce que le développement Web soit "comme un développement de bureau", il sera toujours très désagréable et ennuyeux.

la plus grande refonte du bureau vers le Web est: l'application Web est intrinsèquement apatride

comprendre cette partie, et vous êtes bon.

Une grande partie de l'ennui vient du travail nécessaire pour que tout fonctionne dans tous les navigateurs. Comme vous n'avez probablement pas besoin d'être à la pointe du progrès, vous pouvez tirer parti du travail effectué par d'autres, en choisissant un cadre Web approprié au lieu de contrôler manuellement le vôtre.

Lequel utiliser, dépend fortement de l'environnement linguistique auquel vous êtes actuellement habitué. Vous souhaiterez peut-être modifier la question pour fournir ces informations.

Non, les applications Web ont des compromis différents des applications de bureau. Chacun a ses forces à mon esprit. Bien qu'il existe des atouts comme un déploiement unique, il y a le compromis de savoir quels navigateurs prenez-vous en charge et quelle résolution d'écran attendez-vous du client? Bien que vous ayez le contrôle sur le matériel du serveur, la question est de savoir combien de trafic attendez-vous et dans quelle mesure évoluera-t-il? Pour ceux qui ont fait du développement Web pendant des années, cela peut être douloureux, tout comme j'imagine que vous avez des tâches de développement qui vous semblent être une douleur majeure, non?

Une application Flash peut ou non être une application Web à mon avis. Quelque chose comme AIR peut maintenant faire tourner des trucs Flash sur le bureau et certaines applications sont construites sur cela, par exemple Twhirl, donc ce n'est pas tout de suite aussi sec et sec.

Le développement Web n'est pas nécessairement pire , c'est juste très différent.

L'une des choses qui sépare le développement Web du développement de bureau est la pléthore de technologies radicalement différentes que vous devez maîtriser pour développer une application décemment complexe. Je veux dire, vous devez essentiellement avoir une solide connaissance de:

• HTML
• Javascript
• CSS
• Quelques langages côté serveur (Java / PHP / quoi que ce soit ...)
• Un SGBDR (ou une technologie de magasin persistant)
• ... et peut-être bien d'autres choses comme Flash, Silverlight, etc.

Alors qu'avec le développement de bureau, vous travaillez généralement avec un ensemble de technologies beaucoup plus monolithique. Par exemple, le développement d'une application Java nécessite essentiellement que vous connaissiez Java, et c'est tout. (Bien sûr, c'est en quelque sorte une simplification, mais le fait est que le développement Web vous expose à un éventail beaucoup plus large de technologies radicalement différentes qui doivent travailler ensemble pour former une application fonctionnelle.)

Non

Tant que vous choisissez les bons outils, le développement Web est aussi propre et facile que le développement de bureau.

Les API web (html, CSS, Javascript et DOM) sont l'équivalent de l'api win32. Finalement, tout se résume à ce niveau d'API, mais vous êtes fou si vous programmez directement par-dessus sans bibliothèque pour faire abstraction du désordre, de la verbosité et de l'incohérence.

Alors, faites attention à votre choix de frameworks. Certains problèmes sont auto-infligés en choisissant de mauvais outils (par exemple, des problèmes de compatibilité du navigateur).

Il est possible d'avoir une plate-forme de développement Web propre et cohérente, avec une seule langue. Par exemple, si vous voulez que ce soit "tout Java tout le temps", vous pouvez utiliser GWT et écrire à la fois votre code côté client et votre code côté serveur en Java. Ou, si vous préférez que tout soit javascript, vous pouvez choisir quelque chose comme Ext JS pour le côté client et node.js pour le côté serveur.

Je l'ai entendu décrit comme "... le fléau de mon existence" et je suis d'accord. On m'a offert $$$ une heure pour faire du développement Web HTML et je l'ai refusé. C'est tellement pénible. J'ai passé une majorité de temps en HTML et j'ai récemment commencé à travailler avec la "plateforme Flash". C'est l'un des cadres les plus sophistiqués que j'aie jamais vus et personne ne le sait même. Lorsque les gens évoquent Flash, ils pensent à Flash il y a 10 ans. Il a grandi ... beaucoup. J'adore réécrire des logiciels.

Il a toujours ses inconvénients. Les bugs persistent parfois pour toujours mais ça s'est amélioré (merci Steve J.).

BTW Il y a une pénurie majeure pour les développeurs Flex. J'ai été approché par tant d'entreprises, c'est malade. Si vous connaissez votre CS, passez les 6 mois suivants à apprendre Flex Hardcore, puis appelez-moi. Je vais transmettre toutes les offres d'emploi que je dois refuser.

Mise à jour: la prise en charge de plusieurs navigateurs est le principal problème. Ce qui fonctionne dans un navigateur ne fonctionnera pas dans un autre ou il le sera mais pas dans une version précédente.

Le processus se déroule comme suit: - obtenir la conception du site - tenter de le recréer dans un navigateur cible (cela peut être difficile) - montrer le client - le client modifie la conception - gratter tout le travail de mise en page que vous avez fait à l'origine - le rendre fonctionnel - le client approuve - le faire fonctionner dans d'autres navigateurs. C'est la partie la plus difficile. Il y a des bugs obscurs tout au long du parcours. Ensuite, vous rencontrerez des fonctionnalités que les navigateurs précédents ne prennent pas en charge, comme les coins arrondis. Vous allez essayer de réutiliser votre code et css mais cela devient rapidement fragmenté. Tout simplement, il peut devenir très rapide et nécessitant beaucoup d'entretien. Ajoutez des animations et les anciens navigateurs s'étouffent.

Le client va faire des changements. Vous finirez par passer tout votre temps à faire «ce qui devrait être des choses simples» et à détester votre vie. Vous deviendrez un gourou et vous saurez des choses que vous ne voulez pas savoir. Je sais que cela semble dramatique, mais je n'embellis pas les problèmes auxquels vous serez confronté. Les cadres vous faciliteront la tâche. Si vous persistez à travailler en HTML, préparez-vous à recréer l'un de vos sites préférés en HTML en vous assurant de faire correspondre la conception et les fonctionnalités de tous les navigateurs qu'il prend en charge. Éliminez les problèmes que vous rencontrez avant de commencer un travail. Problèmes tels que les meilleurs outils de conception, les meilleurs cadres javascript, les meilleurs outils de débogage, les meilleurs IDE, etc.