This question is locked. New answers and comments are not allowed.
Hi all, for those of you who didn't manage to attend the webinar last week we uploaded the recording of the webinar here:
https://www.youtube.com/watch?v=Glh927vSYKo
There were many questions during the webinar. I answered to many of them during the webinar, but here is the full list of all questions and their answers:
Q: Is it wise to develop a complex app in the Telerik Platform with NativeScript at this moment.
A: No, now is not a time to start writing a complex application with NativeScript. We are still in the very early stages of development of the framework. I recommend that you wait at least until the public beta version is released in February. Now is a very good time to start learning and experimenting with the framework and also provide feedback to the development team.
Q: When do you believe NativeScript will be stable enough to build apps to be published onto the app store/play store?
A: According to our plans this should happen in May.2015 when we will release our v1. You can of course start developing the app earlier and update the framework code when we have an update.
Q: Is it possible to pull in a .NET PCL into a NativeScript project?
A: Not out of the box. You need to convert it first to JavaScript library. Try http://jsil.org/. This will be useful for you if you have existing .NET code that you want to reuse. Otherwise you can use one the most popular JavaScript libraries on the planet like: Underscore.js and many more :)
Q: As compared to Appcelerator, is the primary advantage using pure JS/CSS/TypeScript .. nothing proprietary? What about in terms of performance?
A: You are correct that unlike Appcelerator Titanium, NativeScript uses standards based JavaScript and standard CSS to create truly native apps. Тhe entire source code of NativeScript will be open sourced in February, 2015. We do have very tight integration with TypeScript and this is very important.
There are lots of things to bear in mind when comparing two frameworks. I would separate them in two - 1st - ease of development and support and 2nd - end result and performance of the applications.
So if we see the first topic - the ease of development and support. It should be pointed out that the NativeScript way of developing native apps is much more flexible. The entire application stack that is available to the developers is much more modern, more extensible and most importantly it is a breeze to get access to the native APIs and to include any 3rd party native library. We are not making any optimizations to JavaScript and our solution is more simple and stable. You don’t need to learn another layer on top of JavaScript. And if you step back and look at the entire picture you will see that Telerik Platform is much better and offers much more functionalities compared to the Appcelerator platform.
In terms of support - ask anyone who is using any of the Telerik products and I’m sure you will receive the answer that this is one of the most strong benefits when using Telerik.
Now to the second topic. In terms of performance of the apps at the current state of our framework we do not see any significant difference when comparing to native code. There are some scenarios where we can improve on Android and we are working in this direction. We are performing internal tests against native platforms, Xamarin and Appcelerator and I can say that the results are promising. This all performance requires a new blog post, so I will make sure to write one when we are near the public launch and will show the tests we are executing.
Q: Would it be possible to use native XIB/Storyboards or Android XML and hook them up in NativeScript JS code?
A: Not at the moment. But we are thinking about it. It will be useful if you share specific scenarios where could be helpful. Please write in the forum for those.
Q: Do you plan to support desktop OS, like OS X or Windows?
A: Not at the moment. Implementing another NativeScript runtime is not an easy task but once we are open source we are welcoming implementations for other platforms inspired by our for iOS and Android. Our current architecture allows easy introduction of a new runtime.
Q: Currently the generated APKs/IPAs by NativeScript are quite big. Do you plan to make it smaller?
A: Current size of the IPA files is ~2Mb, and for Android is 8MB (for one platform). For iOS we do not plan further optimizations. For Android soon we will introduce a new mechanism for native API mappings and the Android APK size will become smaller. You should expect that the size will become smaller (~4Mb for one platform).
Q: For when is the UI-builder planned?
A: UI builder is planned for May.2015 as part of Telerik Platform.
Q: Does the JS VM use Google V8? Can you say a little more about the JS engine powering NativeScript apps?
A: Yes, we use Google V8 engine for our Android implementation. For iOS we use JavaScript Core. We use the V8 and JSC engines as they are, with no modifications. This allow us to update the engines as needed and to keep up with everything that is part of them.
Q: Using SL/WPF syntax and data binding was best approach.
A: We are glad you like it. We think this is the best approach for describing and building UI at the moment.
Q: When do you expect to launch NativeScript publically to your Telerik Platform users?
A: The beta version of NativeScript will be launched publicly in February, 2015. V1 will be launched in May, 2015.
Q: I may have missed it, but does NativeScript integrate with Cordova? Or is it an alternative?
A: NativeScript does not integrate with Cordova. Cordova aims to help developers build hybrid mobile apps using their web skills where NativeScript is built to help developers build truly native apps with native performance and native user experience using JavaScript and CSS. So they are separate frameworks and NativeScript is the new alternative way to build cross-platform mobile apps.
Q: How do you debug NativeScript apps?
A: Our debugging story is not very good at the moment. But in the future you will be able to debug NativeScript for Android with any V8 debugger (e.g. node-inspector). For NativeScript for iOS you will use webkit debugging tools.
Q: Is there a reason you opted to use XML instead of HTML for the UI? It raises the learning curve for web devs, especially if they've never used XAML.
A: The goal of NativeScript is to enable developers to build truly native apps. Using HTML would mean that the apps would have to be hybrid apps thus lacking the native performance and user experience. If you are looking to use HTML, CSS and JavaScript to build mobile apps, check out Telerik Appbuilder.
Q: Does NativeScript have CLI tools? This is vital for integration with grunt/gulp, Jenkins and other build systems, IDEs, etc
A: Yes. We have (and love) CLI tools. Please see http://npmjs.org/nativescript
Q: Can Jasmine and Karma be used with NativeScript?
A: Yes. They are JavaScript based and do not have browser dependencies and should work out of the box.
Q: Is there a way to mock the lower-level APIs when testing (if it's possible at all)?
A: Yes. It is all JavaScript code. What is the scenario here?
Q: Does the NativeScript Bridge support other languages, or just JavaScript? Is there any reason it can't support any language?
A: No, we support only JavaScript and JavaScript-based languages like TypeScript, CofeeScript, etc.
Q: Hi Valio, will Swift be supported in future?
A: We do not have plans for this at the moment.
Q: Will NativeScript apps for iOS still require compilation on a Mac?
A: No, if you are using the tools found in Telerik Platform. They are doing the compilation in the cloud and you can use the app package directly with your device. More info is available here.
Q: So basically, I write an app in Level 2, then I can make an if-statement and make a level 1 native api call if I detect an android phone?
A: Yes - exactly. You can check on which OS the code is running and do platform-specific implementation.
If you have any other questions, please let me know - I will be happy to help!
Best,
Valio
https://www.youtube.com/watch?v=Glh927vSYKo
There were many questions during the webinar. I answered to many of them during the webinar, but here is the full list of all questions and their answers:
Q: Is it wise to develop a complex app in the Telerik Platform with NativeScript at this moment.
A: No, now is not a time to start writing a complex application with NativeScript. We are still in the very early stages of development of the framework. I recommend that you wait at least until the public beta version is released in February. Now is a very good time to start learning and experimenting with the framework and also provide feedback to the development team.
Q: When do you believe NativeScript will be stable enough to build apps to be published onto the app store/play store?
A: According to our plans this should happen in May.2015 when we will release our v1. You can of course start developing the app earlier and update the framework code when we have an update.
Q: Is it possible to pull in a .NET PCL into a NativeScript project?
A: Not out of the box. You need to convert it first to JavaScript library. Try http://jsil.org/. This will be useful for you if you have existing .NET code that you want to reuse. Otherwise you can use one the most popular JavaScript libraries on the planet like: Underscore.js and many more :)
Q: As compared to Appcelerator, is the primary advantage using pure JS/CSS/TypeScript .. nothing proprietary? What about in terms of performance?
A: You are correct that unlike Appcelerator Titanium, NativeScript uses standards based JavaScript and standard CSS to create truly native apps. Тhe entire source code of NativeScript will be open sourced in February, 2015. We do have very tight integration with TypeScript and this is very important.
There are lots of things to bear in mind when comparing two frameworks. I would separate them in two - 1st - ease of development and support and 2nd - end result and performance of the applications.
So if we see the first topic - the ease of development and support. It should be pointed out that the NativeScript way of developing native apps is much more flexible. The entire application stack that is available to the developers is much more modern, more extensible and most importantly it is a breeze to get access to the native APIs and to include any 3rd party native library. We are not making any optimizations to JavaScript and our solution is more simple and stable. You don’t need to learn another layer on top of JavaScript. And if you step back and look at the entire picture you will see that Telerik Platform is much better and offers much more functionalities compared to the Appcelerator platform.
In terms of support - ask anyone who is using any of the Telerik products and I’m sure you will receive the answer that this is one of the most strong benefits when using Telerik.
Now to the second topic. In terms of performance of the apps at the current state of our framework we do not see any significant difference when comparing to native code. There are some scenarios where we can improve on Android and we are working in this direction. We are performing internal tests against native platforms, Xamarin and Appcelerator and I can say that the results are promising. This all performance requires a new blog post, so I will make sure to write one when we are near the public launch and will show the tests we are executing.
Q: Would it be possible to use native XIB/Storyboards or Android XML and hook them up in NativeScript JS code?
A: Not at the moment. But we are thinking about it. It will be useful if you share specific scenarios where could be helpful. Please write in the forum for those.
Q: Do you plan to support desktop OS, like OS X or Windows?
A: Not at the moment. Implementing another NativeScript runtime is not an easy task but once we are open source we are welcoming implementations for other platforms inspired by our for iOS and Android. Our current architecture allows easy introduction of a new runtime.
Q: Currently the generated APKs/IPAs by NativeScript are quite big. Do you plan to make it smaller?
A: Current size of the IPA files is ~2Mb, and for Android is 8MB (for one platform). For iOS we do not plan further optimizations. For Android soon we will introduce a new mechanism for native API mappings and the Android APK size will become smaller. You should expect that the size will become smaller (~4Mb for one platform).
Q: For when is the UI-builder planned?
A: UI builder is planned for May.2015 as part of Telerik Platform.
Q: Does the JS VM use Google V8? Can you say a little more about the JS engine powering NativeScript apps?
A: Yes, we use Google V8 engine for our Android implementation. For iOS we use JavaScript Core. We use the V8 and JSC engines as they are, with no modifications. This allow us to update the engines as needed and to keep up with everything that is part of them.
Q: Using SL/WPF syntax and data binding was best approach.
A: We are glad you like it. We think this is the best approach for describing and building UI at the moment.
Q: When do you expect to launch NativeScript publically to your Telerik Platform users?
A: The beta version of NativeScript will be launched publicly in February, 2015. V1 will be launched in May, 2015.
Q: I may have missed it, but does NativeScript integrate with Cordova? Or is it an alternative?
A: NativeScript does not integrate with Cordova. Cordova aims to help developers build hybrid mobile apps using their web skills where NativeScript is built to help developers build truly native apps with native performance and native user experience using JavaScript and CSS. So they are separate frameworks and NativeScript is the new alternative way to build cross-platform mobile apps.
Q: How do you debug NativeScript apps?
A: Our debugging story is not very good at the moment. But in the future you will be able to debug NativeScript for Android with any V8 debugger (e.g. node-inspector). For NativeScript for iOS you will use webkit debugging tools.
Q: Is there a reason you opted to use XML instead of HTML for the UI? It raises the learning curve for web devs, especially if they've never used XAML.
A: The goal of NativeScript is to enable developers to build truly native apps. Using HTML would mean that the apps would have to be hybrid apps thus lacking the native performance and user experience. If you are looking to use HTML, CSS and JavaScript to build mobile apps, check out Telerik Appbuilder.
Q: Does NativeScript have CLI tools? This is vital for integration with grunt/gulp, Jenkins and other build systems, IDEs, etc
A: Yes. We have (and love) CLI tools. Please see http://npmjs.org/nativescript
Q: Can Jasmine and Karma be used with NativeScript?
A: Yes. They are JavaScript based and do not have browser dependencies and should work out of the box.
Q: Is there a way to mock the lower-level APIs when testing (if it's possible at all)?
A: Yes. It is all JavaScript code. What is the scenario here?
Q: Does the NativeScript Bridge support other languages, or just JavaScript? Is there any reason it can't support any language?
A: No, we support only JavaScript and JavaScript-based languages like TypeScript, CofeeScript, etc.
Q: Hi Valio, will Swift be supported in future?
A: We do not have plans for this at the moment.
Q: Will NativeScript apps for iOS still require compilation on a Mac?
A: No, if you are using the tools found in Telerik Platform. They are doing the compilation in the cloud and you can use the app package directly with your device. More info is available here.
Q: So basically, I write an app in Level 2, then I can make an if-statement and make a level 1 native api call if I detect an android phone?
A: Yes - exactly. You can check on which OS the code is running and do platform-specific implementation.
If you have any other questions, please let me know - I will be happy to help!
Best,
Valio
7 Answers, 1 is accepted
0
Ben Hayat
Top achievements
Rank 2
Rank 2
answered on 11 Dec 2014, 01:05 PM
Valio, I like the way you answered the questions (Yes/No) like a developer and not like a PM or salesperson. :-)
Straight to the point and clear!!! Keep it like this forever! :-)
Straight to the point and clear!!! Keep it like this forever! :-)
0
Hello Ben,
The "Technical" prefix of my PM title speaks for itself :).
Regards,
Valentin.Stoychev
Telerik
The "Technical" prefix of my PM title speaks for itself :).
Regards,
Valentin.Stoychev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Arthur
Top achievements
Rank 1
Rank 1
answered on 16 Dec 2014, 12:57 AM
It would be great if UI Builder will be web based. I mean it is no problem to have Web/Browser as an target, therefore it will allow easy making of UI Builder with live preview. Possibly developers could make their own builders since all planned to be open source :)
Thanks.
Thanks.
0
Valio
Top achievements
Rank 1
Rank 1
answered on 16 Dec 2014, 12:58 PM
Hi Andre, yes - everyone is welcome to build tools on top of the open source framework. We encourage this ofcourse and we will help with whatever we can.
the UI Builder is planned as part of the Telerik Platform offering and yes its UI will be web-based. But please note that this is not a pixel-perfect UI designer, but a functional designer with some predefined templates which you can use.
The idea of having a web-based preview of the app is very good, but it will require lots of efforts to translate our XML UI language to something that the browser can render. Do you have ideas how this can me simplified?:)
--Valio
the UI Builder is planned as part of the Telerik Platform offering and yes its UI will be web-based. But please note that this is not a pixel-perfect UI designer, but a functional designer with some predefined templates which you can use.
The idea of having a web-based preview of the app is very good, but it will require lots of efforts to translate our XML UI language to something that the browser can render. Do you have ideas how this can me simplified?:)
--Valio
0
Arthur
Top achievements
Rank 1
Rank 1
answered on 16 Dec 2014, 02:04 PM
Hi!
[quote]Valentin.Stoychev said:Hi Andre[/quote]
Not sure it's my name :)
[quote]Valentin.Stoychev said:
The idea of having a web-based preview of the app is very good, but it will require lots of efforts to translate our XML UI language to something that the browser can render. Do you have ideas how this can me simplified?:)[/quote]
Probably. I meant what web at some time might be target platform for tns like ios/android. It will simplified the things. Of course there should be runtime for all of it in browser, but I think it's not huge task in comparison with ios/android platform building (I do not mean it's not huge and you must do it anyway, just say that it looks relatively easy to me).
Thank you!
[quote]Valentin.Stoychev said:Hi Andre[/quote]
Not sure it's my name :)
[quote]Valentin.Stoychev said:
The idea of having a web-based preview of the app is very good, but it will require lots of efforts to translate our XML UI language to something that the browser can render. Do you have ideas how this can me simplified?:)[/quote]
Probably. I meant what web at some time might be target platform for tns like ios/android. It will simplified the things. Of course there should be runtime for all of it in browser, but I think it's not huge task in comparison with ios/android platform building (I do not mean it's not huge and you must do it anyway, just say that it looks relatively easy to me).
Thank you!
0
Valio
Top achievements
Rank 1
Rank 1
answered on 16 Dec 2014, 02:17 PM
Hi Arthur,
I understand now. Thanks for the clarification. Web target is not in the short term plan, but the good thing is that it is relatively easy to create another runtime and plug into our architecture. So maybe the community can help in this area!
PS: sorry about the wrong name in the prev. reply (not sure what I was thinking :))
--Valio
I understand now. Thanks for the clarification. Web target is not in the short term plan, but the good thing is that it is relatively easy to create another runtime and plug into our architecture. So maybe the community can help in this area!
PS: sorry about the wrong name in the prev. reply (not sure what I was thinking :))
--Valio
0
Arthur
Top achievements
Rank 1
Rank 1
answered on 16 Dec 2014, 02:32 PM
Hi, Valentin!
[quote]Valentin.Stoychev said:
I understand now. Thanks for the clarification. Web target is not in the short term plan, but the good thing is that it is relatively easy to create another runtime and plug into our architecture. So maybe the community can help in this area!
[/quote]
That would be good! I think all are passionate in that NativeScript will Open Source.
[quote]Valentin.Stoychev said:
PS: sorry about the wrong name in the prev. reply (not sure what I was thinking :))
[/quote]
It's ok :)
[quote]Valentin.Stoychev said:
I understand now. Thanks for the clarification. Web target is not in the short term plan, but the good thing is that it is relatively easy to create another runtime and plug into our architecture. So maybe the community can help in this area!
[/quote]
That would be good! I think all are passionate in that NativeScript will Open Source.
[quote]Valentin.Stoychev said:
PS: sorry about the wrong name in the prev. reply (not sure what I was thinking :))
[/quote]
It's ok :)