Le web c'est la plate forme ultime, ca y est, maintenant j'y crois : tout le monde peut avoir un smartphone et un abonnement 3G à un prix presque abordable, des tablettes multitouch se vendent sur le net à moins de 100 euros parce qu'elles n'ont que 256mo de RAM.
Tous ces beaux objets ont chacun leur propre framework de développement mais intègrent des navigateurs théoriquement capable d'héberger des applications riches entières se basant sur Javascript, l'API Canvas (voire SVG) pour le rendu 2D voir 3D avec WebGL. Sont également disponibles de la communication réseau, du stockage local relationnel (IndexDB), un mode d’exécution hors connection. Pas d'inquiétude non plus sur les moyens de diffuser ces applis : Google et Mozilla ont prévu ou déjà sorti leurs boutiques en ligne dédiées.
Alors qu'est ce qui manque ?? Ma réponse est dans le titre, ce sont les outils de développement, autant au niveau des IDE que de la création de contenu multimédia, ainsi qu’une certaine maturité des API.
Adobe et Macromedia ont développé Flash avant tout en proposant des outils aux créatifs. L'aspect développement n'est venu qu'après en complément. Ici avec HTML5, c'est un peu l'inverse, on a beaucoup d'API technique mais peu d'outil et surtout vraiment peu de choses orienté contenu. (A moins que vous comptiez les produits Adobe récemment réorientés vers HTML5 ?)
Je suis conscient qu'il existe des IDE très avancés ciblant Javascript (Webstorm, Aptana, FlashDevelop, FDT, je découvre juste) mais la syntaxe et le typage dynamique du langage semble limiter les fonctionnalités de refactoring possibles. Il semble naturel que chaque équipe souhaite choisir le langage de son choix en fonction de ses opinions et de son expérience. Et là les choses se gâtent un peu. Les solutions ne sont pas vraiment satisfaisantes.
Google propose GWT qui convertit un sous ensemble de Java en Javascript et est accompagné d'un ensemble de bibliothèques, et de nombreuses autres sont proposées par des tierces parties. Le projet est maintenant stable mais n'avance plus autant car une grande partie de l'équipe a basculé sur Dart, qui se veut être un langage de remplacement de JS. Ceci créée une situation confuse : D'un coté GWT est moins attractive, Google s'est brouillé avec Mozilla et les inconditionnels d'un JS dynamiquement typé et Dart est encore à l'état de preversion technique inutilisable. Imaginer la tête d'un chef de projet fan de Google qui doit choisir une techno pour former une nouvelle équipe !
D'autre langages peuvent être convertis en JS, une liste entière se trouve ici : https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS .
Mais je ne vois rien qui sorte du lot et qui puisse s'imposer comme une alternative crédible et surtout sur lequel un ensemble d'outils puisse être bâti.
Enfin je cite sans le considérer réellement l'autre projet de Google "Portable Native Client", qui vise à standardiser un format d'application quasi natives (sources C++, API Chrome + OpenGL) packagées en byte code LLVM pour la portabilité. Déjà ce n'est pas prêt et la réponse négative de Mozilla de collaborer à ce type d'approche augure mal de sa diffusion. Pourtant techniquement ça peut surement fonctionner.
Revenons donc aux bibliothèques JS. De très nombreuses sont disponibles et certaines ont évoluées vers des frameworks RIA entiers (ExtJS, SmartClient). Malheureusement elles sont basées sur le DOM, et non Canvas et je ne vois pas d'évolution en cours dans cette direction. Si Canvas a été créé, c'est bien que l'on ne peut pas tout faire avec DOM et CSS, ou alors j'ai raté un épisode ? Evidemment le poids de la rétro compatibilité pèse lourd.
Il existe certes quelques frameworks utilisant Canvas, mais ils sont quasi exclusivement orientés jeux, et centrés sur une boucle de rendu et non sur un système d’évenements. J’ai trouvé pour l’instant PlayN (cross platform Android/HTML5, utilisant GWT) et CAAT (pur js).
Enfin, une étude plus poussée de l'état des API exposées par les navigateurs font apparaître des zones d'ombres génantes. Par exemple l'API de saisie des évenements claviers est implémentées de façon très variables entre les navigateurs, et il est même tellement difficile de déterminer précisément les caractères saisis sur les claviers internationaux que les développeurs de l'éditeur ACE ont dû placé une TextArea cachée sous leur composant pour récupérer les caractères saisis.
Les jeux HTML5 attendent également un meilleur support du plein écran et la capture du curseur de la souris. J'ai trouvée une liste détaillées de souhaits ici :
http://codeflow.org/entries/2011/sep/11/webgl-and-html5-challenges-for-the-future/
Je souhaite me préparer à des futurs projets web RIA et pour l’instant je me forme sur des librairies Javascript et les API fournies par les navigateurs. Mais j’imagine que la plate forme HTML5 n’explosera que quand des outils de productivité seront disponibles pour les développeurs et les créatifs et que quand les imperfections des API seront comblées. En attendant les hackers sont à la fête et profitent du rythme d'innovation rapide et de la pléthore de technos proposées.
# Il y a aussi HaXe
Posté par chansen . Évalué à 2.
HaXe est un langage typé inspiré d'ActionScript (et donc apparenté à JS).
Il est accompagné du framework NME reprenant l'API de Flash ciblant IOS et Android et d'un autre framework, Jeash , moins utilisé il me semble, ciblant HTML5. C'est drôle que j'ai oublié de le mettre dans le journal initial car c'est le seul projet qui répond vraiment à ma recherche en fait.
J'ai du mal à saisir le lien de parenté entre ActionScript 3 et Javascript. A priori tous deux sont liés au niveau de la norme Ecmascript 3. Concrêtement peut on dire que c'est le même langage ?
[^] # Re: Il y a aussi HaXe
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
C'est la même grammaire si on veut, mais le vocabulaire est différent en majorité.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Raphaeljs est peut-être ton ami
Posté par Narmer . Évalué à -3.
http://raphaeljs.com/
Let us know
# du RIA avec canvas ??
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
J'ai du mal à comprendre ce que tu veux faire exactement. Tu veux faire une interface utilisateur avec canvas ?
Parce que si c'est le cas, canvas n'est pas fait pour ça.
[^] # Re: du RIA avec canvas ??
Posté par steph1978 . Évalué à 2.
Je me suis fait la même réflexion.
Pour moi, canvas est plus bas niveau que DOM.
Ça doit servir à remplacer flash pour des animations et de jeux.
Mais plus une application de gestion, pouvant utiliser DOM, il faudrait recréer tout les widgets du HTML.
# Dart
Posté par YBoy360 (site web personnel) . Évalué à 0.
j'aime vraiment beaucoup par rapport à javascript, le moteur natif Dart vient d'être intégrée à Chromium :
http://blog.chromium.org/2012/02/tech-preview-of-chromium-with-dart.html
L'ide s'améliore rapidement. Aujourd'hui c'est encore un peu jeune, mais les choses avancent vite.
J'encourage à regarder.
# "Portable Native Client"
Posté par steph1978 . Évalué à 3.
Ou comment ré-inventer les applets java.
Que reproche/reprochait-on aux applets ? En gros la relative difficulté de faire des interfaces graphique en AWT/SWING.
Peut être à cause du manque d'outil d'ailleurs.
Et peut être la difficulté en Java2D et Java3D, mais j'ai moins joués avec.
Pour le reste, cela propose une très bonne architecture de sécurité: sandboxing, permissions, certificats. Et une programmation événementiel proche de DOM+JS.
[^] # Re: "Portable Native Client"
Posté par Moonz . Évalué à 1.
Le but de NaCl est de remplacer javascript, pas les applet Java : ça communique avec le DOM, contrairement à une applet qui est juste un gros carré dans la page qui n’interagit pas avec elle.
[^] # Re: "Portable Native Client"
Posté par steph1978 . Évalué à 2.
Je postule que NaCl+DOM=Applet, pas que NaCl=Applet.
[^] # Re: "Portable Native Client"
Posté par Moonz . Évalué à 2.
Arrête moi si je me trompe, mais il me semble que les applets n’avaient pas accès au DOM. Du coup je ne vois pas comment tu peux dire NaCl = applet.
Ou alors je n’ai rien compris à ta remarque.
[^] # Re: "Portable Native Client"
Posté par steph1978 . Évalué à 2.
En effet, je ne peux pas, d'où la négation dans ma remarque.
[^] # Re: "Portable Native Client"
Posté par Moonz . Évalué à 1.
Je suis le seul à avoir l’impression de rien comprendre à ce que tu racontes ? Je ne sais même pas si on est d’accord ou pas, au final
On reprend.
Les applets Java c’est, du point de vue de la page, comme une image : un carré d’une taille définie qui n’a aucune autre interaction possible avec les autres éléments de la page (l’arbre DOM).
NaCl, au contraire, ne possède pas d’espace réservé (tout comme la balise script ne possède pas d’espace réservé), mais peut manipuler le reste de la page en ajoutant des éléments à l’arbre DOM, en supprimer, modifier, etc. Encore
Du coup, non, NaCl ce n’est pas une « ré-invention des applets Java ». Tu devrais pouvoir faire avec NaCl des tas de choses que tu ne peux pas faire avec les applets Java.
# Dart
Posté par Sébastien B. . Évalué à 2.
Purée, j'ai vraiment du mal à comprendre Dart. Disons que jusqu'à aujourd'hui, on avait le javascript, seul langage implémenté par les navigateurs (et non par un plugin externe) pour rajouter de l'interactivité à une page web.
Le javascript, ça vaut ce que ça vaut, il y en a qui aiment, d'autres moins. Du coup, on a vu apparaître pas mal de solutions pour utiliser un autre langage qu'on compilerait vers du javascript. Exemple : Pyjamas pour Python. Il y a aussi le coffeescript qui est fait pour être compilé en Javascript. Il est évident qu'il n'y a pas de langage parfait et que chaque développeur préfèrera un langage voire un paradigme à un autre. Comme le dit le journal, il y a même Google qui a fait un framework Java, permettant de compiler du java en javascript.
À partir de là, est ce que la solution aux faiblesses du javascript, c'est un autre langage ??? Non franchement, perso j'y crois pas. On aura peut être quelque chose de meilleur que le javascript, mais pour moi, le problème est toujours là, à savoir, on ne peut utiliser qu'un seul langage de programmation pour le web dynamique ... Du coup, est ce qu'il n'y aurait pas moyen de faire un truc un poil intelligent du genre, créer un assembleur de haut niveau (genre comme le bytecode lua) bien adapté au web ce qui permettrait d'utiliser n'importe quel langage, voire d'en créer de nouveaux, que l'ont compilerait dans cet assembleur ?
Enfin voila, désolé pour le hors sujet mais il fallait que ça sorte.
[^] # Re: Dart
Posté par Larry Cow . Évalué à 2.
Genre on écrirait un module pour que LLVM produise ce bytecode depuis tous ces frontends? Ce serait cool. Et puis tant qu'à pas réinventer la roue, on utiliserait directement Javascript comme "bytecode".
Et puis on se retrouverait avec emscripten ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.