7 ms·

NativeScript – Cross-platform framework for building native mobile applications

77 points by orand 12y ago

yuchi 12y ago
This is mostly the same as https://github.com/appcelerator/hyperloop https://github.com/appcelerator/hyperloop I’m very, very curious to try it.
- marcoms 12y ago
  I would also be willing to try it, provided I didn't have to register with any services to do so
- T-A 12y ago
  I haven't looked closely at Hyperloop, but I thought it was meant to be a JavaScript-to-native compiler. NativeScript looks more like plain old Titanium: run JavaScript in V8, with an interface to native UI (and other) APIs.
  - yuchi 12y ago
    The point is where the Titanium-esque part is built: kernel-land (native) or user-land (JS)? In Hyperloop/NativeScript (as far as I can understand NativeScript) it is done completely in JS-land, so there’s no difference between Titanium code and app-code. In plain old Titanium (Ti.Current) the bridge is in kernel-space.
Pacabel 12y ago
Are there any screenshots showing side-by-side comparisons between the same app implemented using this technology running on the different platforms it supports? I looked quickly through the article and the NativeScript web site, but couldn't find any. All I saw was rather useless marketing imagery.
- blagoev 12y ago
  You can check the companion apps on Google Play and Apple iTunes. Search for "NativeScript".
  - leorocky 12y ago
    I've seen iOS UIs in Android apps before, but I've never seen an Android menu in an iOS app before: https://itunes.apple.com/us/app/nativescript/id882561588?mt=8 https://itunes.apple.com/us/app/nativescript/id882561588?mt=... https://play.google.com/store/apps/details?id=com.telerik.NativeScript https://play.google.com/store/apps/details?id=com.telerik.Na...
jtheory 12y ago
These kinds of frameworks will be quite useful, when mature. Though -- they're of course tackling a problem that gets harder the deeper you get into it, and has already been tried a few times, never with really great success. Java's AWT made a "lowest common denominator" kind of cross-platform UI back in the last 90s, and was fairly universally disliked (so Sun made Swing after that, which switched from "native components" to "over-engineered fake native components"). I hope the people building cross-platform UI for mobile devices now have studied the lessons to be learned from previous attempts -- mainly, I suspect, that getting something that kind-of works is exciting and fairly easy, but getting the detail right is grueling, thankless work, and ultimately impossible. It might be wise for them to start with the hardest, least-cross-platform-appropriate bits, and see in advance what compromises those will force.
- blagoev 12y ago
  The application UI is the native one. It's just that you use NativeScript to create it. It's not like an 'ugly' cross platform common denominator.
  - slavoingilizov 12y ago
    I think you're misunderstanding jtheory. It's not about whether it's native or not - it's about using each platform's idioms and peculiarities which don't exist in other platforms. There isn't a 1-to-1 mapping between iOS UI elements and Android UI Elements. What do you do then? The Android Spinner is an example: http://developer.android.com/design/building-blocks/spinners.html http://developer.android.com/design/building-blocks/spinners... There is no alternative in iOS, but if you don't use it in your Android app you are missing out, because people on that platform expect it and know it. What about Back buttons in iOS? You don't need them in Android. If you are developing a cross-platform UI without using these elements, you are probably compromising the UX of your app. I am very interested in how those problems are solved. Will try and play around with it.
    - blagoev 12y ago
      The application you are building will use each platform's idioms. So the UI layer code will be platform specific and can not be reused. All other business logic code will be reused thought.
crncosta 12y ago
Opensource? no?! well, thank you but I already have a lot of problems with platform/vendor lock-in in the mobile world. But if you guys decided to change your mind and open the source, I will be glad to try :-)
- blagoev 12y ago
  It will be open sourced. Apache License Version 2.
- alanning 12y ago
  There are many areas in the article where they describe their plan to open source this. It's in their roadmap for v0.4 projected to be released in Oct. 2014. Also, "...This is the reason why we decided that once the core framework is implemented we will release the framework code under the Apache License Version 2. We already have an organization on http://github.com/NativeScript http://github.com/NativeScript where the project will be hosted and will be pushing the code shortly - now just go ahead and star us." ... from the section titled, "Open Source - not yet another proprietary framework".
  - mkesper 12y ago
    I just wonder why they don't do it right from the start?
    - teh_klev 12y ago
      Possibly because there's a load of distracting crap (early/redundant code) they want to clear out before releasing to the public.
