Discussion :

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

[zeyr2mejetrem]

Je résume mon propos pour éviter toute confusion:

• Dire que dans un an tous les développements natifs seront remplacés par du développement Web est idiot dans la mesure où le navigateur, on le code en quoi ??? En techno native, non ?
  
• S'extasier devant le HTML5 est un peu bizarre dans la mesure où HTML5 est une norme encore instable qui arrive après la guerre. Le besoin a été comblé par plusieurs technos maintenant très répandues.
  
• De toute façon même une fois la norme stabilisée, les implémentations seront très probablement dépendantes du navigateur comme avec le JS actuellement.
  
• Il est tout à fait possible de faire de très jolis applis web avec les technos existantes (HTML5 ne présente donc pas vraiment d'intérêt)
  
• La grosse problématique du web est de pouvoir accéder aux ressources matérielles du client (surtout en mobile) mais la solution viendra des APIs du navigateurs qui seront de toute façon accessibles avec les technos existantes.
  
• Pour les grosses applis industrielles, l’exécution côté client est soit trop gourmande en ressources soit trop risquée pour utiliser du web, HTML5 compris, et donc les développements natifs (au sens dépendant de l'OS) "lourds" C++, Java ont encore de beaux jours devant eux
  .
• De toute façon avec l'inertie des gros systèmes on est pas près de passer à un HTML5 qui n'a pas encore fait ses preuves

[seb012007]

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 ?"

Oui bon d'accord le titre du topic aurait dû comporter HTML5 + Js m'enfin je pense que tout le monde avait compris.

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

Qu'est ce qui te permet d'affirmer cela?

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

Ben à part que ce type d'application se généralise de plus en plus, non rien de nouveau en effet.

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

Tout dépend de quelles applis professionnelles on parle. Pour moi quand on parle de progiciels on parle surtout d'applications fortement orientées client/serveur. Et de plus en plus les entreprises demandent du RIA pour cela.

Et pour rappel beaucoup d'applications pro tournent encore sur du Mainframe, donc tout est sur le serveur et la partie client consiste juste en une connexion telnet. On peut très bien ajouter une couche RIA par dessus ça

[Paul TOTH]

Je résume mon propos pour éviter toute confusion:

• Dire que dans un an tous les développements natifs seront remplacés par du développement Web est idiot dans la mesure où le navigateur, on le code en quoi ??? En techno native, non ?
  
• S'extasier devant le HTML5 est un peu bizarre dans la mesure où HTML5 est une norme encore instable qui arrive après la guerre. Le besoin a été comblé par plusieurs technos maintenant très répandues.
  
• De toute façon même une fois la norme stabilisée, les implémentations seront très probablement dépendantes du navigateur comme avec le JS actuellement.
  
• Il est tout à fait possible de faire de très jolis applis web avec les technos existantes (HTML5 ne présente donc pas vraiment d'intérêt)
  
• La grosse problématique du web est de pouvoir accéder aux ressources matérielles du client (surtout en mobile) mais la solution viendra des APIs du navigateurs qui seront de toute façon accessibles avec les technos existantes.
  
• Pour les grosses applis industrielles, l’exécution côté client est soit trop gourmande en ressources soit trop risquée pour utiliser du web, HTML5 compris, et donc les développements natifs (au sens dépendant de l'OS) "lourds" C++, Java ont encore de beaux jours devant eux
  .
• De toute façon avec l'inertie des gros systèmes on est pas près de passer à un HTML5 qui n'a pas encore fait ses preuves

Mais Windows 8 ne propose pas de développer dans un navigateur, il propose en JS et HTML d'adresser les objets système comme un ListView.

Microsoft propose de développer des applications "natives" en JS/HTML

[xelab]

Dire que dans un an tous les développements natifs seront remplacés par du développement Web est idiot [..]

C'est vrai... et en même temps personne n'a dit ça au final, si on lit bien le tweet original... C'est assez aberrant que la news n'ait pas été corrigée et qu'un débat soit parti sur une interprétation complètement contraire au sens initial du tweet.

[zeyr2mejetrem]

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

Pour faire de la vue, OK, c'est bien HTML/Js.
Pour faire du métier ou du traitement un peu lourd c'est pas fait pour ...
Maintenant, j'ai peut être tord mais j'aimerai voir un exemple qui me contredise (avec du vrai traitement et de la base de donnée, pas un éditeur de texte ...)

Tout dépend de quelles applis professionnelles on parle. Pour moi quand on parle de progiciels on parle surtout d'applications fortement orientées client/serveur. Et de plus en plus les entreprises demandent du RIA pour cela.

Oui. Du client LOURD.
Quant aux entreprises qui demandent du RIA, je peux te garantir qu'elles déchantent souvent et finissent même par revenir soit vers du lourd, soit vers un modèle du type RCP/Java Web Start.

Et pour rappel beaucoup d'applications pro tournent encore sur du Mainframe, donc tout est sur le serveur et la partie client consiste juste en une connexion telnet. On peut très bien ajouter une couche RIA par dessus ça

Ce n'est pas incompatible avec ce que je dis, à savoir que les traitements sont faits côté serveur et que le front-office n'a pas besoin de HTML5, XHTML+Js suffisent amplement ...

[zeyr2mejetrem]

Mais Windows 8 ne propose pas de développer dans un navigateur, il propose en JS et HTML d'adresser les objets système comme un ListView.

Microsoft propose de développer des applications "natives" en JS/HTML

Bref, un moteur de navigateur intégré dans Metro qui va rendre ton HTML/Js.
Pour moi, ce n'est pas une révolution.

Mon problème est peut être le suivant:
Pour moi une application qui n'a ni base de donnée, ni couche "métier" n'est pas représentative du marché du développement.

OK, dans Metro on pourra monter une petite "applet" en HTML/Js ... et alors ?

[seb012007]

Quant aux entreprises qui demandent du RIA, je peux te garantir qu'elles déchantent souvent et finissent même par revenir soit vers du lourd, soit vers un modèle du type RCP/Java Web Start.

C'est pas la tendance que je constate, y a qu'à voir le nombre d'offres d'emplois pour des dev Flex ou des spécialistes Js.

Ce n'est pas incompatible avec ce que je dis, à savoir que les traitements sont faits côté serveur et que le front-office n'a pas besoin de HTML5, XHTML+Js suffisent amplement ...

Là on est d'accord

[ZiGoM@r]

Le web du futur nécessitera donc de la compilation, des adaptations au hardware, du stockage local, des sockets etc... Finalement, le jour ou le web sera devenu du natif (en moins performant) on pourra dire que la web aura remplacé le natif.
Standardiser les API est une bonne chose et personne ici ne dit le contraire mais qui a attendu cela pour coder son application en flash (qui n'a d'ailleurs rien remplacé ou presque) ou autre ? Aussi, au vu du temps de réaction du w3c, les technologies futures risquent-elles encore de se voir standardisées bien après la guerre...
Sun et Adobe existent depuis assez longtemps pour pouvoir conclure que la révolution n'aura pas lieu. Maintenant, que HTML5 et JavaScript ne soit utilisé respectivement que comme API et bytecode standard est certainement très utile, voir nécessaire, mais les besoins auxquels répondent le natif sont totalement différents et ne disparaîtrons pas, au contraire !

[I_Pnose]

Ouais. Dans la réalité, si les choses bougeaient si vite dans l'arrière boutique, je ne serais sans doute pas de ceux qui maintiennent du code vb6 dans leur boite.

[camus3]

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

Ces 2 webapps sont faites en flash.

[Paul TOTH]

Bref, un moteur de navigateur intégré dans Metro qui va rendre ton HTML/Js.
Pour moi, ce n'est pas une révolution.

non, HTML est utilisé comme XML dans d'autres langage, pour le design de l'appli et les binds avec des composants systèmes. Ensuite JS fait le reste.

Mon problème est peut être le suivant:
Pour moi une application qui n'a ni base de donnée, ni couche "métier" n'est pas représentative du marché du développement.

OK, dans Metro on pourra monter une petite "applet" en HTML/Js ... et alors ?

Mais on le faisait déjà il y a 20 ans avec Visual Basic, qu'est ce qui empêcherais Javascript d'utiliser les connexion BDD de Microsoft ou d'écrire une couche métier ? JS est tout de même un peu plus évolué que VB (j'ai lâché le produit à la version 3 ceci dit) !

En tant que développeur Delphi, je ne suis pas pour l'harmonisation des langages et du "tous sous JS", mais ça reste pourtant techniquement tout à fait réalisable.

[zeyr2mejetrem]

non, HTML est utilisé comme XML dans d'autres langage, pour le design de l'appli et les binds avec des composants systèmes. Ensuite JS fait le reste.

Et JS, pour fonctionner, nécessite bien un moteur Javascript (Webkit, Gecko ou Trident...), non ?

Mais on le faisait déjà il y a 20 ans avec Visual Basic, qu'est ce qui empêcherais Javascript d'utiliser les connexion BDD de Microsoft ou d'écrire une couche métier ? JS est tout de même un peu plus évolué que VB (j'ai lâché le produit à la version 3 ceci dit) !

Js n'est pas plus évolué que VB (du moins les versions actuelles).
De plus, si Javascript utilise des couches natives (OLE, ODBC...) il perd son intérêt en tant qu'alternative au natif ...

En tant que développeur Delphi, je ne suis pas pour l'harmonisation des langages et du "tous sous JS", mais ça reste pourtant techniquement tout à fait réalisable.

Quant à moi je suis contre l'optique du langage unique.
Et ce n'est pas parce qu'une chose est réalisable qu'elle est souhaitable

[Paul TOTH]

Et JS, pour fonctionner, nécessite bien un moteur Javascript (Webkit, Gecko ou Trident...), non ?

et VB un Runtime, Java une JVM... et .Net un CLI, on s'éloigne du natif même avec les outils modernes...après dans quelle mesure il est possible de compiler du Javascript en natif...c'est ce que fait le JIT de toute façon.

Js n'est pas plus évolué que VB (du moins les versions actuelles).
De plus, si Javascript utilise des couches natives (OLE, ODBC...) il perd son intérêt en tant qu'alternative au natif ...

en fait je pense que l'idée c'est dans l'autre sens, permettre de développer "nativement" avec les outils du Web...probablement aussi pour dénaturer le Web et en faire du Metro, donc du Windows, donc du Microsoft Comme IE6 qui a la peau dure.

Quant à moi je suis contre l'optique du langage unique.
Et ce n'est pas parce qu'une chose est réalisable qu'elle est souhaitable

Je préfère JS à VB...mais ma préférence va toujours au Pascal...partant de là mes souhaits et la réalité ne sont pas toujours d'accord

[_skip]

et VB un Runtime, Java une JVM... et .Net un CLI, on s'éloigne du natif même avec les outils modernes...après dans quelle mesure il est possible de compiler du Javascript en natif...c'est ce que fait le JIT de toute façon.

Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Par rapport au C++, oui, dotnet nous a fait gagner en productivité et permet d'écrire un code plus clair et plus maintenable selon moi, et plus stable. Y a t-il un coût en performances ? Bien sûr de l'ordre de 30%, ce qui est acceptable pour la plupart des applications.

La situation est-elle alors comparable avec js+html ? Non :
* Le coût en performances n'est pas de 30% avec js+html, il est beaucoup plus élevé, sans doute 500% à 1000%. Le moindre accès à une variable impose de consulter un dictionnaire.
* Cette perte de performances se faisait dans le cadre de machines dont la puissance doublait tous les 18 mois. Ici la puissance vient d'être divisée par 20.
* Dotnet permettait d'accroître la productivité. Js+html la diminue.

Enfin, le sens de l'histoire jusqu'à présent, c'était d'accroître la productivité au détriment des performances. Rien de tel avec js+html. Le seul intérêt de js+html c'est de prétendre à être un esperanto, ce qui est relativement faux (support restreint de html5 sur les postes windows existants et sans doute anciens iphones) et à relativiser par l'existence d'alternatives viables

Merci beaucoup DonQuiche, quand je lis ça j'ai moins l'impression d'avoir loupé le virage du RIA en pur html/javascript. Je trouve même que ce que fait html5 (au sens large), certaines technos font la même chose depuis des années avec des outils puissants (Silverlight et flash entre autre pour ne pas le nommer) et là soudain, un comité, après moult houleuses délibérations (qui prennent des années) nous pond un "standard" et hop tout le monde s'accorde à dire que c'est le futur et que le reste n'a aucune raison d'être.
On a pourtant au coeur de tout ça javascript, un langage conçu à la base pour servir à faire des petits bricolages plus qu'autre chose, un truc dont presque tout le monde s'accord à dire qu'il n'est pleinement satisfaisant ni sur la performance, ni sur la portabilité, ni sur le reste (typage, organisation, scope, sécurité, etc...).

Est-ce que je dénigre? En fait je constate que reprendre du code javascript est souvent une tâche horrible, et que ça a beau être standard, il y a toujours des différences subtiles entre les navigateurs qui demandent beaucoup de test sur différentes configs, et rarement du test facilement automatisable.

Lorsque je code en java, .net, c++, ou même python (lui aussi interprété). Malgré leurs défauts je sais que tout fonctionne "comme codé" en exécution sauf si l'utilisateur me fait une grosse variante (runtime exotique).

Donc avec ce que je vois de JS aujourd'hui je suis très sceptique avec le côté "coder une fois, faire tourner sur iPhone, Android, Desktop" etc... Je sais beaucoup ne cessent de dire que la situation actuelle c'est la faute à IE, peut être mais franchement ce n'est pas une excuse que je peux facilement sortir de mon chapeau devant un client.

Alors je suis plein de doutes quand j'entends dire que le html/js dans le navigateur c'est le futur de mon métier car avec ce que je vois de ces technos web aujourd'hui, il reste beaucoup de chemin à faire...
C'est peut être le futur de youtube, de gmail, de messenger, de l'application iPhone X qui fait prout mais j'ai encore du mal à imaginer une simple caisse enregistreuse codée là dessus. Ne serait-ce que pour l'accès aux périphériques...

Accessoirement, et c'est surtout là la raison de cet engouement, il offre d'autres débouchés à une pléthore d'équipes web js+html moins coûteuses.

Peut être mais les tests, ça coûte plutôt cher aussi. A moins que des supers outils se développent ou que des garanties sérieuses de respect inconditionnel d'une spécification super stricte et sans ambiguïté soient fournis au développeur.

Ce n'est pas impossible en soi. Mais j'attend de voir, rester avec mes technos et ma mentalité dépassés encore un moment.

[Uther]

Je résume mon propos pour éviter toute confusion:

• Dire que dans un an tous les développements natifs seront remplacés par du développement Web est idiot dans la mesure où le navigateur, on le code en quoi ??? En techno native, non ?
  
• S'extasier devant le HTML5 est un peu bizarre dans la mesure où HTML5 est une norme encore instable qui arrive après la guerre. Le besoin a été comblé par plusieurs technos maintenant très répandues.
  
• De toute façon même une fois la norme stabilisée, les implémentations seront très probablement dépendantes du navigateur comme avec le JS actuellement.
  
• Il est tout à fait possible de faire de très jolis applis web avec les technos existantes (HTML5 ne présente donc pas vraiment d'intérêt)
  
• La grosse problématique du web est de pouvoir accéder aux ressources matérielles du client (surtout en mobile) mais la solution viendra des APIs du navigateurs qui seront de toute façon accessibles avec les technos existantes.
  
• Pour les grosses applis industrielles, l’exécution côté client est soit trop gourmande en ressources soit trop risquée pour utiliser du web, HTML5 compris, et donc les développements natifs (au sens dépendant de l'OS) "lourds" C++, Java ont encore de beaux jours devant eux
  .
• De toute façon avec l'inertie des gros systèmes on est pas près de passer à un HTML5 qui n'a pas encore fait ses preuves

De toute facon le constat de départ est foireux, l'interprétation du tweet par le newsers particulièrement.
Il est plus qu'évident que HTML5, CSS3, WebGL, Javascript, ... ne pourront pas remplacer toutes les applications natives et surtout pas dès l'année prochaine.
Par contre dans pas mal de cas, c'est déjà possible. Et vu l'évolution assez rapide du web ces derniers temps, je pense qu'en effet le HTML 5 à tout ce qu'il faut pour remplacer les applications lourde dans de nombreux cas ou ce n'était même pas imaginable avant.

C'est vrai... et en même temps personne n'a dit ça au final, si on lit bien le tweet original... C'est assez aberrant que la news n'ait pas été corrigée et qu'un débat soit parti sur une interprétation complètement contraire au sens initial du tweet.

Ça fait un moment que les news de developper.com ressemblent de plus en plus a des invitations au troll. Les modérateurs doivent s’ennuyer sur les sujets trop techniques.

Mais on le faisait déjà il y a 20 ans avec Visual Basic, qu'est ce qui empêcherais Javascript d'utiliser les connexion BDD de Microsoft ou d'écrire une couche métier ? JS est tout de même un peu plus évolué que VB (j'ai lâché le produit à la version 3 ceci dit) !

Difficile de dire que le JS ou le VB sont plus évolués l'un que l'autre. C'est deux langages différents qui ont en commun de ne pas avoir été crée pour ce a quoi il servent aujourd'hui.
Le premier a une orientation objet par prototype, ce qui le rend aux yeux de ces adeptes vraiment "puissant", pour moi c'est surtout tellement souple que ça deviens très vite le bordel. Même si en général ça marche, on écrit souvent des choses sans être très sur de ce que l'on fait. Enfin c'est complètement inadapté à la plupart des outils d'aide au programmeur (complétion, refactoring,...).
Visual Basic était a la base une langage pour débutant qui a été modifié et a gagné un modèle objet certes plus strict que le modèle par prototype, mais qui me déroute vraiment.

Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Ca doit bien faire 2 ans que tous les navigateurs font du JIT, certains mieux que d'autre. Il faut dire que le Javascript n'est pas le langage le plus adapté pour ça.

[DonQuiche]

Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Il l'est avec Firefox et Chrome, oui, depuis un moment maintenant.

Malheureusement, cela reste lent : la VM doit toujours aller consulter un dico pour accéder à la moindre variable et fonction, les vérifications de types doivent toujours être réalisées à l'évaluation (pour une addition par exemple, le membre gauche doit toujours tester le type du membre droit et traiter chacun des cas), toutes les opérations légères demeurent lourdes (les opérateurs addition, référencement, égalité, etc sont toujours des appels de fonction avec appel au dico), le moindre entier demeure en réalité un objet lourd (type, dictionnaire des membres, etc).

Bref, toutes ces choses qui, avec un typage statique et fort sont résolues à la compilation demeurent ici presque toujours résolues à l'évaluation. En théorie, il serait possible d'aller plus loin en exploitant le fait que l'essentiel du code dynamique peut être retraduit en langage statique : d'abord on reconstruit une hiérarchie de types (amalgamer les objets ayant les mêmes membres), ce que les navigateurs font déjà, puis on procède à une analyse statique approfondie afin de prédire le pseudo-type de nombreuses variables et on utilise ensuite cette information pour résoudre le plus de choses possibles à la compilation.

Hélas, l'analyse statique est coûteuse et même avec des algorithmes simples pour ce problème particulier (O(n^3) / O(n^4)), quelques dizaines de ko de code à traiter (disons 500 à 2000 lignes) suffisent typiquement à dépasser les dix secondes, puis la minute quand celui-ci double, puis une heure en multipliant encore par cinq, etc... Accessoirement, si le problème est très intéressant, je pense que tous ceux qui s'y sont frotté seront d'accord avec moi pour dire que c'est une horreur à écrire : on se retrouve typiquement à générer plusieurs représentations du code sous diverses formes - graphes de dominance, arbres, piles, etc - qu'il faut ensuite modifier et resynchroniser les unes à partir des autres tout en optimisant sévèrement les performances, faire passer le tout dans des machines de turing, ...

[Uther]

Pour faire de la vue, OK, c'est bien HTML/Js.
Pour faire du métier ou du traitement un peu lourd c'est pas fait pour ...
Maintenant, j'ai peut être tord mais j'aimerai voir un exemple qui me contredise (avec du vrai traitement et de la base de donnée, pas un éditeur de texte ...)

Par exemple ça : http://mbebenita.github.com/Broadway/broadway.html
D'après l'auteur c'est 4 fois plus lent que l'équivalent C, mais ca reste quand même une bonne performance.

Pour la base de donnée, de toute façon, ça n'a que très rarement intérêt coté client.

Bref, toutes ces choses qui, avec un typage statique et fort sont résolues à la compilation demeurent ici presque toujours résolues à l'évaluation. En théorie, il serait possible d'aller plus loin en exploitant le fait que l'essentiel du code dynamique peut être retraduit en langage statique : d'abord on reconstruit une hiérarchie de types (amalgamer les objets ayant les mêmes membres), ce que les navigateurs font déjà, puis on procède à une analyse statique approfondie afin de prédire le pseudo-type de nombreuses variables et on utilise ensuite cette information pour résoudre le plus de choses possibles à la compilation.

La dernière version (ou la béta en cours, je suis plus sur) de Firefox fait de l'inférence de type, le gain est sensible mais c'est encore loin d'être parfait.

[DonQuiche]

La dernière version (ou la béta en cours, je suis plus sur) de Firefox fait de l'inférence de type, le gain est sensible mais c'est encore loin d'être parfait.

Oui et je ne pense pas que ça le sera, les gains issus de ces stratégies vont être de plus en plus faibles. A mon avis les espoirs d'optimisation reposent plutôt sur l'intégration de nouvelles API au sein des navigateurs, comme le projet de Firefox de fournir des appels JQuery natifs (les appels JQuery JS seraient remplacés à la volée par les appels au code natif). Malheureusement la limite de cette stratégie et des autres, c'est que les dévs doivent pondre un code pour le plus petit dénominateur commun, le plus lent des navigateurs parmi leurs clients : aujourd'hui, IE6.

[regisportalez]

Et tes navigateurs , ils tournent sous quoi ? un os javascript ? et tes navigateurs ils sont codés en quoi ? javascript ?et le dom ? et les moteurs javascript , ils sont codés en quoi ? javascript ? pour que des personnes comme toi puissent se la jouer HTML5 , d'autres se sont cassé le cul à développer des moteurs qui tournent relativement vite dans des technos que tu dénigres. On appelle cela être ignorant.

A la base je suis développeur C/Cuda donc je n'ai vraiment rien contre les autres langages.
Non je ne dénigre rien, ce n'est pas mon genre.
Mais si on critique les technos en disant qu'elles se basent sur d'autres trucs, on ira pas bien loin...