HTML5 / JS remplacera-t-il éventuellement toutes les langues côté client? [fermé]

Je m'interroge simplement sur l'avenir de tout cela. À mon humble avis, il y a 4 forces qui définissent où va la technologie: Microsoft, Apple, Google, Adobe.

Il semble que dans l'iPhone / iPad d'Apple, les iAD peuvent désormais être programmés en HTML5. Cela signifie-t-il donc que HTML5 remplacera éventuellement l'objectif-c?

De plus, Microsoft a maintenant déplacé son attention de WPF / Silverlight vers HTML5 et je suppose que Visual Studio 2011 sera entièrement consacré à la prise en charge des outils pour HTML5. Parce que c'est ce que fait Microsoft. (Outils). Dans quelques mois IE9, le dernier navigateur majeur prendra en charge HTML5.

De même, Adobe se lance dans le mouvement HTML5 et permet d'exporter du contenu flash vers HTML5 dans ses derniers outils.

Et nous savons tous combien Google est au lit avec html5. Heck, leur dernier système d'exploitation (Chrome OS) n'est rien d'autre qu'un gros navigateur Web.

Les applications pour mobile (par exemple, iPhone, Android, WM7) sont très difficiles à programmer pour une entreprise, en particulier pour de nombreux appareils différents (chacun avec leur propre langue), donc je suppose que cela ne durera pas trop longtemps. C'est-à-dire que HTML5 sera la langue unificatrice. Ce qui est un peu triste pour les développeurs d'applications, car les utilisateurs pourront désormais jouer gratuitement aux applications html5 «cool» et il sera difficile de les facturer.

Les langages fortement typés sont-ils vraiment condamnés, et à l'avenir, disons 5 à 10 ans, la programmation côté client sera-t-elle uniquement en HTML5? Serons-nous tous des programmeurs javascript? :) Parce que les panneaux pointent de cette façon ...

Je pense qu'il est erroné de suggérer que HTML5 / JS remplacera TOUS les langages côté client. Est-ce que beaucoup d'applications iront dans ce sens dans les années à venir? Oui probablement. Est-ce que tous? Non.

L'autre point important à noter est que le paysage est en constante évolution. HTML5 est une excellente technologie qui promet de résoudre un grand nombre des problèmes que rencontrent actuellement les développeurs lorsqu'ils essaient d'écrire des applications qui fonctionnent sur plusieurs plates-formes. Bien sûr, HTML5 / JS peut résoudre bon nombre de ces problèmes, mais le paysage changera et un nouvel ensemble de problèmes surgira. HTML5 semblera finalement daté.

Dans 10 ans, demandez-vous si HTML5 / JS était la solution à tous les problèmes et je peux presque garantir que la réponse sera non. Dans 20 ans, la question elle-même semblera probablement ridicule.

Javascript est un langage de programmation très pauvre. La traduction à partir de langages de programmation typés statiquement, tels que Java avec GWT, devient de plus en plus courante. Javascript peut devenir le même type de langage unificateur que l'assembleur - vous pouvez l'écrire directement, mais c'est rarement une bonne idée.

Oui.

Voici pourquoi. Les applications sont composées de code d'interface utilisateur et de données principales. Le code d'interface utilisateur est exécuté en HTML5 / CSS3 / Javascript. Le code principal peut être propriétaire et exécuté dans la langue de votre choix. De plus, jQTouch et des bibliothèques similaires peuvent être utilisés pour émuler des interfaces utilisateur de type iPhone mais open-source et écrites en Javascript / HTML5 / CSS. jQTouch a montré que si le navigateur permet aux programmeurs JS d'accéder aux événements d'interface utilisateur du périphérique, les programmeurs JS émuleront le style d'interface utilisateur à la mode pour la même plate-forme.

Les programmeurs Javascript seront plus demandés que jamais. Dans une architecture modèle-vue-contrôleur, le modèle et le contrôleur sont dans le back-end, mais le code de vue est mieux écrit dans le navigateur. c'est-à-dire HTML5, Javascript, CSS. Et vous devez écrire du code JS pour accéder aux données principales, en particulier avec du code AJAX lourd.