alanning 12y ago
Very interesting! To help give some context is it similar to Xamarin's approach but uses Javascript instead of C# as the base language? Also curious if you will be encouraging/hosting a components store similar to http://components.xamarin.com/ http://components.xamarin.com/?
thousande 12y ago
Interesting and look promising. Hopefully the announced performance improvements in v0.2 will solve stuttering scrolling in the demo[1] I am experiencing on Nexus4 https://play.google.com/store/apps/details?id=com.telerik.NativeScript https://play.google.com/store/apps/details?id=com.telerik.Na...
programminggeek 12y ago
I'm curious how this exactly differs from Titanium.
- joewrong 12y ago
  "No Mac machine required to build for iOS"
yamill 12y ago
so this is like Appcelerator? use javascript api to connect with native components and compile...
randunel 12y ago
I would expect <space> to work like on all other websites... scroll down 1 page, not to the end of content (and beginning of comments) :) At least they're not breaking the back button, but they are breaking all the keyboard scrolling buttons, such as PgUp/PgDn/UpArrow/DownArrow in FF
- moron4hire 12y ago
  I don't understand the motivation to override the keyboard shortcuts on a non-interactive page. Nobody ever advertises it, so it's always a surprise. And some places even make it a nearly integral part of the experience, which makes the site almost completely useless on a mobile device. It's like someone said, "hey, let's jerk off back of our customer's heads while they're eating dinner, they'll really be impressed with that."
jipiboily 12y ago
Everytime I see one of those, I want to love them. Then I remember how hard it is for those tools to keep up with the OS features. Not being able to add or fix stuff because a new OS version is out and the tool is not up to date (yet) is a total deal breaker. Been there, done that, bought the t-shirt. I would love to be proven wrong though! ;)
- increment_i 12y ago
  After trying every cross platform framework under the sun, I'm inclined to agree. I can appreciate the talent and engineering ingenuity required to build something like this but I'll take a wait and see approach. These things are almost constantly breaking so good luck to the team working on this, its a hell of a problem to bite off.
- swalsh 12y ago
  On the other hand Telerik has made a name for themselves by being very high quality tools. I'd trust them to do it right.
Rusky 12y ago
From the name I was hoping this would be some kind of alternative platform to JavaScript that kept the deployment model and dropped some of the baggage that comes from emscripten-like solutions. Instead, I found the opposite- putting JavaScript in between the app and the platform. It's a nice idea, and works pretty well. But instead of the idea of JavaScript-as-assembly, I'd like to see a standard bytecode, integrated into the browser as well as JS, designed for apps as well as/rather than document tweaking, with better control over the memory model, data manipulation, and thus performance. We could still run JavaScript, and even crazy C++-emscripten-asm.js stuff on top of that bytecode, but it would enable much faster (startup and runtime) and more power-efficient apps with a much simpler stack.
- jerf 12y ago
  That's call asm.js. asm.js is just a bytecode with a particularly baroque serialization right now; if it is widely adopted expect a more compact serialization to be one of the first "optimizations" released. asm.js is a really clever play to leverage Javascript to get JS out of the way, while never making it obvious that's what it's doing.
  - CmonDev 12y ago
    That's the only hope. Unfortunately there is so little news on that front and no enthusiasm from the side of mainstream language providers so far...
  - Rusky 12y ago
    asm.js is still stuck with the JavaScript memory model and type system no matter how it's serialized. I would almost be okay with a textual serialization of a language with better semantics.
    - vertex-four 12y ago
      > asm.js is still stuck with the JavaScript memory model and type system no matter how it's serialized. What? You're stuck dealing with ints and a heap of memory... which is exactly what you get when developing native code. On top of that, you can implement any memory model and type system you want. Are you saying you want a managed VM, so something further away from the processor? What features do you want, and which tradeoffs would it make? Why can't you just implement your managed VM on top of asm.js?
