Heures d'ouverture

9h-12 & 14h-18h du Lundi au Vendredi

Appelez-nous

+33 1 83 64 25 33

Nous sommes à votre disposition





Les Basses Forges, 35530 Noyal-Sur-Vilaine

Pourquoi nous ne développons pas avec React Native ? Partie 2

Vraiment décourageant

En plus de sa licence permissive de style BSD, React Native est livré avec l’autorisation additionnelle de droits de brevets de Facebook, Version 2. Les motivations de Facebook pour inclure ce fichier ne sont pas claires, pas plus que le fichier lui-même.

C’est un document bipolaire. Juste après que le document vous accorde une licence « perpétuelle, mondiale, libre de droits, non exclusive, irrévocable » pour utiliser React Native, nous recevons la clause suivante :

« La licence accordée aux présentes sera résiliée, automatiquement et sans préavis, si vous (ou l’une de vos filiales, sociétés affiliées ou agents) initiez directement ou indirectement, ou avez un intérêt financier direct dans toute demande de brevet: (i) contre Facebook ou toute autre (ii) à l’encontre de toute partie si une telle revendication de brevet découle en totalité ou en partie de tout logiciel, technologie, produit ou service de Facebook ou de ses filiales ou sociétés affiliées, ou (iii) contre toute partie relative au logiciel. »

Selon un expert en droit, cette clause se résume à ceci : si j’engage une action en justice alléguant une contrefaçon de brevet contre Facebook, ma licence d’utilisation de React Native serait immédiatement résiliée.

En pratique, cela semble dissuader de poursuivre Facebook contre des brevets. Par implication, il semble aussi que Facebook laisse une grande marge de manœuvre pour enfreindre les brevets

Un algorithme de recherche linéaire fonctionnera de manière optimale dans des scénarios où la valeur cible est la première de la liste, mais ce seul fait n’est pas suffisant pour nous persuader d’utiliser des algorithmes de recherche linéaire dans un scénario donné. S’il est possible que la valeur cible soit la dernière de la liste, la performance moyenne de mon algorithme de recherche linéaire sera très mauvaise.

De même, le fait que Facebook ne soit pas un serial IP contrefacteur aujourd’hui nous rassure peu, s’il est possible que Facebook devienne un serial IP serial contrefacteur demain et punisse toute représailles de ma part en révoquant ma licence d’utilisation de React Native. Si Facebook devait enfreindre notre IP demain et que nous les poursuivions, nous leur avons donné le droit de débrancher notre application.

Nous mettons donc en péril, à la fois la plateforme dont dépend notre application et notre propriété intellectuelle.

De manière silencieuse

L’interprétation ci-dessus est-elle correcte ? Est-ce que le pire des scénarios, est une possibilité ? Avons nous une bonne raison d’être inquiets ? Avons nous une bonne raison de ne pas s’inquiéter?

Dans divers messages et forums GitHub, les développeurs ont prétendu que leurs services juridiques leur avaient conseillé de ne pas utiliser React ou React Native précisément à cause de cette clause. Les questions restent déplorablement ambiguës pour les développeurs qui n’ont pas de service juridique à leur disposition.

Plus inquiétant, Facebook n’a pas fait d’efforts substantiels pour clarifier les choses. Un article publié en 2015 sur le blog Facebook Open Source reconnaît cette « confusion » et annonce avec clarté des clarifications à son octroi additionnel de droits de brevet. Plus de cinq problèmes liés à GitHub plus tard, le brouillard n’a pas disparu.

Divers développeurs de Facebook ont ​​réagi à ces problèmes, essayant de rassurer les développeurs tout en précisant que tout ce qu’ils écrivaient n’était pas une garantie de quoi que ce soit. L’un d’entre eux a même offert des liens vers des discussions sur Reddit et Hacker News, ce qui n’a servi ni à rien, ni de manière trompeuse.

Cela s’est transformé en un exercice d’herméneutique et de spéculation sur une question d’importance réelle: Facebook peut-il révoquer sa licence React Native ? Si oui, dans quelles conditions ?

Mise à jour d’octobre 2017: Facebook Relicensing

«Après plusieurs semaines de déception et d’incertitude pour notre communauté», Facebook a réactivé React, Jest, Flow et Immutable.js sous la licence du MIT. Malheureusement, la licence et le brevet de React Native n’ont pas changé depuis la publication de cet article.

Nous saluons l’affirmation selon laquelle les gens de Facebook « ne veulent pas freiner les progrès pour des raisons non techniques », mais nous avons du mal à voir quelle raison technique ils ont pour maintenir la situation ci-dessus pour React Native.