Les gains de productivité iront tous aux langages interprétés dynamiques. Au fur et à mesure que les processeurs deviennent de plus en plus rapides, la productivité du codage des programmeurs, la productivité des administrateurs système et la productivité des administrateurs d'applications influencent davantage la productivité globale. Vous n'avez tout simplement plus à vous soucier de la vitesse d'exécution de la machine virtuelle ou du compilateur de votre langage de programmation. Vous devez vous soucier davantage maintenant du coût de la mise en service et de la prise en charge de votre application.

La plupart des applications autonomes ne sont pas si bonnes à mon avis. Tout comme il existe peu d'excellentes applications PC autonomes, et les meilleures sont transformées en applications Web. Il est en fait préférable de donner gratuitement l'application client HTML / JS / CSS et de facturer des frais mensuels pour l'accès aux données principales et à la logique métier. Les programmeurs feront mieux de vendre des abonnements que des applications uniques.

BTW a regardé cette vidéo sur l'écriture d'une partie d'une application web autonome sur un navigateur Webkit. C'est intéressant...

Il existe une volonté de remplacer les langages de codage d'application tels que C ++, Java ... par HTML / Javascript. Il y a plusieurs raisons à cela, certaines d'entre elles:

• Développement plus rapide
• Main-d'œuvre moins chère
• La connectivité est intégrée
• Plus facile à produire quelque chose qui a l'air bien
• Le texte est accessible aux moteurs d'indexation

Pourtant, peut-être d'autres langues apparaîtront, pour être utilisées en remplacement de JavaScript. Après tout, c'est difficile d'avoir une langue qui peut tout faire correctement, tout en restant une langue de haut niveau! Et JavaScript existe depuis un certain temps et a accumulé quelques lacunes.

JavaScript pourrait très bien finir par être le langage principal pour le client, mais je ne pense pas qu'il puisse ni ne devrait être le seul langage, car, JS étant un langage basé sur des normes et conçu par comité, cela tuera simplement l'innovation à ce niveau (langages de programmation).

Cela dépend également des compétences de la majorité des développeurs et des outils qu'ils utilisent. Les géants de la technologie que vous mentionnez peuvent piloter une technologie basée sur les outils qu'ils fournissent. Par exemple, les gens disent que HTML5 est un tueur de Flash, mais je pense que c'est trop loin, il y a beaucoup de développeurs Flash et c'est une tâche décourageante de déplacer leurs compétences vers JavaScript. Ce qui arrive finalement, la compétence reste la même mais la sortie devient différente. Dans ce cas, Adobe sort avec un outil de conversion HTML5.

Vous devez également penser aux performances des applications clientes. Lorsque cela est nécessaire, un outil spécifique à la plate-forme sera utilisé. Prend des jeux et des applications iOS par exemple. Je sais que WebGL sort bien, mais je pense que les gens utilisent toujours C pour créer des jeux. Ou ils créeront un langage de jeu qui crée des jeux de haute performance. Apple ne voulait initialement que des applications Web, mais lorsque les développeurs ont vu les merveilles de Cocoa, ils ont sauté dessus pour créer des applications élégantes.

Pour résumer, il y aura toujours de nouveaux outils / langages / technologies qui seront toujours plus cool que les actuels.

Pas tous, mais probablement la plupart. Peut-être que javascript peut devenir assez rapide pour remplacer HashCalc, mais il n'y a pas d'alternative Web à VLC (les navigateurs ne prendront pas en charge tous ces codecs). Je doute que les navigateurs Web me permettent d'accéder à n'importe quel fichier que je veux ou de stocker une liste de fichiers récente (sans «est-ce correct d'accéder» à chaque fois que je clique sur le fichier récent) et je n'aime pas l'idée de distribuer des applications qui sont à 99% des navigateurs Web (plusieurs mb) avec mes 100 ko de code quand il s'agit de cas où le code casse les navigateurs bc ne sont pas rétrocompatibles avec le html ou j'ai besoin d'une variante / légère modification du webkit.

-edit- j'aime aussi les langages statiques plutôt que dynamiques mais je suppose que je peux utiliser un bon langage avec LLVM qui devrait être supporté par le navigateur.

Je pense que nous continuerons dans cette direction jusqu'à ce que le navigateur devienne le système d'exploitation, puis tout recommencera dans le même ordre, mais avec des leçons apprises et des améliorations.