mgkimsal 12y ago
As someone doing Titanium development, this is an interesting development. On one hand, good to see more players getting in to this space, but... Telerik might get some strong traction because of the reputation for UI controls. Most other toolkits I've seen don't come with any, and you end up having to build a lot of stuff that you wouldn't think you'd need to build.
evo_9 12y ago
Reading through this thread it appears most are not familiar with what a joke Telerik is, at least in the .Net community where they sell a lot of control add-ons. Whenever I've had to work with there stuff I've ripped it out every time and replaced it either with a .net baseline control that was actually easier to work with and extend, or wrote my own. Now if I'm considering a job and I hear they are a heavy Telerik shop I know they are probably either all newbies or simply don't know what they are doing and I don't even interview there. I'm curious, do these guys actually have a positive rep outside the .net community? edit: typo.
- recursive 12y ago
  Telerik's controls appear to be optimized for development during presentations and demos.
- anon4 12y ago
  I live in the city where their hq is. Here they're colloquially called "the source code mill" or "the source code factory". As in, they take in junior cs students and mill out source code. A lot of people like working for them because they do take almost anybody and don't have high standards. You could call it the "bullshit job" of CS.
  - tluyben2 12y ago
    Sounds like a lot of companies :) But yes, the target audience for the components is probably the not very technical CTO (company wide or departmental) who believes that this will save a lot of money because stuff can be bought and not built. It'll end up as a few 100(0) developer licenses on a shelf, next to the 20 enterprise CMS licenses, the unused CRM licenses, the magic bullet never touched BI licenses etc. Edit: typo
- mattnibs 12y ago
  Could not agree more. Telerik is terrible. A part of me dies every time I run across a project that's been 'infected' with Telerik. You have to make sure you have the correct version of Telerik installed or your project just doesn't work and finding the correct version on their website is difficult. The markup for their controls is just horrendous. Documentation and support are just as bad. Sorry, I didn't read the article. Just looking for an excuse to curse Telerik.
