Differenza tra sceneggiatura nativa Xamarin e Telerik di

Question

Xamarin

• Scrivi il modello in C#
• Scrivi i punti di vista per ogni sistema operativo a suo modo nativo
• Xamarin promette che la nuova funzionalità nelle biblioteche è aggiunto lo stesso giorno

Telerik sceneggiatura Native

• Scrivere in javascript e richiamare l'API di script nativo che chiama quindi gli apis javascript del SO separato?
• Scrivi la vista in html5 e css che è riutilizzabile per tutti i sistemi operativi poiché ora supportano i front end html5 e css?
• Telerik afferma semplicemente ... e mi parafrasare 'non ha questo problema'

Se quanto sopra è così, come è Telerik meglio di Xamarin come si legge sul suo sito web:

"Quando si utilizzano NativeScript, le nuove aggiunte alla piattaforma nativa sono immediatamente disponibili, . Questo non è il caso in Xamarin o Appcelerator, dove ci sono limitazioni tecniche e wrapper necessari da creare quando vengono aggiunte nuove funzionalità della piattaforma nativa. "

Sono confuso da come Telerik è stato scritto come migliore di Xamarin quando Xamarin viene fornito con un linguaggio di tipo forte senza usare la cosa un po 'sciolta di TypeScript. E anche che Xamarin si trova in realtà esattamente nella stessa barca in cui Xamarin è parte della vista ... che in realtà dovrebbe essere un vantaggio?

Domanda:
- Qual è la differenza tra loro a parte i due che ho indicato?
- Perché Telerik dovrebbe affermare una cosa del genere?

Answer 1

[Disclaimer:. Io lavoro per Telerik]

Telerik NativeScript e Xamarin stanno risolvendo problemi simili in modi diversi. Entrambi i framework sono focalizzati sul consentire agli sviluppatori di creare applicazioni mobili multipiattaforma con interfaccia utente nativa e codice comune condiviso su tutte le piattaforme.

Per NativeScript, ci siamo concentrati molto sul set di competenze dello sviluppatore web. Vogliamo chiunque sia a proprio agio oggi a scrivere HTML/CSS/JavaScript per sentirsi subito a casa a creare app native usando NativeScript.

L'unica cosa leggermente diversa è che le viste sono definite in un markup basato su XML. Questo markup è analizzato da NativeScript e reso come UI nativa su tutte le piattaforme di destinazione. (i moduli NativeScript incapsulano i rendering specifici della piattaforma)

La capacità che si evidenzia è anche qualcosa di esclusivo dell'approccio di NativeScript per l'esposizione delle API della piattaforma nativa sottostante.NativeScript utilizza effettivamente la reflection (build-time) per rendere disponibile QUALSIASI API nativa al proxy JavaScript. Include le librerie native di terze parti. Non si dipende da Telerik (o dalla comunità open source) per aggiornare NativeScript per sfruttare queste nuove API. Basta eseguire un comando e scoprire automaticamente le nuove API.

Ovviamente non ci aspettiamo che molte persone scrivano contro le API native native utilizzando JavaScript, quindi è qui che i moduli aiutano di nuovo a incapsulare le diverse API native ed esporre una singola, pulita, API JavaScript multipiattaforma. Chiunque può creare moduli NativeScript.

C'è un grande post che spiega come tutto questo funziona in modo molto più dettagliato sulla Telerik Developer Network (TDN): http://developer.telerik.com/featured/nativescript-works/

Spero che questo aiuti. La beta pubblica di NativeScript sarà disponibile questa settimana e la versione 1 sarà disponibile a maggio.

---

UPDATE [Feb 2016] Dal momento che questo è stato originariamente pubblicato, NativeScript ha venduto ed è ora in v1.6. E 'anche ora integrando pesantemente con angolare 2. È possibile seguire l'avanzamento del progetto su GitHub: https://github.com/NativeScript/NativeScript

---

UPDATE [giugno 2016] Ora ci sono le metriche di performance confronto NativeScript e Xamarin. Li trovate qui: https://github.com/NativeScript/sample-iOS-Profiling/tree/performance-tests