Discussion :

[Vinchenzo.939]

Je penses que nous devrions arreter de developper des applications et attendre cette magnifique revolution qu'est HTML5.

C'est vrai, avec toute les nouveautes annonces, les choses incroyable que nous pourrons faire comme par exemple les balises video ou menu, c'est une vrai revolution qui est en marche, rendez-vous compte des menus et des videos accessible a tous, c'est Internet 2.0 qui arrives !

Plus serieusement je suis plus que septique quand je lis ce genre d'article.
Oui c'est bien de creer un standard universel, mais ca s'arrete la.
La preuve etant, pour tester la vrai valeur de HTML5, desactiver javascript, et la on pourra voir ce qu'est vraiment HTML5 (rien du tout donc).

HTML restera un support, sur lequel viendra se greffer d'autres technologies de plus haut niveau, qui pourrons donner acces a de la POO.

La mort des applications en 1 an ? Fort heureusement personne n'est paye pour raconter des choses pareils... Attendons la "sortie officiel" pour voir les revolutions annonces...

[nirgal76]

les applications natives seront remplacées par les applications HTML5 l’an prochain

ouiaip, et en l'an 2000, on volera tous dans son avion perso, java va supplanter tous les autres langages de programmations, il n'y aura plus d'IPv4 en 2006 etc...j'adore les "experts" et leurs prévisions. (il a vu ça dans les os de poulets qu'il a jeté dans une assiette ?)

[zeyr2mejetrem]

ouiaip, et en l'an 2000, on volera tous dans son avion perso, java va supplanter tous les autres langages de programmations, il n'y aura plus d'IPv4 en 2006 etc...j'adore les "experts" et leurs prévisions. (il a vu ça dans les os de poulets qu'il a jeté dans une assiette ?)

En 2000, Science et vie avait sorti un numéro hors-série qui était très bien et qui s'appelait "Ils ont prévu l'an 2000 et ils se sont plantés".
C'était un vrai régal.

Et si on y allait de nos prédictions à nous ?
Je me lance:
- Dans 2 ans, tous les bureau d'écoliers auront étés remplacés par des tablettes géantes sous Android

[Octopod]

Jamais tu verras un Photoshop réalisé en HTML. Jamais tu verras un jeu PS3 réalisé en HTML. Jamais tu verras un Visual Studio réalisé en HTML. Pas que c'est impossible (comme d'écrire directement en langage machine sans même passer par de l'assembleur), mais juste qu'il faudrait être con pour utiliser une technologie qui n'est pas faite pour.

Encore un question à la con.

[pseudocode]

L’année prochaine pourrait être l’année du HTML 5 au détriment des applications natives ?

Ca dépend de ce qu'on appelle "application" : jeux, bureautique, compta, conception, gestion, calcul, supervision ?

Pour tout ce qui est de la "visualisation de données" (image/son), il est probable que le HTML5 devienne incontournable. En particulier lorsque les données en question doivent être visibles sur un appareil mobile.

Après, j'ai un peu de mal à imaginer que les drivers, OS et applications lourdes (bancaires, médicales, industrielles, ...) seront codées "en HTML5" l'année prochaine.

[Shaidak]

Jamais tu verras un Visual Studio réalisé en HTML. Pas que c'est impossible (comme d'écrire directement en langage machine sans même passer par de l'assembleur)

Il existe déjà des IDE disponible via le navigateur, pour de l'embarqué par exemple. C'est juste que la couche métier est complètement masquée afin de ne laisser que l'interface à l'utilisateur.
Maintenant le soucis c'est qu'il faut que les infrastructures suivent, et je ne suis pas certain que le parc actuel survivrait à du web only, sans parler des questions de performances pour les applications critiques ...

[Paul TOTH]

Jamais tu verras un Photoshop réalisé en HTML. Jamais tu verras un jeu PS3 réalisé en HTML. Jamais tu verras un Visual Studio réalisé en HTML. Pas que c'est impossible (comme d'écrire directement en langage machine sans même passer par de l'assembleur), mais juste qu'il faudrait être con pour utiliser une technologie qui n'est pas faite pour.

Encore un question à la con.

mais si ! quand j'ai commencé l'informatique le processeurs ne permettaient pas d'imaginer ce que sont les jeux PS3 aujourd'hui...comme de toute façon c'est aujourd'hui la carte graphique qui bosse, avoir un moteur Javascript (ou Lua comme ça se fait beaucoup dans les jeux vidéo) ce n'est pas un problème.

Demain on aura des évangélistes Javascript/HTML5 pour Windows 8 ça ne fait aucun doute. Ils nous expliqueront qu'il faut se mettre pas aux nouvelles technologies sinon nous serons les cobolistes de demain, et les développeurs dotNet d'aujourd'hui seront vus comme des développeurs C++ d'hier, des dinosaures.

Est-ce que les applications seront mieux ou plus efficaces que ce qu'on fait aujourd'hui ? non, probablement pas, mais qui s'en préoccupe ?

Chacun ira de son extension, comme ça s'est fait par le passé, on aura des applications Metro, des applications Chromes, des application Firefox, et sans doute aussi des plugins pour les rendre compatibles. Et ça sera tout de même plus facile d'adapter une appli Javascript que de faire tourner win32 sous Linux (pourtant ça a fini pas marcher vraiment bien ce truc, win32 est presque devenu un format portable ... je me demande d'ailleurs s'il n'y a pas plus d'appli win32 qui tournent sous WINE que d'appli dotNet sous Mono !).

Bref, on aura des applications plus portables avec des outils moins efficaces...c'est la tendance depuis quelques années.

[ZiGoM@r]

Je pense aussi que JavaScript ne sera plus utilisé directement mais comme bytecode. La question est donc : Pourquoi ne pas avoir standardisé un bytecode plutôt qu'un langage interprété d'une qualité toute relative ?

Finalement c'est bel et bien Sun qui avait trouvé la bonne voie, dommage qu'ils n'aient pas su transformer l'essai de la standardisation. Aujourd'hui, Java est encore propriétaire et cède toujours plus de terrain à l'immondice JavaScript...

Aussi, il serait sûrement moins risqué d'attendre les applications native x86 etc.. sur smartphone/tablette (Windows 8 sera compatible tablette)...

[PINGOUIN_GEANT]

Je ne suis pas sur que faire une prévision à un an ait un intérêt pour prendre des décisions dans des entreprises, qui ne vont pas modifier leur façon de travailler à si court terme. Pour bâtir la stratégie un responsable informatique dans une entreprise doit être informé de ce que sera le développement dans 5 ans voire 8 ans. Quelqu'un a un avis sur HTML5 contre applis natives dans 5 ans ? Quelle est la tendance à long terme ?

[Chuck_Norris]

Tu dis ça parce tu es dév php/js et jaloux des rémunérations des dévs Java/C#/C++ ?

Donc en gros tu me prends pour une personne sans principe qui ne pense qu'à l'argent ?

Désolé. Je préfère faire ce en quoi je crois, ce en quoi je pense qu'il y a de l'avenir, ce qui me plaît, même si je dois pour ça vivre avec mon compte à découvert, plutôt que d'être riche, mais faire quelque chose qui ne me plaît pas et pour lequel je pense qu'il n'y a plus d'avenir ?

J'en suis pas sûr. Vu le temps qu'il a fallu pour nous concocter un html5, les technos propriétaires peuvent facilement devancer ce premier en fonctionnalité en offrant des cycles de release plus rapides. Je ne les enterrerai pas trop vite...

Regarde la nouvelle récente : Flash Player est abandonné pour mobiles. C'est bête hein, mais cela montre qu'au contraire le Html 5 est l'une des solutions permettant d'avoir la compatibilité dans le futur avec toutes les plate-formes, sans dépendre du bon vouloir d'un éditeur qui décide d'arrêter le produit du jour au lendemain, ou qui décide ou pas de supporter une plate-forme (ou de mal la supporter). D'où l'intérêt d'un standard qui ne dépend pas de logiciels propriétaires pour concevoir ou exécuter la chose afin d'avoir la pérennité du développement.

D'habitude je porte le plus grand crédit à ton opinion mais là, laisse moi te dire que tu m'as bien fait marrer
"la puissance du langage Javascript"

Moi je dirais que ça sent un peu le second degré, non ?

Certes mon message était un peu provocateur. On voit aussi que j'ai touché un point sensible des développeurs applicatifs vu l'avalanche de [-] que j'ai eu dans mon message. Ne dit-on pas, y'a que la vérité qui blesse ?

En ce qui concerne la puissance du langage Javascript, je vais te dire ce que j'en pense.

On est parti d'un langage peu performant, mal conçu dès le départ et à la compatibilité douteuse. Depuis, le langage a été (un peu) enrichi à la base. Mais surtout, le langage a été enrichi considérablement avec l'avènement des bibliothèques Javascript comme jQuery, ExtJS, et d'autres.

Alors certes les bases sont pas solides, mais elles sont là, et on fait avec. Avec le travail qui a été fait au niveau des navigateurs pour optimiser le Javascript, on peut maintenant faire beaucoup de choses qu'auparavant on aurait jamais imaginées.

On pourrait certes faire un langage bien mieux adapté aux besoins. Le problème est qu'il y a tout le poids de l'existant. Quand on sait qu'IE 6 règne toujours en maître et surtout dans les entreprises, je pense qu'il faut pas trop compter sur une alternative à Javascript avant des années.

Sérieusement, il y a bien une raison pour laquelle Google a developpé Dart.
Si Google qui est le champion du tout web, a jugé utile de proposer un langage alternatif à Javascript, cela veut bien dire qu'il estime que Javascript est trop limité pour le developpement d'applications puissantes.

Javascript n'a pas été conçu pour ça, mais on pousse ses limites chaque jour. Si Internet Explorer n'existait pas, je suis sûr qu'on pourrait avancer bien plus vite pour justement améliorer significativement JS ou un autre langage pour avoir bien plus de puissance à notre disposition.

Enfin, un dernier mot.

Je pense que le Développement Web dans le but de remplacer certaines applications métiers à de l'avenir.

Avantages :
- Multiplateforme d'origine, que la machine soit sous Windows (toute version), Linux, Mac, Solaris, ou je ne sais quoi encore
- Aucun travail de déploiement à faire (aussi bien initial que de mise à jour), il suffit d'un accès à l'intranet

Inconvénients :
- Internet Explorer est le boulet du Développement Web. Si la dernière version se rapproche un peu de ce qui se fait chez les concurrents, les autres versions hantent les développeurs Web.
- Performances très inférieures
- Certaines limitations qui peuvent être gênant suivant les applications (notamment pas d'accès au système de fichier)

Pour les applis métiers qui étaient légères, cela me semble parfait.

Evidemment pour des applications plus lourdes, qui ont besoin de puissance, etc, le développement applicatif restera irremplaçable, surtout pour le code natif.

C'est donc amené à se développer, c'est évident. A faire disparaître le développement applicatif, certes non. On a des processeurs très puissants, et on trouvera toujours de quoi se servir de cette puissance sans forcément la gaspiller par du pseudo-code comme Javascript, ou même Java et .NET.

[DonQuiche]

Est-ce que les applications seront mieux ou plus efficaces que ce qu'on fait aujourd'hui ? non, probablement pas, mais qui s'en préoccupe ?

Le client ?
Parce que si la concurrence fait deux fois mieux en deux fois moins de temps et pour deux fois moins cher...

Compare un produit touchant 70% du marché à un autre touchant 100%. Le premier est performant, rapide et peu coûteux à développer tandis que l'autre est une horreur pour le développeur et ramouille sévèrement sur les mobiles. En tant que client comme en tant qu'investisseur, sur laquelle vas-tu miser ?

Enfin, ta prédiction s'appuie sur des outils qui ne seraient pas le vieux js+html mais d'autres, pas encore disponibles. Tu ne crois pas que, pendant ce temps, il se passe aussi des choses en C++, java et dotnet ? Sans parler du fait que ce que tu nous décris implique des langages lents tournant sur des interpréteurs eux-mêmes écrits dans des langages lents afin d'assurer l'interopérabilité ! A une heure où la puissance disponible a fait un bond de dix ou quinze ans en arrière avec les plateformes mobiles. Tu parles d'une tour de Babel !

[jeroy]

Ce genre de news fracassante, c'est juste l'expression de la loi de Wirth / Gates :

"The speed of software halves every 18 months."

On rajoute des couches (des VM, des interpréteurs) tous les ans, dans le but de toujours simplifier/accélérer le dévelopement. Au final on ne fait qu'occuper le temps de proc disponible. La nature ayant horreur du vide, on occupe la puissance dispo, au lieu de l'utiliser mieux. Et le développement n'est pas plus simple - mais il nécessite plus de monde, plus de spécialités différentes.

En 10 ans, la puissance des procs a évolué d'une manière énorme, mais Office tourne pas plus vite. On occupe cette puissance à faire tourner des couches additionnelles. Sans vraiment de raison derrière.

Après on y peut rien, le progrès dans le secteur des langages et plate-formes, ça consiste à rajouter des couches au lasagne. Parce que chaque couche permet de filer du boulot à des développeurs (y compris les plus médiocres dans le cas de cette news), parce que chaque couche permet de vendre des formations, de la documentation, des prestations en plus, des outils de développement. C'est naturel, c'est un business, il faut bien manger.

Espérons que ce phénomène est cyclique, et qu'après cette période qui s'annonce coûteuse en mise à jour hardware pour l'utilisateur final et le client, on voit le retour vers une plus grande simplicité et desp late-formes plus raisonnables. L'industrie du mobile redorera peut-être le blason d'un développement plus léger, l'arrivée des procs ARM aussi.

[regisportalez]

En 10 ans, la puissance des procs a évolué d'une manière énorme, mais Office tourne pas plus vite. On occupe cette puissance à faire tourner des couches additionnelles. Sans vraiment de raison derrière.

Rien ne t'oblige à ne pas faire de l'assembleur...

Personnellement je développe des applis Web en html5/WebGL et je trouve bien pratique de ne pas avoir à apprendre le flash, ni le java, ni les activeX...
D'autant que c'est plus rapide, plus léger, et standardisé par le W3C, ce qui m'assure qu'à part IE, tout le monde sera compatible.
C'est mieux qu'une appli java parce que ça tourne chez le client et du coup mon serveur peut rester petit même si j'ai beaucoup de visites...

Enfin bref je vois pas ce qu'on peut trouver à redire à ce genre d'évolution.

A part peut être que les gens ont leurs habitudes et devront ptet les changer.

[Paul TOTH]

Le client ?
Parce que si la concurrence fait deux fois mieux en deux fois moins de temps et pour deux fois moins cher...

Tu penses réellement que dotNet a apporté quelque chose au client ? tu penses que ça permet de faire 2 fois mieux ?

Compare un produit touchant 70% du marché à un autre touchant 100%. Le premier est performant, rapide et peu coûteux à développer tandis que l'autre est une horreur pour le développeur et ramouille sévèrement sur les mobiles. En tant que client comme en tant qu'investisseur, sur laquelle vas-tu miser ?

Celui de Microsoft ! La qualité d'un produit n'a jamais été le critère principal dans le choix. En tant que développeur Delphi je suis bien placé pour le savoir.

Enfin, ta prédiction s'appuie sur des outils qui ne seraient pas le vieux js+html mais d'autres, pas encore disponibles.

Oui, nous utilisons des solutions de moins en moins pratiques, mais je suis persuadé qu'on finira par retrouver des outils aussi efficaces pour JS/HTML que ce qu'on a depuis 10 ou 20 ans pour les autres langages.

Tu ne crois pas que, pendant ce temps, il se passe aussi des choses en C++, java et dotnet ?

Oui, et Embarcadero vient de sortir un nouveau Delphi, produit dont on dit pourtant qu'il est mort depuis 20 ans. Sauf que Microsoft a décidé que Windows 8 sera HTML et Javascript, pas C++ ou Java.

Sans parler du fait que ce que tu nous décris implique des langages lents tournant sur des interpréteurs eux-mêmes écrits dans des langages lents afin d'assurer l'interopérabilité ! A une heure où la puissance disponible a fait un bond de dix ou quinze ans en arrière avec les plateformes mobiles. Tu parles d'une tour de Babel !

Mais c'est exactement ce qu'il se passe, et ce n'est pas pour rien qu'on a vu une concurrence sévère dans la performance des interpréteurs JavaScript...ça a longtemps été considéré comme un truc optionnel pour le web, c'est devenu le centre d'une compétition pour la plateforme de demain.

En plus je suis persuadé que la puissance des mobiles va grimper en flèche, comme c'est le cas des PC, et que les softs de demains seront encore plus gourmands que ceux d'aujourd'hui.

[DonQuiche]

Tu penses réellement que dotNet a apporté quelque chose au client ? tu penses que ça permet de faire 2 fois mieux ?

Par rapport à une solution js/html ? Sans aucun doute, d'abord parce que nous travaillerons deux fois plus vite, ensuite parce que nous ne rencontrerons pas un plafond de performances qui nous obligera à faire des pieds et des mains pour le dépasser avec des résultats mitigés, enfin parce que notre produit, lui, ne videra pas la batterie de l'utilisateur en huit minutes.

Oui, nous utilisons des solutions de moins en moins pratiques, mais je suis persuadé qu'on finira par retrouver des outils aussi efficaces pour JS/HTML que ce qu'on a depuis 10 ou 20 ans pour les autres langages.

Pouquoi ne sont-ils pas déjà là alors que Js/html est ancienne ? Cette plateforme ne peut qu'évoluer lentement, au rythme des standardisations et de l'adoption hétérogène d'extras par les navigateurs et de l'adoption de ces nouveaux navigateurs par les utilisateurs. Dévélopper en html5 aujourd'hui, c'est encore développer pour un faible public.

Or, pendant que Js/html peine à s'adapter aux besoins actuels, les plateformes traditionnelles travaillent déjà sur les nouveaux besoins.

Sauf que Microsoft a décidé que Windows 8 sera HTML et Javascript, pas C++ ou Java.

Faux. Applis metro en dotnet ou js+html, applis natives en dotnet ou c++.

Mais c'est exactement ce qu'il se passe, et ce n'est pas pour rien qu'on a vu une concurrence sévère dans la performance des interpréteurs JavaScript...ça a longtemps été considéré comme un truc optionnel pour le web, c'est devenu le centre d'une compétition pour la plateforme de demain.

Et malgré tous ces efforts, ça reste lent. Et ça le restera car c'est une limite intrinsèque et infranchissable pour les langages souples.

En plus je suis persuadé que la puissance des mobiles va grimper en flèche, comme c'est le cas des PC, et que les softs de demains seront encore plus gourmands que ceux d'aujourd'hui.

La puissance des mobiles est soumise aux lois de la physiques et celles-ci ne sont pas commodes. Nous verrons les réponses qu'apporte l'innovation.

[seb012007]

Jamais tu verras un Photoshop réalisé en HTML.

http://pixlr.com
http://www.photoshop.com/tools/overview
etc.. (y en a des tonnes)

Jamais tu verras un jeu PS3 réalisé en HTML.

PS3 c'est sûr vu que c'est une console... Par contre pour les jeux en 3d :
http://code.google.com/p/quake2-gwt-port/

Jamais tu verras un Visual Studio réalisé en HTML.

http://www.wiode.com/

Evidemment ça n'est que quelques exemples, mais clairement l'avenir est là.

mais juste qu'il faudrait être con pour utiliser une technologie qui n'est pas faite pour.

C'est justement ça qu'on appelle... l'innovation.

Bref.

[zeyr2mejetrem]

PS3 c'est sûr vu que c'est une console... Par contre pour les jeux en 3d :
http://code.google.com/p/quake2-gwt-port/

Désolé, mais GWT c'est du Java qui ensuite crache du Javascript/HTML pour la partie cliente et du Java Web/JEE pour la partie serveur.
HTML5 n'a rien à voir la dedans (ou si peu ...)

http://www.wiode.com/

L'ide en question est en PHP ...

Evidemment ça n'est que quelques exemples, mais clairement l'avenir est là.

... Dans les technos serveurs existantes saupoudrées de HTML5
Pas dans les applis full HTML5 (côté client) comme les marketeux voudraient le faire croire.

C'est justement ça qu'on appelle... l'innovation.

... mouais... c'est surtout ce qu'on appelle le buzz

[seb012007]

Désolé, mais GWT c'est du Java qui ensuite crache du Javascript/HTML pour la partie cliente et du Java Web/JEE pour la partie serveur.
HTML5 n'a rien à voir la dedans (ou si peu ...)

Oui non mais là alors si tu te met à croire qu'on va faire des applis complexe et des jeux en 3d avec juste un langage de balisage...

L'ide en question est en PHP ...

Ben oui c'est du client/serveur avec la partie client en html + js.

... Dans les technos serveurs existantes saupoudrées de HTML5
Pas dans les applis full HTML5 (côté client) comme les marketeux voudraient le faire croire.

On en revient au fait que html c'est du balisage. Pas de la logique de code.
[edit]Pardon j'avais mal lu. D'un autre côté de plus en plus la partie serveur ne sert plus qu'à stocker des données en base. De là a stocker les données dans le navigateur à la place il n'y a qu'un pas.

... mouais... c'est surtout ce qu'on appelle le buzz

Ben non justement : ce genre de technos prend de plus en plus d'ampleur depuis quelques années, on est loin du buzz. Regarde du côté de Google Document et consorts.

[zeyr2mejetrem]

Oui non mais là alors si tu te met à croire qu'on va faire des applis complexe et des jeux en 3d avec juste un langage de balisage...

Ce n'est pas moi qui le dit, c'est le propos du topic: "Les applications natives seront-elles remplacées par les applications HTML 5 ?"
HTML 5 est un langage de balisage. Ce n'est pas parce qu'on va lui rajouter une couche de Javascript qu'on va en faire une vrai appli

Ben oui c'est du client/serveur avec la partie client en html + js.

Oui. Donc rien de nouveau sous le soleil ...

De là a stocker les données dans le navigateur à la place il n'y a qu'un pas.

Euh, pour des petites applis, pourquoi pas.
Pour les applis professionnelles je suis carrément dubitatif.

Ben non justement : ce genre de technos prend de plus en plus d'ampleur depuis quelques années, on est loin du buzz. Regarde du côté de Google Document et consorts.

Attention. Quand je parle de buzz, je parle du fait qu'on essaie de faire croire que HTML5 fait le café alors que ce n'est qu'une norme (non encore stabilisée) qui n'apporte pas grand chose par rapport aux technos actuelles qui ont déjà pris la place le temps que le W3C se bouge ...

Je suis complètement d'accord que l'on peut faire de très bonnes applis avec la combo (XHTML/Js)<--Ajax-->Langage Serveur.

Cependant pour certaines applis professionnelles (progiciels) le web n'est, a mon humble avis pas approprié car on est dans une autre échelle qu'un logiciel de bureautique comme Google Docs et on a aucun intérêt ou presque à faire trainer des infos sur inter/intranet.

Je pense que de nombreux acteurs du forum confirmeront que par rapport à certaines applis "industrielles" (de gestion de process, de flux financiers, de gestion immobilière, etc ...) Google apps et autre c'est de la roupie de sansonnet (et je suis pourtant un gros utilisateur de Google Apps !!).

[Uther]

Désolé, mais GWT c'est du Java qui ensuite crache du Javascript/HTML pour la partie cliente et du Java Web/JEE pour la partie serveur.
HTML5 n'a rien à voir la dedans (ou si peu ...)

HTML 5 n'a en effet rien a voir vu que WebGL n'en fait pas partie. Et alors?
Que le javascript soit compilé à partir de code Java ou non, il n'en reste pas moins que c'est au final une application web qui s’exécute directement dans le navigateur et dont quasiment rien n'est exécute coté serveur, pour l"exemple cité.
Si on suit ton raisonnement un programme écrit en C++ n'est pas natif.

... Dans les technos serveurs existantes saupoudrées de HTML5
Pas dans les applis full HTML5 (côté client) comme les marketeux voudraient le faire croire.

Full HTML5 ne veux de toute façon rien dire. Il est évident que l'on aura forcément un minimum recours au coté serveur même les applications traditionnelles en ont parfois besoin.