TeeWEE 12y ago
Its using javascript. Seriously? Why? The only sensible reason to us it, is that a lot of users are using it. Technically there is no good reason to use old javascript imho.
LukeB_UK 12y ago
The name makes me think it's a language, not a framework.
euroclydon 12y ago
So does it compile JS to native code for each platform (I highly doubt) or does it utilize a JS interpreter in each platform? If the latter, does it ship the same interpreter or utilize one that comes with each platform?
peterhunt 12y ago
The comments on this post are the lowest quality I've seen on HN for a long time, so I feel compelled to actually make a meaningful one. This project exposes the native platform APIs to a JavaScript VM running on the device. It does not try to build cross-platform widgets as far as I can tell. This is generally a good idea. It's much better than WebView and friends because the DOM will always be slow and not have native-feeling interactions unless W3C decides to break backwards compatibility (they won't). It's also much better than trying to do a "write-once-run-anywhere" cross-platform widget library because those solutions never feel like the target platform either (see Swing vs SWT) This approach lets you teach your team one language and one set of idioms and then implement across different platforms. While I have some beefs with the details of the implementation it appears to me to be a winning strategy. BTW: I don't work for Telerik and know nothing about them.
- city41 12y ago
  I think it's doing both. Exposing native APIs for non UI related APIs, and providing an abstract UI layer that works across all devices. The article says: "Cross Platform UI abstractions - available will be full UI abstraction to build the application UI. All the UI code will be shared - you do not need prior Android, iOS or Windows knowledge."
- _random_ 12y ago
  "lets you teach your team one language" - good idea, but why pick one of the worse languages?
  - peterhunt 12y ago
    It's everywhere, and JS isn't so bad that it's unusable.
notastartup 12y ago
I got really excited about this but then saw the pricing page and it immediately killed any further motivation. I feel like they are trying to squeeze every cent out of developers every month. Lot of developers are against subscribing to develop on a proprietary platform. $1,299 / developer That was downright enough to lead me away. As I recall, a while back, there was another open source solution llvm or something like that which also let's you write cross platform mobile apps with Javascript but have not heard about them since.

77 points by orand 12y ago

yuchi 12y ago

This is mostly the same as https://github.com/appcelerator/hyperloop https://github.com/appcelerator/hyperloop I’m very, very curious to try it.

marcoms 12y ago
I would also be willing to try it, provided I didn't have to register with any services to do so
T-A 12y ago
I haven't looked closely at Hyperloop, but I thought it was meant to be a JavaScript-to-native compiler. NativeScript looks more like plain old Titanium: run JavaScript in V8, with an interface to native UI (and other) APIs.
- yuchi 12y ago
  The point is where the Titanium-esque part is built: kernel-land (native) or user-land (JS)? In Hyperloop/NativeScript (as far as I can understand NativeScript) it is done completely in JS-land, so there’s no difference between Titanium code and app-code. In plain old Titanium (Ti.Current) the bridge is in kernel-space.

Pacabel 12y ago

Are there any screenshots showing side-by-side comparisons between the same app implemented using this technology running on the different platforms it supports? I looked quickly through the article and the NativeScript web site, but couldn't find any. All I saw was rather useless marketing imagery.

blagoev 12y ago
You can check the companion apps on Google Play and Apple iTunes. Search for "NativeScript".
- leorocky 12y ago
  I've seen iOS UIs in Android apps before, but I've never seen an Android menu in an iOS app before: https://itunes.apple.com/us/app/nativescript/id882561588?mt=8 https://itunes.apple.com/us/app/nativescript/id882561588?mt=... https://play.google.com/store/apps/details?id=com.telerik.NativeScript https://play.google.com/store/apps/details?id=com.telerik.Na...

jtheory 12y ago

These kinds of frameworks will be quite useful, when mature. Though -- they're of course tackling a problem that gets harder the deeper you get into it, and has already been tried a few times, never with really great success. Java's AWT made a "lowest common denominator" kind of cross-platform UI back in the last 90s, and was fairly universally disliked (so Sun made Swing after that, which switched from "native components" to "over-engineered fake native components"). I hope the people building cross-platform UI for mobile devices now have studied the lessons to be learned from previous attempts -- mainly, I suspect, that getting something that kind-of works is exciting and fairly easy, but getting the detail right is grueling, thankless work, and ultimately impossible. It might be wise for them to start with the hardest, least-cross-platform-appropriate bits, and see in advance what compromises those will force.

blagoev 12y ago
The application UI is the native one. It's just that you use NativeScript to create it. It's not like an 'ugly' cross platform common denominator.
- slavoingilizov 12y ago
  I think you're misunderstanding jtheory. It's not about whether it's native or not - it's about using each platform's idioms and peculiarities which don't exist in other platforms. There isn't a 1-to-1 mapping between iOS UI elements and Android UI Elements. What do you do then? The Android Spinner is an example: http://developer.android.com/design/building-blocks/spinners.html http://developer.android.com/design/building-blocks/spinners... There is no alternative in iOS, but if you don't use it in your Android app you are missing out, because people on that platform expect it and know it. What about Back buttons in iOS? You don't need them in Android. If you are developing a cross-platform UI without using these elements, you are probably compromising the UX of your app. I am very interested in how those problems are solved. Will try and play around with it.
  - blagoev 12y ago
    The application you are building will use each platform's idioms. So the UI layer code will be platform specific and can not be reused. All other business logic code will be reused thought.

crncosta 12y ago

Opensource? no?! well, thank you but I already have a lot of problems with platform/vendor lock-in in the mobile world. But if you guys decided to change your mind and open the source, I will be glad to try :-)

blagoev 12y ago
It will be open sourced. Apache License Version 2.
alanning 12y ago
There are many areas in the article where they describe their plan to open source this. It's in their roadmap for v0.4 projected to be released in Oct. 2014. Also, "...This is the reason why we decided that once the core framework is implemented we will release the framework code under the Apache License Version 2. We already have an organization on http://github.com/NativeScript http://github.com/NativeScript where the project will be hosted and will be pushing the code shortly - now just go ahead and star us." ... from the section titled, "Open Source - not yet another proprietary framework".
- mkesper 12y ago
  I just wonder why they don't do it right from the start?
  - teh_klev 12y ago
    Possibly because there's a load of distracting crap (early/redundant code) they want to clear out before releasing to the public.

