Discussion :

[Olivier Famien]

Facebook abandonne HTML5 pour son framework React Native
dans le développement de ses futures applications mobiles natives

Cette semaine, Facebook a accordé une interview à plusieurs journalistes dans la capitale anglaise. Devant les représentants d’organes de presse, David Mortenson, le directeur de l’infrastructure de développeur du réseau social a annoncé la fin du développement des applications mobiles avec HTML5 et JavaScript.

Dorénavant, le réseau social se consacrera au développement d’applications mobiles avec son framework JavaScript React Native. Aussi, vu le soutien apporté par les entreprises et Facebook y compris après la sortie d’HTML5, c’est un revirement de situation auquel on ne s’y attendait pas.

Il faut rappeler que React Native avait été présenté en 2013 et a été rendu open source à la conférence F8 2015 qui avait également servi d’appui pour présenter ComponentKit, le framework dérivé de React Native qui a été porté sur iOS. L’objectif de Facebook en implémentant ce framework est de simplifier la création d’applications natives mobiles tout en donnant aux développeurs les moyens de concevoir assez rapidement leurs produits.

Mortenson a encore rappelé ces avantages pendant l’interview en soulignant que React Native favorise une itération des développements mobiles « très, très » rapidement et permet également d’être productif. Le projet ayant gagné en maturité, Facebook se tourne entièrement vers son framework pour le développement d’applications natives sur les mobiles.

Il faut souligner que la firme tient particulièrement à ce projet en raison des limites rencontrées dans le développement des applications mobiles natives. En effet, en jetant un coup d’œil sur le développement des applications web, on constate que les projets les plus vastes s’achèvent rapidement, souligne Facebook.

Cette même célérité ne se voit pas lorsqu’il s’agit des projets mobiles. Aussi la firme a mis en œuvre ce framework afin de répondre à ce besoin de gagner en temps pour les projets mobiles. Facebook ajoute également ceci, « la raison pour laquelle nous concevons des applications natives sur ces plateformes propriétaires est que dès maintenant, nous pouvons créer de meilleures expériences qui sont plus compatibles avec le reste de la plateforme que ne nous pouvons sur le web ».

Pour concevoir ces applications natives, vous pouvez utiliser React Native avec JavaScript ou React qui est une bibliothèque JavaScript mise en œuvre par Facebook pour concevoir des interfaces utilisateurs.

Toutefois, il est bon de savoir que React Native ne s’inscrit pas dans la maxime « code once, deploy everywhere », mais plutôt « learn once, write anywhere ». Pour les francophiles, il faut simplement comprendre que React Native ne permet pas de concevoir un seul projet pour le déployer sur toutes les plateformes, mais permet d’apprendre les caractéristiques du framework afin de pouvoir coder facilement un même projet sur plusieurs plateformes en utilisant ce framework.

La firme affirme par ailleurs que plusieurs applications ont déjà été développées avec ce framework parmi lesquelles on peut citer Facebook Groups qui est une application hybride et Facebook Ads Manager qui est une application entièrement conçue avec Rect Native.

Source : The Register, Facebook, GitHub React Native, React

Et vous ?

Que pensez-vous de React Native ?

Est-ce un framework de trop ? Ou pensez-vous qu’il aura réellement du succès ?

[Paul TOTH]

ils abandonnent HTML5 ? très bien, il ne reste plus qu'à abandonner JavaScript et ils pourront enfin faire du développement sérieusement

[crodilus]

ils abandonnent HTML5 ? très bien, il ne reste plus qu'à abandonner JavaScript et ils pourront enfin faire du développement sérieusement

Abandonner HTML5 et JavaScript ? ! Qu'ils abandonnent le web alors ? Non ? !

[Paul TOTH]

Abandonner HTML5 et JavaScript ? ! Qu'ils abandonnent le web alors ? Non ? !

je suis certain que Facebook adorerait pouvoir remplacer les navigateurs, mais là question ici n'est pas sur l'accès Web à FaceBook, mais de l'accès Mobile.

Si HTML5 permet de créer des sites accessibles aussi bien sur PC que sur Mobile, on trouve de plus en plus d'applications "natives" sur mobile. Elles s'intègrent bien plus naturellement sur le mobile que n'importe quelle application Web.

Ensuite HTML5 est utilisé de façon embarquée pour développer une seule fois l'application pour Android ou iOS avec un bootstrap spécifique à la plateforme. Là FaceBook laisse tomber HTML5/DOM pour le remplacer par une API native afin de manipuler iOS depuis Javascript comme le montre cet exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var React = require('react-native');
var { TabBarIOS, NavigatorIOS } = React;

