NativeScript, Angular, React, View... quel choix faire ?

Bonjour

Je dois intégrer divers développement déjà fait depuis peu de temps (3 mois de dev) en React. Et je vois le temps passer et trainer chez mes dev (3 jeunes deb+)... et doute de React, qui n'est pas un framework. C'est pour faire une sorte de www.tribeez.com (regardez svp, sympa): un petit portail multi-services (chat, photo, albums, notes, todo, agenda,
docs, ...) pour ma femme et moi d'un côté, ma famille de l'autre, voire un petit réseau social multi-groupes, microblogging, iSO Android et Web responsive. Rien de très 3D ou game ou complexe, plus "productivité" personnelle et de groupe...

React semble nécessiter 3-5 jours pour porter le code iOS sur Android, plus encore pour faire une version Web. NativeScript semble être bien plus multi-cibles facile.

React n'impose pas à mes dev un cadre clair propre commun à toutes les apps voire à un portail avec une UI et une structure de données assez bien intégrée entre les services (modules, fonctions, appelez les comme vous voulez: notes todo agenda etc.) et peut-être a moins de fonctions faciles à trouver (trop de choix tue le choix...) d'intégration avec Android iOS et autres web services (iCloud, Google contacts, sync agenda, docs...): Angular 2 (ou 4 maintenant) semble logiquement être un meilleur choix mais quelles sont les "cons" versus React?

Quel est l'apport de NativeScript dans tout ça, avec ou sans Angular, vs React et Angular???

Bref, tout est à tiroir, à ne plus rien comprendre... Une chouette matrice d'aide à la décision serait utile, un jour, dans ce capharnaüm JS et terminaux...

Grand merci à celui qui éclairera mes lanternes!

Bienvenue dans le javascript de 2017, où la pagaille est complète, on court tous derrière le dernier joujou à la mode sans se soucier si c'est vraiment le plus approprié ou pas, où les versions ne sont jamais stables et la pérennité des libs jamais garantie, où on doit jongler entre vieux javascript, es5, es6, es6+, typescript, bientôt webassembly et asm.js. Et je ne parle même pas des outils comme Babel, Webpack, browserify, systemjs (et npm, grunt, gulp, bower). Sans compter que le tout doit être isomorphique, évidemment.

Désolé de l'intro peu constructive, mais c'est juste qu'on est beaucoup à être dans l'expectative en ce moment face à tout cela. Javascript est dans une phase d'immaturité totale où tout peut disparaitre du jour au lendemain.

Maintenant, React vs Angular c'est essentiellement une question de goût, mais:

- Angular oblige tes devs à apprendre Typescript (ce qui n'est pas compliqué s'ils ont déjà fait autre chose que du javascript). Sur react, Flow te permet d'avoir un typage tout en gardant javascript.

- React native est la solution naturelle si on utilises React en front-end

- React te donne plus de liberté dans le choix des composants (ce n'est pas un framework), mais pour exercer cette liberté il faut déjà savoir choisir les bons composants.

- Je vois personnellement plus de documentations/articles/tutoriels sur React que sur Angular, mais c'est peut-être un biais des sites que je fréquente.

- Il y a définitivement plus de documentations/articles/tutoriels sur React Native que sur NativeScript

- J'évite Angular vu la propension de Google à jeter ses technos sans avertir.

- Mais la réalité est que dans 80% des cas, on peut faire la même chose avec autant d'efficacité avec React, Vue.js, Ember ou Angular, à condition d'avoir les connaissances.

Merci pour la réponse!

En lisant d'autres blogs (anglais en général) je résume à ça:

- React et son écosystème (Redux Flow Fiber etc.) permet de tout faire mais il faut savoir choisir ses morceaux pour donc construire ce qu'on veut, personnalisé. Avec une énorme communauté à la pointe, on a souvent voire toujours le "best of" puisque chaque élément peut être challengé par un autre pour le même usage, et le tout enrichi d'un autre "truc" pour l'améliorer. Idéal pour les super techs qui veulent toujours le best of, personnaliser leur expérience, se sentir "chez soi", etc.

- Angular au contraire est pensé pour les grandes organisations, avec un ensemble, un cadre, framework, complet et cohérent, propre, ciblé sur la facilité de prise en main immédiate et l'organisation du développement en grandes équipes: chaque composant est unique, bien articulé avec les autres, chaque documentation est complète et cohérente avec les autres, et Google a choisi TypeScript mais aussi Dart pour que les équipes des grandes entreprises, plutôt C++, Java, C#, y retrouvent leurs petites habitudes et la puissance qui fait -encore- défaut à JS (typage, etc.). Ainsi que la pléïade d'outils MS, excellents. Mais sans "challengers" internes, les divers morceaux de Angular n'ont pas a priori d'aiguillon pour évoluer aussi vite que dans le monde React ou chacun peut vouloir améliorer un morceau.

On peut faire un amusant parallèle: React et Angular, c'est le bazar et la cathédrale, Ruby on Rails (et ses gems) versus Python et son "there's only one way to do that", c''est l'Europe et ses nations belliqueuse contre la Chine impériale, c'est le PC et ses compatibles versus le Mac monolithique...

L'Histoire montre ce qu'il en advint... Néanmoins, je crois qu'il y a une place pour tous, nous n'avons pas le même besoin.

et "seul, on va plus vite" (avec React), "ensemble, on va plus loin" (avec Angular).

Nous étions à un codeur il y a 6 mois, puis 2 en mai, puis 3 en juin, bientôt 4 la semaine prochaine...

Nous faisons un portail de famille avec un appstore (ou plug-in ou modules, appelez les comme vous voulez) pour que toute personne externe puisse coder des nouvelles fonctions (que pour elle ou dispo pour tous): pour des raisons de sécurité, nous avons abandonné Python /Django car un module externe ne doit pas toucher le coeur et donc JS était une solution (ça ne tourne que chez l'utilisateur). Mais je cherche toujours le framework ou architecture la plus adéquate à construire un tel portail, façon ERP social, modulaire, mais apte à attirer les devs...

Toute idée et conseils bienvenue! (RoR, View, Ember, ... voire même Drupal?)


www.Tribeez.com

Plutôt que d'embaucher des devs tu ferais mieux de prendre un architecte. Ça sent le mur ton histoire ...