Différence entre Xamarin et le script natif de Telerik
Xamarin
- Ecrivez le modèle en C #
- Écrivez les vues pour chaque système d'exploitation à leur manière
- Xamarin promet que la nouvelle fonctionnalité dans les bibliothèques sera ajoutée le même jour
script natif Telerik
- Ecrire en javascript et appeler l'api du script natif qui appelle ensuite les apis javascript OS séparés?
- Ecrire la vue en html5 et css qui est réutilisable pour tous les OS car ils supportent maintenant tous les frontaux html5 et css?
- Telerik déclare simplement ... et je paraphrase "il n'a pas ce problème"
Si tel est le cas, comment Telerik est-il meilleur que Xamarin comme il l'indique sur son site Web:
"Lorsque vous utilisez NativeScript, les nouveaux ajouts à la plate-forme native sont disponibles immédiatement. Ce n'est pas le cas ni dans Xamarin ni dans Appcelerator, où il existe des limitations techniques et des wrappers doivent être créés lorsque de nouvelles fonctionnalités de plate-forme native sont ajoutées."
Je suis confus quant à la façon dont Telerik est écrit comme étant meilleur que Xamarin lorsque Xamarin est livré avec un langage de type fort sans utiliser la chose légèrement lâche de TypeScript. Et aussi que Xamarin se trouve en fait exactement dans le même bateau que Xamarin à part la partie vue ... qui est en fait censé être un avantage?
Question:
- Quelle est la différence entre eux en dehors des deux que j'ai indiqués?
- Pourquoi Telerik revendiquerait-il une telle chose?
[Avertissement: je travaille pour Telerik.]
Telerik NativeScript et Xamarin résolvent des problèmes similaires de différentes manières. Les deux cadres visent à permettre aux développeurs de créer des applications mobiles multiplateformes avec une interface utilisateur native et un code commun partagé sur toutes les plates-formes.
Pour NativeScript, nous nous concentrons fortement sur l'ensemble de compétences des développeurs Web. Nous voulons que quiconque est à l'aise aujourd'hui en écrivant HTML/CSS/JavaScript se sente instantanément à accueil création d'applications natives à l'aide de NativeScript.
La seule chose un peu différente est que les vues sont définies dans un balisage basé sur XML. Ce balisage est analysé par NativeScript et rendu en tant qu'interface utilisateur native sur toutes les plates-formes cibles. (les modules NativeScript encapsulent les rendus spécifiques à la plate-forme.)
La capacité que vous mettez en évidence est également quelque chose d'unique à l'approche de NativeScript pour exposer les API de plateforme native sous-jacentes. NativeScript utilise efficacement la réflexion (au moment de la construction) pour rendre TOUTE API native disponible pour le proxy JavaScript. Cela inclut des bibliothèques natives tierces. Vous ne dépendez pas de Telerik (ou de la communauté open source) pour mettre à jour NativeScript pour profiter de ces nouvelles API. Vous exécutez simplement une commande et découvrez automatiquement les nouvelles API.
Bien sûr, nous ne nous attendons pas à ce que beaucoup de gens écrivent contre les API natives brutes en utilisant JavaScript, c'est donc là que les modules aident à nouveau à encapsuler les différentes API natives et à exposer une seule API JavaScript propre et multiplateforme. Tout le monde peut créer des modules NativeScript.
Un excellent article explique comment tout cela fonctionne de manière beaucoup plus détaillée sur le Telerik Developer Network (TDN): http: // developer.telerik.com/featured/nativescript-works/
J'espère que cela t'aides. La version bêta publique de NativeScript sera disponible cette semaine et la v1 sera disponible en mai.
MISE À JOUR [février 2016] Depuis que cela a été initialement publié, NativeScript a été expédié et est maintenant en v1.6. Il s'intègre également fortement avec Angular 2. Vous pouvez suivre la progression du projet sur GitHub: https://github.com/NativeScript/NativeScript
MISE À JOUR [juin 2016] Il existe désormais des mesures de performances comparant NativeScript et Xamarin. Veuillez les trouver ici: https://github.com/NativeScript/sample-iOS-Profiling/tree/performance-tests