var App = React.createClass({
  render: function() {
    return (
      <TabBarIOS>
        <TabBarIOS.Item title="React Native" selected={true}>
          <NavigatorIOS initialRoute={{ title: 'React Native' }} />
        </TabBarIOS.Item>
      </TabBarIOS>
    );
  },
});

La seule chose que je n'ai pas compris c'est que d'après ce que je vois React Native c'est uniquement pour iOS...quid de l'appli Facebook pour Android ?

[SylvainPV]

Pour rappel, Sencha avait déjà envoyé gentiment balader les arguments de Facebook sur HTML5 : http://www.developpez.com/actu/50604...de-la-societe/

Rien de surprenant à ce que Facebook défende sa solution maison (même si React est web à la base, ils n'ont jamais été dans l'optique HTML5). Du côté de Google, on vend du Polymer et ça marche aussi très bien (essayez https://polymer-topeka.appspot.com/ sur vos mobiles).

Le web et le natif ne sont pas des technos concurrentes, ce sont des approches différentes:

Application native:
Application conçue spécifiquement pour une plate-forme avec le SDK propre à celle-ci.
Exclusivité, spécificité, performance, centré sur l’appareil

Web app mobile:
Site web optimisé pour un usage mobile
Universalité, pérennité, adaptabilité, centré sur le contenu

Vouloir faire du natif multi-plateforme c'est un non-sens. Ceux désirant une vraie expérience "native" suivront les guidelines du constructeur, au lieu d'empiler des couches d'abstraction et de chercher des compromis entre toutes les plates-formes supportées.

http://rexstjohn.com/is-react-native...orm-snake-oil/

[Paul TOTH]

Pour rappel, Sencha avait déjà envoyé gentiment balader les arguments de Facebook sur HTML5 : http://www.developpez.com/actu/50604...de-la-societe/

Rien de surprenant à ce que Facebook défende sa solution maison (même si React est web à la base, ils n'ont jamais été dans l'optique HTML5). Du côté de Google, on vend du Polymer et ça marche aussi très bien (essayez https://polymer-topeka.appspot.com/ sur vos mobiles).

Le web et le natif ne sont pas des technos concurrentes, ce sont des approches différentes:

Application native:
Application conçue spécifiquement pour une plate-forme avec le SDK propre à celle-ci.
Exclusivité, spécificité, performance, centré sur l’appareil

Web app mobile:
Site web optimisé pour un usage mobile
Universalité, pérennité, adaptabilité, centré sur le contenu

Vouloir faire du natif multi-plateforme c'est un non-sens. Ceux désirant une vraie expérience "native" suivront les guidelines du constructeur, au lieu d'empiler des couches d'abstraction et de chercher des compromis entre toutes les plates-formes supportées.

http://rexstjohn.com/is-react-native...orm-snake-oil/

il y a tout de même un problème dans ta définition d'application native, tout comme sous Windows tu n'est pas obligé d'utiliser les outils Microsoft pour développer en natif, tu n'est pas contraint d'utiliser XCode ou AndroidStudio pour développer "natif" sur iOS ou Android. et rien ne t'oblige a être centré sur un appareil, d'ailleurs entre un smartphone une phablette une "watch", il n'y a pas grand chose à voir.

Je ne suis pas non plus d'accord avec ta définition de l'app mobile, la pérennité n'est certainement pas une caractéristique du HTML ou des feuilles de styles dont les normes évoluent avec de méchantes cassures avec le passé.

Après, que Facebook développe comme des manches, ça c'est tout à fait possible.

[crodilus]

Tant qu'il n'y aura pas une homogénéité qui sera faite au niveau des terminaux portatifs (tablettes,smarthphone,iphone,...) on aura droit à tout et n'importe quoi, et à un beau paquet de "caca". C'est comparable à l’informatique d'il y a 30 ans, tout le monde à sa technologie propriétaire avec son matériel qui va avec.

Quand je vois le le nombre de couche pour arriver à un terminal mobile, je me dis que certain dirigeants des grosses boites informatiques doivent aimer les gros gâteaux à plusieurs couches.

L'orienté objet est déjà une jungle ou il faut une sacré machette pour y avancer correctement mais le mobile c'est l'Amazonie avec comme seul outil un couteau suisse.

Alors qu'ils y aient chacun de leur idées, de leurs frameworks, de leurs rustines révolutionnaires pour contourner l'incontournable mais ça n'apportera rien de constructif mis à part scinder un peu plus les communautés.

Le proverbe ne dit-il pas "diviser pour mieux régner" ?

[SylvainPV]

il y a tout de même un problème dans ta définition d'application native, tout comme sous Windows tu n'est pas obligé d'utiliser les outils Microsoft pour développer en natif, tu n'est pas contraint d'utiliser XCode ou AndroidStudio pour développer "natif" sur iOS ou Android. et rien ne t'oblige a être centré sur un appareil, d'ailleurs entre un smartphone une phablette une "watch", il n'y a pas grand chose à voir.

Ce ne sont pas les mêmes environnements de développement mais on passe toujours par le SDK et les API du constructeur. Et je suis bien d'accord qu'une montre n'a rien à voir avec un smartphone et une phablette, c'est pourquoi ça n'a pas de sens de vouloir faire une application native qui cible ces 3 classes d'appareils en même temps.

Je ne suis pas non plus d'accord avec ta définition de l'app mobile, la pérennité n'est certainement pas une caractéristique du HTML ou des feuilles de styles dont les normes évoluent avec de méchantes cassures avec le passé.

Pardon ??? Depuis quand le web n'est plus rétrocompatible ? Les sites faits il y a 20 ans tournent toujours sur ton navigateur que je sache. Il n'y a pas de cassure entre les normes web, la rétrocompatibilité est une contrainte inhérente au web. On ne peut pas se permettre de casser les millions de sites existants.

[Bono_BX]

L'orienté objet est déjà une jungle ou il faut une sacré machette pour y avancer correctement

C'est fatiguant ce genre d'absurdité ... je ne répondrais pas plus à ce troll que ceci : la programmation objet simplifie le code QUAND BIEN UTILISEE ! C'est sûr qu'entre les mains de manches, ça fait des catastrophes. Sinon c'est super simple et logique. Après, il faut bien entendu voir quelle est la "méthodologie" la plus adaptée au besoin : objet, fonctionnelle, événementielle ...

Application native:
Application conçue spécifiquement pour une plate-forme avec le SDK propre à celle-ci.
@SylvainPV : Exclusivité, spécificité, performance, centré sur l’appareil

Qu'entends-tu par là ? Si c'est "utilisation possible des exclusivités et spécificités", je suis d'accord. Par contre, si c'est "non portabilité", là, non : c'est pour cela que des technologies comme JAVA et Mono existent (entre autre) ; ce qui au passage invalide ta première phrase.

Web app mobile:
Site web optimisé pour un usage mobile
Universalité, pérennité, adaptabilité, centré sur le contenu

Si seulement tous les dev pouvaient t'entendre ...

[crodilus]

C'est fatiguant ce genre d'absurdité ... je ne répondrais pas plus à ce troll que ceci : la programmation objet simplifie le code QUAND BIEN UTILISEE ! C'est sûr qu'entre les mains de manches, ça fait des catastrophes. Sinon c'est super simple et logique. Après, il faut bien entendu voir quelle est la "méthodologie" la plus adaptée au besoin : objet, fonctionnelle, événementielle ...

Je n'ai jamais dit que c'était compliqué. L'orienté objet est une jungle, ce qui sous entend qu'il y a une profusion de framework, d'API,... Choisir les bons outils n'est pas toujours facile, à la limite c'est peut-être encore plus difficile que de maîtriser le langage en lui même.

Le concept est clair et précis la manière d'y arriver ne l'est pas toujours.

[Bono_BX]

L'orienté objet est une jungle, ce qui sous entend qu'il y a une profusion de framework, d'API

OK, c'est plus clair, mais ce n'est pas spécialement lié à l'orienté objet : on peut dire exactement la même chose avec les multiples frameworks javascript, PHP (avant qu'il ne fasse de l'objet) ...

Et zut ! J'ai répondu (bon là ce n'est plus un troll, c'est un hors sujet, donc j'arrête)

[polaroid62]

[QUOTE=SylvainPV;8286560]Ce ne sont pas les mêmes environnements de développement mais on passe toujours par le SDK et les API du constructeur. Et je suis bien d'accord qu'une montre n'a rien à voir avec un smartphone et une phablette, c'est pourquoi ça n'a pas de sens de vouloir faire une application native qui cible ces 3 classes d'appareils en même temps.



Avec les xamarin forms il est tout à fait possible de développer une appli native qui sera identique partout sans se soucier de la plateforme finale ,idem pour les jeux où des solutions existent.

[micka132]

Pardon ??? Depuis quand le web n'est plus rétrocompatible ? Les sites faits il y a 20 ans tournent toujours sur ton navigateur que je sache. Il n'y a pas de cassure entre les normes web, la rétrocompatibilité est une contrainte inhérente au web. On ne peut pas se permettre de casser les millions de sites existants.

C'est pour ca que les intégrateurs web s'arrachent les cheveux à chaque test sous un autre navigateur? (Ce qui est certes de moins en moins vrai)
Apres si tu parles de site avec du texte brute comme un affichage sur un bloc note, alors oui il y a rétrocompatibilité, sinon tu dois vivre sur une autre planète.

[SylvainPV]

Avec les xamarin forms il est tout à fait possible de développer une appli native qui sera identique partout sans se soucier de la plateforme finale, idem pour les jeux où des solutions existent.

Oui, Xamarin, Appcelerator Titanium, FireMonkey et bien d'autres... Notre R&D a testé toutes ces solutions et pourtant on continue à faire des développements mono-plateforme. Le problème est là: "qui sera identique partout sans se soucier de la plateforme finale". Nos clients ne veulent pas d'un produit identique, quand on leur vend du natif ils exigent une ergonomie et une interface spécifique à chaque plate-forme. C'est encore plus vrai avec les applis grand public, les utilisateurs savent faire la différence entre des apps hybrides et natives et le font savoir dans les commentaires sur les app stores. En revanche, les jeux sont un cas à part vu que chacun a généralement sa propre UI.

@micka132: je parle des normes uniquement, pas de leur implémentation dans les navigateurs ni de la qualité des développements derrière.

[Paul TOTH]

Oui, Xamarin, Appcelerator Titanium, FireMonkey et bien d'autres... Notre R&D a testé toutes ces solutions et pourtant on continue à faire des développements mono-plateforme. Le problème est là: "qui sera identique partout sans se soucier de la plateforme finale". Nos clients ne veulent pas d'un produit identique, quand on leur vend du natif ils exigent une ergonomie et une interface spécifique à chaque plate-forme. C'est encore plus vrai avec les applis grand public, les utilisateurs savent faire la différence entre des apps hybrides et natives et le font savoir dans les commentaires sur les app stores. En revanche, les jeux sont un cas à part vu que chacun a généralement sa propre UI.

@micka132: je parle des normes uniquement, pas de leur implémentation dans les navigateurs ni de la qualité des développements derrière.

bon je connais surtout FireMonkey, qui présente l'avantage d'avoir un look adapté à la plateforme, c'est à dire que la même application compilée pour Windows aura un look Windows, pour Mac un look Mac, etc...tout cela grâce à un système de styles prédéfinis. Pour iOS il permet aussi en basculant la propriété ControlType de "Styled" à "Platform" de passer d'un composant stylé au composant natif de la plateforme.

mais l'UI n'est pas le plus important à mon avis, car il est souvent bien plus intéressant de concevoir pour Windows un application multi fenêtrée alors que sur mobile on cherchera à travailler sur des slides...par contre tout le code métier et lui strictement le même et il est partagé entre tous les projets sur toutes les plateformes, et sous Delphi c'est du code compilé natif Intel/ARM selon le cas. Ben oui, "natif" sous Android est une notion ambiguë, fait-il parler du processeur (ARM dans la grande majorité des cas) ou de Dalvik ?

Quand à la pérennité, oui le code HTML d'il y a 20 ans a des chances de s'afficher aujourd'hui puisqu'il venait à peine d'ajouter le support des tables, par contre tu peux jeter tous les sites de la période IE6 qui ne s'affichaient déjà pas sur autre chose que IE6 à l'époque de leur conception.

Un site comme developpez.com il y a 15 ans, s'affiche aussi très bien, mais ce n'est pas une WebApplication qui a des besoins un tout petit plus évolués que d'afficher du texte avec mise en forme.

[SylvainPV]

A partir du moment où on suit les standards (et pas des hacks ou API propriétaires comme ça se faisait beaucoup du temps d'IE6), on a l'assurance de la perennité. Il faut arrêter de croire qu'on est pas capables de faire plus que du simple texte mis en forme en web multiplateforme. On est en 2015 quand même ! Ce matin je suis retombé sur un webmail qui n'a pas été mis à jour depuis 2007. Il a mal vieilli, mais il tourne toujours et il n'y a pas de raison qu'il ne tourne plus sur les futurs navigateurs. On ne s'embête même pas à le tester sur les nouveaux navigateurs tellement ça paraît naturel qu'il continue à fonctionner.

[Captain_Walker]

Très bonne idée ... comme ça, en cas de faille dans leur librairie, on pourra lire tout le contenu du téléphone, voire le foutre en l'air, et tout ça avec juste un bout de javascript ...