alanning 12y ago

Very interesting! To help give some context is it similar to Xamarin's approach but uses Javascript instead of C# as the base language? Also curious if you will be encouraging/hosting a components store similar to http://components.xamarin.com/ http://components.xamarin.com/?

thousande 12y ago

Interesting and look promising. Hopefully the announced performance improvements in v0.2 will solve stuttering scrolling in the demo[1] I am experiencing on Nexus4 https://play.google.com/store/apps/details?id=com.telerik.NativeScript https://play.google.com/store/apps/details?id=com.telerik.Na...

programminggeek 12y ago

I'm curious how this exactly differs from Titanium.

joewrong 12y ago
"No Mac machine required to build for iOS"

yamill 12y ago

so this is like Appcelerator? use javascript api to connect with native components and compile...

randunel 12y ago

I would expect <space> to work like on all other websites... scroll down 1 page, not to the end of content (and beginning of comments) :) At least they're not breaking the back button, but they are breaking all the keyboard scrolling buttons, such as PgUp/PgDn/UpArrow/DownArrow in FF

moron4hire 12y ago
I don't understand the motivation to override the keyboard shortcuts on a non-interactive page. Nobody ever advertises it, so it's always a surprise. And some places even make it a nearly integral part of the experience, which makes the site almost completely useless on a mobile device. It's like someone said, "hey, let's jerk off back of our customer's heads while they're eating dinner, they'll really be impressed with that."

jipiboily 12y ago

Everytime I see one of those, I want to love them. Then I remember how hard it is for those tools to keep up with the OS features. Not being able to add or fix stuff because a new OS version is out and the tool is not up to date (yet) is a total deal breaker. Been there, done that, bought the t-shirt. I would love to be proven wrong though! ;)

increment_i 12y ago
After trying every cross platform framework under the sun, I'm inclined to agree. I can appreciate the talent and engineering ingenuity required to build something like this but I'll take a wait and see approach. These things are almost constantly breaking so good luck to the team working on this, its a hell of a problem to bite off.
swalsh 12y ago
On the other hand Telerik has made a name for themselves by being very high quality tools. I'd trust them to do it right.

Rusky 12y ago

From the name I was hoping this would be some kind of alternative platform to JavaScript that kept the deployment model and dropped some of the baggage that comes from emscripten-like solutions. Instead, I found the opposite- putting JavaScript in between the app and the platform. It's a nice idea, and works pretty well. But instead of the idea of JavaScript-as-assembly, I'd like to see a standard bytecode, integrated into the browser as well as JS, designed for apps as well as/rather than document tweaking, with better control over the memory model, data manipulation, and thus performance. We could still run JavaScript, and even crazy C++-emscripten-asm.js stuff on top of that bytecode, but it would enable much faster (startup and runtime) and more power-efficient apps with a much simpler stack.

jerf 12y ago
That's call asm.js. asm.js is just a bytecode with a particularly baroque serialization right now; if it is widely adopted expect a more compact serialization to be one of the first "optimizations" released. asm.js is a really clever play to leverage Javascript to get JS out of the way, while never making it obvious that's what it's doing.
- CmonDev 12y ago
  That's the only hope. Unfortunately there is so little news on that front and no enthusiasm from the side of mainstream language providers so far...
- Rusky 12y ago
  asm.js is still stuck with the JavaScript memory model and type system no matter how it's serialized. I would almost be okay with a textual serialization of a language with better semantics.
  - vertex-four 12y ago
    > asm.js is still stuck with the JavaScript memory model and type system no matter how it's serialized. What? You're stuck dealing with ints and a heap of memory... which is exactly what you get when developing native code. On top of that, you can implement any memory model and type system you want. Are you saying you want a managed VM, so something further away from the processor? What features do you want, and which tradeoffs would it make? Why can't you just implement your managed VM on top of asm.js?

