Lors de la seconde keynote de cet IDF , Renée James a tenu à nous parler de son concept de « Transparent Computing ». Si cela inclut des notions de sécurité ou un concept marketing tel que le « cloud flexible » on retiendra surtout la volonté d'Intel d'unifier le développement à travers les plateformes et les OS, notamment grâce au HTML5.
Vie de développeur = VDM ?
Et pour débuter sa conférence, Renée James nous a montré une vidéo au sein de laquelle la vie de développeur était présentée de manière bien amère : celui-ci croule en effet sous les plateformes, les OS, les stores... et n'aurait jamais assez de temps pour s'adapter, le tout avec un environnement qui ne cesse d'évoluer. La monétisation est aussi un gros problème, une majorité d'applications ne permettant pas à ceux qui en sont à l'origine de vivre.
Un constat qui peut paraître assez réaliste, mais qui ne représente sans doute pas la vision que peut avoir l'ensemble des développeurs qui produisent des applications au quotidien. Malheureusement, cette vidéo un brin anxiogène n'a pas été mise en ligne.
Vanter HTML5 après la sortie de Zuckerberg... c'est moche
Quoi qu'il en soit, Intel continue de penser que la solution est toute trouvée : le HTML5. Fonctionnant sur l'ensemble des plateformes disponibles, pouvant être exploité au sein d'applications natives, il ne cesse d'afficher des performances et des capacités plus importantes. Mais cette annonce tombait mal : le lendemain de la fameuse interview de Mark Zuckerberg, que James a évoquée non sans une certaine amertume, il était plus complexe de tenir ce discours.
Mais outre ce cas particulier, il faudra bien que les géants du secteur finissent par s'accorder afin de permettre à des sociétés de taille moyenne d'assurer leur présence sans avoir à embaucher une armée de développeurs, souvent complexe à constituer tant les talents sont rares. Intel annonce ainsi que selon ses statistiques, 40 % des développeurs exploitent déjà HTML5 et autant compteraient y passer.
Le géant de Santa Clara semble néanmoins conscient que le HTML5 dispose encore de nombreux défauts, le fait même d'être rendu par un navigateur étant sans doute le principal, et précise que beaucoup de travail sera encore nécessaire. Mais Intel semble continuer à fonder ses espoirs sur une telle solution.
Un choix d'autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s'éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.
Quoi qu'il en soit, plusieurs démonstrations ont été effectuées afin d'évoquer les possibilités offertes par le HTML5, comme vous pourrez le voir sur ces deux vidéos :
River Trail nativement supporté par Firefox en 2013, une nouvelle Developer Zone
De son côté, Intel en a profité pour annoncer qu'il mettait à jour son site dédié aux développeurs, et que celui-ci proposerait toute une palette d'aides et d'outils pour les adeptes de l'HTML5. Certains sont déjà disponibles par ici, comme un « Playground » vous permettant de tester du code en ligne. On attendra néanmoins de voir ce qui arrive par la suite afin de juger de la pertinence de la chose.
On notera aussi que le projet River Trail, actuellement proposé via une extension pour Firefox devrait être supporté nativement d'ici à 2013. Pour rappel, celui-ci consiste à l'exploitation de plusieurs coeurs via du code Javascript. Le malheur des développeurs web est en effet que JS soit au centre de leurs projets, celui-ci n'ayant pas évolué sur certains aspects de ce genre.
Google tente bien de contourner le problème en misant sur Go, mais Intel ne semble pas privilégier vraiment cette approche. Reste maintenant aux développeurs à trancher, et à se positionner entre le natif et le HTML5, la présence sur l'ensemble des plateformes ou le fait de ne se concentrer que sur certaines d'entre elles...
Commentaires (36)
#1
Elle est comment l’API HTML5 pour un driver ?
" />
#2
à la base le html5 c’est pas censé être fait pour les page web ? j’ai du louper l’étape ou le html 5 passe du statue de language de site web a a language de programmation ^^”
#3
#4
#5
#6
Un choix d’autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s’éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.
Justement, le but n’est-il pas pour Intel que les app dev passent sur HTML5 pour rendre portable les app mobiles majoritairement sous ARM ?
Tout ca bien sur en proposant des outils specifiques a Intel comme River Trail.
Faut ptet que j’arrete de regarder X-Files, je me mulderise et en plus je pense avoir raison
#7
#8
#9
#10
#11
#12
Le plus gênant c’est pas vraiment l’html qui correspond plutôt à la couche de présentation mais le JavaScript et bon à part voir des gens dirent ça à l’air génial html5 (surtout les non initié), peu le manipule vraiment (à part les dev de chez intel, google et consort pour faire de jolie démo), et bon le full html/css/js j’y crois pas trop ça sera surement moins efficace, réactif et simple à développer que du natif ou java/c#.
Vivement la fin du JS mais qui le remplacera donc ???
#13
Vivement la fin du JS mais qui le remplacera donc ???
Et pourquoi ça ? Je trouve qu’à son application actuelle, javascript est un langage qui fonctionne bien. Je l’utilise même via node.js et il se porte comme un charme…
#14
#15
#16
#17
#18
#19
#20
#21
Le jour où il feront ça, le langage utilisé ne sera plus un problème et certains ne seront plus tenté de faire sortir un langage de script du navigateur pour en faire un langage de programmation qui n’apportera, seul, rien de plus que ce qui existe actuellement. Bref, à mon avis actuellement, ils dépensent du temps et de l’argent mais pas sur le bon problème.
#22
#23
le faite qu’il soit pas typé (après certain le préfère comme ça), que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça), une vrai et bonne documentation, un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.
Le fait qu’il soit pas typé, ça me gêne pas personnellement. Pour le côté objet, c’est hard mais faisable. Et créer un framework pour gérer ça plus simplement prend 30 minutes à faire. Pour ce qui est de la documentation, ben la MDN permet de couvrir l’usage de javascript, je ne vois pas le problème. Et enfin, les débuggers s’améliorent constamment (mon préféré est Dragonfly, web Inspector est pas mal. Et node en intègre un pour le out of browser).
#24
#25
#26
Un choix d’autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s’éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.
Ca fait pourtant tellement longtemps que les développeurs d’assembleur disent que les OPCODES x86 sont d’une absurdité incroyable… Ca serait un bon début si les fondeurs pouvaient se mettre d’accord sur un standard, au moins pour les instructions non optionnelles. Ca permettrait d’avoir des programmes compilés portables sur toutes les machines sans avoir besoin de les recompiler.
C’est beau de rêver…
#27
Je ne suis pas sur d’avoir bien compris la tirade sur le go de Google à la fin.
Go comme alternative au Javascript ? Vraiment ?
#28
Merci pour le mdn je ne savais pas qu’on y trouvait une doc complète.
" />
" />
Dans le sens ce n’est pas un langage objet c’est la création de classe, d’interface la possibilité de faire de l’héritage ….
Je fais de l’asp.net le côté c# ne me pose pas de problème mais dès que certaine opération nécessite l’utilisation exclusive du JS
Si demain on me demande de faire des application full Html5/Css/JS
#29
#30
#31
#32
#33
#34
#35
#36