
NativeScript – Cross-platform framework for building native mobile applications - orand
http://blogs.telerik.com/valentinstoychev/posts/14-06-12/announcing-nativescript---cross-platform-framework-for-building-native-mobile-applications
======
peterhunt
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.

~~~
_random_
"lets you teach your team one language" \- good idea, but why pick one of the
worse languages?

~~~
peterhunt
It's everywhere, and JS isn't so bad that it's unusable.

------
Rusky
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
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.

~~~
Rusky
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
> 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?

------
jtheory
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
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
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...](http://developer.android.com/design/building-
blocks/spinners.html)

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
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.

~~~
tluyben2
This is often a returning topic here on HN where most users probably work in
startups and/or companies with consumer facing apps. Those would want every
platform to have the look & feel of the platform you're running on.
Although... Seems the new version of iOS Skype is WP8 styled and feels a bit
alien on iOS while it's not unpleasant at all. So not sure if I agree always.
Anyway; if you have apps for internal use or use with partners, it is actually
often better for the apps to be 100% identical on all platforms as that will
save tons of support calls. That's why a lot of companies just do iOS first,
design it for that and will make the Android version exactly identical. To
save time there, often HTML5/Cordova is used for that by internal departments
/ IT, but I know you can make MUCH nicer apps in the same / less time if you
use Xamarin (Forms or Metaframe) (or maybe a solution like this) (although I
cannot imagine IT would pick JS over .NET or Java, ever).

------
Pacabel
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
You can check the companion apps on Google Play and Apple iTunes. Search for
"NativeScript".

~~~
leorocky
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=...](https://itunes.apple.com/us/app/nativescript/id882561588?mt=8)

[https://play.google.com/store/apps/details?id=com.telerik.Na...](https://play.google.com/store/apps/details?id=com.telerik.NativeScript)

------
yuchi
This is mostly the same as
[https://github.com/appcelerator/hyperloop](https://github.com/appcelerator/hyperloop)

I’m very, very curious to try it.

~~~
T-A
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
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.

------
mgkimsal
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.

------
jipiboily
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
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.

------
thousande
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.Na...](https://play.google.com/store/apps/details?id=com.telerik.NativeScript)

------
alanning
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/)?

------
randunel
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
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."

------
euroclydon
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?

------
TeeWEE
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
The name makes me think it's a language, not a framework.

------
programminggeek
I'm curious how this exactly differs from Titanium.

~~~
joewrong
"No Mac machine required to build for iOS"

------
yamill
so this is like Appcelerator?

use javascript api to connect with native components and compile...

------
evo_9
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.

~~~
anon4
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
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

------
notastartup
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.

------
crncosta
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 :-)

~~~
alanning
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
I just wonder why they don't do it right from the start?

~~~
teh_klev
Possibly because there's a load of distracting crap (early/redundant code)
they want to clear out before releasing to the public.