mgkimsal 12y ago

As someone doing Titanium development, this is an interesting development. On one hand, good to see more players getting in to this space, but... Telerik might get some strong traction because of the reputation for UI controls. Most other toolkits I've seen don't come with any, and you end up having to build a lot of stuff that you wouldn't think you'd need to build.

evo_9 12y ago

Reading through this thread it appears most are not familiar with what a joke Telerik is, at least in the .Net community where they sell a lot of control add-ons. Whenever I've had to work with there stuff I've ripped it out every time and replaced it either with a .net baseline control that was actually easier to work with and extend, or wrote my own. Now if I'm considering a job and I hear they are a heavy Telerik shop I know they are probably either all newbies or simply don't know what they are doing and I don't even interview there. I'm curious, do these guys actually have a positive rep outside the .net community? edit: typo.

recursive 12y ago
Telerik's controls appear to be optimized for development during presentations and demos.
anon4 12y ago
I live in the city where their hq is. Here they're colloquially called "the source code mill" or "the source code factory". As in, they take in junior cs students and mill out source code. A lot of people like working for them because they do take almost anybody and don't have high standards. You could call it the "bullshit job" of CS.
- tluyben2 12y ago
  Sounds like a lot of companies :) But yes, the target audience for the components is probably the not very technical CTO (company wide or departmental) who believes that this will save a lot of money because stuff can be bought and not built. It'll end up as a few 100(0) developer licenses on a shelf, next to the 20 enterprise CMS licenses, the unused CRM licenses, the magic bullet never touched BI licenses etc. Edit: typo
mattnibs 12y ago
Could not agree more. Telerik is terrible. A part of me dies every time I run across a project that's been 'infected' with Telerik. You have to make sure you have the correct version of Telerik installed or your project just doesn't work and finding the correct version on their website is difficult. The markup for their controls is just horrendous. Documentation and support are just as bad. Sorry, I didn't read the article. Just looking for an excuse to curse Telerik.

TeeWEE 12y ago

Its using javascript. Seriously? Why? The only sensible reason to us it, is that a lot of users are using it. Technically there is no good reason to use old javascript imho.

LukeB_UK 12y ago

The name makes me think it's a language, not a framework.

euroclydon 12y ago

So does it compile JS to native code for each platform (I highly doubt) or does it utilize a JS interpreter in each platform? If the latter, does it ship the same interpreter or utilize one that comes with each platform?

peterhunt 12y ago

The comments on this post are the lowest quality I've seen on HN for a long time, so I feel compelled to actually make a meaningful one. This project exposes the native platform APIs to a JavaScript VM running on the device. It does not try to build cross-platform widgets as far as I can tell. This is generally a good idea. It's much better than WebView and friends because the DOM will always be slow and not have native-feeling interactions unless W3C decides to break backwards compatibility (they won't). It's also much better than trying to do a "write-once-run-anywhere" cross-platform widget library because those solutions never feel like the target platform either (see Swing vs SWT) This approach lets you teach your team one language and one set of idioms and then implement across different platforms. While I have some beefs with the details of the implementation it appears to me to be a winning strategy. BTW: I don't work for Telerik and know nothing about them.

city41 12y ago
I think it's doing both. Exposing native APIs for non UI related APIs, and providing an abstract UI layer that works across all devices. The article says: "Cross Platform UI abstractions - available will be full UI abstraction to build the application UI. All the UI code will be shared - you do not need prior Android, iOS or Windows knowledge."
_random_ 12y ago
"lets you teach your team one language" - good idea, but why pick one of the worse languages?
- peterhunt 12y ago
  It's everywhere, and JS isn't so bad that it's unusable.

notastartup 12y ago

I got really excited about this but then saw the pricing page and it immediately killed any further motivation. I feel like they are trying to squeeze every cent out of developers every month. Lot of developers are against subscribing to develop on a proprietary platform. $1,299 / developer That was downright enough to lead me away. As I recall, a while back, there was another open source solution llvm or something like that which also let's you write cross platform mobile apps with Javascript but have not heard about them since.