Javascript

Un inconvénient crucial à passer à React Native de Swift est la régression technique : vous devez adopter et utiliser JavaScript, un langage qui est

  • techniquement défectueux
  • peu sûr
  • évoluant lentement

Tous les exemples de code JavaScript ci-après seront des codes JavaScript (ES2016) valides

L’inadéquation de Javascript

Un langage de programmation devrait offrir des garanties contre les erreurs de programmation.

Le fait que des millions de conducteurs conduisent des voitures productives sans porter de ceinture de sécurité n’est pas un bon argument pour les voitures sans ceinture de sécurité. De même, le fait que des millions de développeurs JavaScript utilisent de manière productive une langue intrinsèquement dangereuse n’est pas un bon argument pour l’utilisation de langages dangereux.

L’importance de la sécurité dans un langage de programmation est celle que nous apprécions à mesure que les outils pour le développement d’iOS ont évolué.

Lorsque le comptage automatique des références est arrivé à Objective-C, vous aviez la possibilité de le désactiver pour votre projet iOS. Pourquoi était-ce une mauvaise idée d’éteindre l’ARC ? Parce que le compilateur pouvait maintenant effectuer une évaluation de la durée de vie de vos objets plus précise que la vôtre. « Le compilateur est plus intelligent que vous » était le mantra, et c’était certainement le cas au moins en ce qui concerne le comptage des références. Je me souviens à quel point j’étais satisfait de constater que mes crashs d’exécution EXC_BAD_ACCESS ont été décimés en conséquence.

Objective-C vous donne la possibilité de définir le type d’une variable à id, ce qui signifie « n’importe quel type ». Mais c’est une mauvaise pratique de l’utiliser pour une variable dont vous connaissez le type car elle ouvre la porte aux plantages, ce que le compilateur pourrait éviter. Si c’est un problème que le compilateur peut résoudre, vous laissez le compilateur le résoudre – et résoudre des problèmes intéressants à la place.

Vous vous souviendrez que le sélecteur non reconnu a été envoyé aux instances de l’instance. Vous appeliez une méthode sur un objet qui n’y répondait pas. Erreur-type.

Sans surprise, l’une de nos premières réactions après l’utilisation de Swift a été « ceci a été fait par quelqu’un qui en avait assez des accidents d’exécution évitables en Objective-C ».

Swift est en sécurité. Le compilateur ne vous laissera pas passer dans un Int à une fonction qui attend une chaîne. En fait, si le compilateur n’est pas en mesure d’inférer un type, vous devez le définir explicitement.

Mais JavaScript ne dispose pas de ces garanties contre les erreurs de programmeur, ce qui rend les pannes d’exécution évitables et les erreurs programmables évitables dans votre routine.

Erreur de type

Le langage n’applique pas le type de variables et de paramètres aux fonctions :

Toute variable peut être n’importe quoi à n’importe quel moment :

var j = null

var j = function foo() {

return j

}

var j = 23

var j = ‘hello’

console.log(j) //hello

JavaScript vous fait croire qu’il a une certaine notion de types et de classes, avec des mots clés comme class, typeof, and instanceof :

class Person {

//nobody is immortal:

isImmortal() {

return false

}

}

var p = new Person()

console.log(typeof p) //object

console.log(p instanceof Person) //true

console.log(p.isImmortal()) //false

p.isImmortal = function() {return true}

console.log(p.isImmortal()) // true

console.log(p instanceof Person) //true

Ici nous voyons ce qui suit:

  • La notion de « classe », « type » et « instance » de JavaScript est complètement différente de la majorité du monde de la programmation.
  • Les types ne servent à rien en JavaScript, car il est trop facile de définir un type de façon non fiable.

Vous souvenez-vous de ce sélecteur non reconnu envoyé aux instances de l’incident? Voici leur incarnation dans React Native :

 

Manque d’options

Un très grand nombre de bogues dans le code Objective-C (et dans beaucoup d’autres langages de programmation plus anciens) est dû à des programmeurs qui appellent involontairement des méthodes sur des objets qui sont nuls.

Dans le monde de React Native et JavaScript, cette erreur est courante :

Et évitable, à la fois en théorie et en pratique.

Swift a résolu ce problème en implémentant des options, qui vous obligent à prendre les vérifications nuls requises si vous savez qu’un objet peut être nul.

Retrouvez la suite de cet article la semaine prochaine dans les actualités de TACTfactory. 

 

Source : https://arielelkin.github.io/articles/why-im-not-a-react-native-developer.html