Is there a difference between using Svelte with Nativescript and "Svelte native" ?
If yes, what is the most significant difference in practice ?
Svelte Native is a new approach to building mobile applications using NativeScript. Where other JavaScript mobile development frameworks like React Native and NativeScript-Vue do the bulk of their work on the mobile device, Svelte Native shifts that work into a compile step that happens when you build your app.
Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the native view widgets when the state of your app changes.
this is from svelte-native official web-site
so Svelte native is the name of the framework and that framework uses Nativescript.
Related
With which subcategory between Angular, Vue, Plain TypeScript, PlainJavaScript, React or Svelte can I develop simultaneously for both operating systems on Windows? Or would you prefer VM?
Asked NS Support
We need to build a commercial mobile app that is supported on iOS, Android and UWP platforms. We have been looking at react native and xamarin forms to do so. What is more recommended/preferable technology to implement this?
Reasons why we wanted to use react native in first place:
1) more experience in JavaScript
2) Some of the UI designs in our mobile app includes having cross platform features which by default could be native to either IOS or android. Such as having icon badges on tab items, having toggle search box in navigation bar. On react native we found these were more easily achievable by git hub plugins but in xamarin forms you need to write custom renderers to achieve so.
Reasons why started investigating on xamarin forms: Since the app needs to run windows phones too, we stared using react native XP plugin to support that. But end prototype on windows phone wasn't very impressive in terms of performance and user experience of some of react native plugins we have used. Plus we also had to do quite a bit UI customisation in terms of specifying width/heights to make components work.
I have been develop on Xamarin a few years now. My honest opinion is that there is a lot of third party libraries and components that only has support for Android and iOS only. Maybe you you check out what third party libraries you need and work back from there.
If Windows Phones are an honest target for you going forward, unless you can limit to those capable of UWP apps (Win 10 Mobile) then scratch Xamarin from the list. Windows Phone 8 and 8.1 support is deprecated and will be dropped soon from Forms.
I have to develop an app for iOS and Android and it has to be able to run embedded in existing apps. I would usually do this with Cordova since it takes care of the multiple platforms and it is easy to embed in an existing app by creating a Cordova WebView.
Since this app is making heavy use of animations I have been playing around with NativeScript in order to avoid the bad performance of this kind of UI running on a WebView.
The problem is that it seems that embedding a NativeScript app in a native app is not straightforward at all. I have found this https://groups.google.com/forum/m/#!msg/nativescript/4kDFcX6gtxA/vdjruLLVBQAJ Is this still true? Any suggestions or ideas on how to accomplish this?
You can check this sample for iOS:
https://github.com/NativeScript/sample-ios-embedded
We will provide soon similar for Android
[UPDATE] Here is how to use {N} in existing Android app:
https://github.com/NativeScript/sample-android-runtime-embedded-POC
Xamarin
Write the model in C#
Write the views for each OS in their own native way
Xamarin promises that the new functionality in libraries is added the same day
Telerik Native script
Write in javascript and call native script's api that then calls the separate OS javascript apis?
Write the view in html5 and css which is re-usable for all OSs as they now all support html5 and css front ends?
Telerik simply states... and I paraphrase 'it does not have this problem'
If the above is so, how is Telerik any better than Xamarin as it states on its website:
"When using NativeScript the new additions to the native platform are
available immediately. This is not the case in neither Xamarin or
Appcelerator, where there are technical limitations and wrappers needs
to be created when new native platform features are added."
I am confused at how Telerik is being penned as being better than Xamarin when Xamarin comes with strong type language without using TypeScript's slightly loose thing going on. And also that Xamarin does in fact sit in exactly the same boat as Xamarin apart form the view part... which is actually supposed to be a benefit?
Question:
- What's the difference between them apart from the two I have denoted?
- Why would Telerik claim such a thing?
[Disclaimer: I work for Telerik.]
Telerik NativeScript and Xamarin are solving similar problems in different ways. Both frameworks are focused on enabling developers to create cross-platform mobile applications with native UI and shared, common code across all platforms.
For NativeScript, we're focused heavily on the web developer skill set. We want anyone that is comfortable today writing HTML/CSS/JavaScript to feel instantly at home creating native apps using NativeScript.
The only thing that is a little different is that views are defined in an XML-based markup. This markup is parsed by NativeScript and rendered as native UI on all target platforms. (NativeScript modules encapsulate the platform-specific renderings.)
The capability you highlight is also something unique to NativeScript's approach for exposing underlying native platform APIs. NativeScript effectively uses (build-time) reflection to make ANY native API available to the JavaScript proxy. That includes 3rd party native libraries. You do not depend on Telerik (or the open source community) to update NativeScript to take advantage of these new APIs. You simply execute a command and auto-discover the new APIs.
Of course, we don't expect a lot of people to write against the raw native APIs using JavaScript, so that's where modules again help encapsulate the different native APIs and expose a single, clean, cross-platform JavaScript API. Anyone can create NativeScript modules.
There's a great post that explains how all of this works in much more detail on the Telerik Developer Network (TDN):
http://developer.telerik.com/featured/nativescript-works/
NativeScript's public beta will be available this week, and v1 will ship in May.
UPDATE [Feb 2016]
Since this was originally posted, NativeScript has shipped and is now in v1.6. It is also now integrating heavily with Angular 2. You can track the project progress on GitHub: https://github.com/NativeScript/NativeScript
UPDATE [June 2016]
There are now performance metrics comparing NativeScript and Xamarin. Please find them here:
https://github.com/NativeScript/sample-iOS-Profiling/tree/performance-tests
Telerik is a UI component and it has some beautiful control for designing in xamarin forms,MVC. Net and etc, but xamarin forms is a technology that helps deveopers to make mobile application using c#
I have just started using Titanium and was wondering if the apps I develop would be sent to Titanium server for compiling? Can anybody clarify? Thanks in advance.
You don't need to compile the apps on any of the Titanium servers. You can compile the apps from within Titanium Studio. When testing the app on the device, Titanium Studio automatically generates the ipa file and apk file for respective platforms
Edit:
Using Titanium, developers can create an application writing Javascript and calling Titanium's APIs. The Javascript is then interpreted at runtime. The application's UI then becomes completely native. There is no web UI in your app since the native Titanium APIs take over control of all UI needs. Titanium runs application's JavaScript using one of two JavaScript interpreters' JavaScriptCore on iOS (the interpreter used by Webkit) and Mozilla Rhino on Android.
The Javascript calls to the Titanium API are mapped to native code in the Titanium framework and generate native components. Events in those components are sent back to the code in Javascript where we can handle them