NativeScript – Cross-platform framework for building native mobile applications(blogs.telerik.com)
blogs.telerik.com
NativeScript – Cross-platform framework for building native mobile applications
http://blogs.telerik.com/valentinstoychev/posts/14-06-12/announcing-nativescript---cross-platform-framework-for-building-native-mobile-applications
18 comments
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."
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.
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.
Bytecode formats are a balancing act. You have to be careful about freezing in a poor format that makes good trade offs for now but locks you into tradeoffs that aren't as good in the future. Java's stack-based virtual machine code was great when people had visions of 8-bit microcontrollers on toasters running Java from a several megabyte PROM. Michael Franz's SafeTSA doctoral thesis showed that an SSA-based bytecode allows a JIT to generate faster native code, and spend less time generating that native code. Many "embedded" systems today put to shame the desktops (and even many workstations) of the early Java days.
Stack machines tend to have small bytecode and it's relatively easy to write a small low-performance stack machine interpreter. Register machine bytecodes tend to take up more space, but it tends to be easier to write high performance interpreters and reasonable JITs. If you're always going to generate machine code, an SSA format minimizes the work/time necessary for a JIT to generate high-performing machine code, but it's difficult to write a high performance non-JITing interpreter for SSA-based bytecodes.
SpiderMonkey, Java, CPython, Forth, and SmallTalk (blue book) all use stack-based bytecodes. LuaJIT, Android's Dalvik, Squirelfish, and Parrot use register-based bytecodes. Michael Franz's SafeTSA (alternative JVM bytecode) and LLVM bitcode are compactly serialized SSA representations.
Microsoft has done some research on using arithmetically compressed syntax trees as an alternative JavaScript format. Part of me feels this is the best approach, as it speeds up transmission and parsing that all JavaScript engines have to do anyway, without performing transformations that JITs spend a fair amount of effort undoing later.
Ideally, I'd like to see a compressed SSA format, with optional debugging symbols and optional decompiling hints, analogous to WavPack's hybrid lossless audio format. The format could be losslessly expanded back into the original JavaScript source, or it could be stripped down to something like a binary with debugging symbols, or it could be further stripped down to just the data necessary to generate fast machine code.
Stack machines tend to have small bytecode and it's relatively easy to write a small low-performance stack machine interpreter. Register machine bytecodes tend to take up more space, but it tends to be easier to write high performance interpreters and reasonable JITs. If you're always going to generate machine code, an SSA format minimizes the work/time necessary for a JIT to generate high-performing machine code, but it's difficult to write a high performance non-JITing interpreter for SSA-based bytecodes.
SpiderMonkey, Java, CPython, Forth, and SmallTalk (blue book) all use stack-based bytecodes. LuaJIT, Android's Dalvik, Squirelfish, and Parrot use register-based bytecodes. Michael Franz's SafeTSA (alternative JVM bytecode) and LLVM bitcode are compactly serialized SSA representations.
Microsoft has done some research on using arithmetically compressed syntax trees as an alternative JavaScript format. Part of me feels this is the best approach, as it speeds up transmission and parsing that all JavaScript engines have to do anyway, without performing transformations that JITs spend a fair amount of effort undoing later.
Ideally, I'd like to see a compressed SSA format, with optional debugging symbols and optional decompiling hints, analogous to WavPack's hybrid lossless audio format. The format could be losslessly expanded back into the original JavaScript source, or it could be stripped down to something like a binary with debugging symbols, or it could be further stripped down to just the data necessary to generate fast machine code.
SSA is probably the best idea- I wouldn't put too much effort into making the bytecode nice for interpreters, since that's not a very common way of running JS. With a simpler type system (i.e. not dynamically typed), there would be even less reason to interpret or even partially JIT- may as well just design it to be pre-optimized and fast to just AOT the whole thing.
The Mill CPU is interesting here, in that it's a belt machine, so SSA is very close to what its native machine/assembly looks like. It basically takes what is currently register renaming and drops the layer of ISA registers, and just refers to the results of previous instructions relative to the current one. That sort of architecture would be almost trivial to JIT SSA for- you wouldn't even need register allocation, just instruction scheduling.
Another consideration to go along with decompiling hints, debug symbols, etc. is that web pages are very transparent and manipulable with the browser's inspector and JS console. Any new bytecode would ideally keep the ability to poke around the app's data and interface- it's a very nice REPL-type tool.
The Mill CPU is interesting here, in that it's a belt machine, so SSA is very close to what its native machine/assembly looks like. It basically takes what is currently register renaming and drops the layer of ISA registers, and just refers to the results of previous instructions relative to the current one. That sort of architecture would be almost trivial to JIT SSA for- you wouldn't even need register allocation, just instruction scheduling.
Another consideration to go along with decompiling hints, debug symbols, etc. is that web pages are very transparent and manipulable with the browser's inspector and JS console. Any new bytecode would ideally keep the ability to poke around the app's data and interface- it's a very nice REPL-type tool.
I feel you. Unfortunately there is this huge strange delusion, that language and VM evolution is over and JavaScript is a silver-bullet just because it happens to be so widely supported. I don't know how we are going to solve the problem of such a mindset.
PS: no transpilation and other 3+ step "compilation" offers.
PS: no transpilation and other 3+ step "compilation" offers.
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.
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.
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...
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.
> 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?
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?
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.
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.
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.
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...
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.
The Android Spinner is an example: 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.
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.
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).
I think for many apps out the codebase is dominated by UI code, and the business logic part is small and relatively easy to write anyway. From personal experience, sure, I have some classes that abstract away server APIs and some classes for data models. But most time and sweat goes into getting the UI to look good and performant on different devices.
Say, for an app like Timely [1] which I'm a fan of, I would think the data models for timers and alarms are trivial, and the code for all the subtle animations is where all the meat is.
[1] https://play.google.com/store/apps/details?id=ch.bitspin.tim...
Say, for an app like Timely [1] which I'm a fan of, I would think the data models for timers and alarms are trivial, and the code for all the subtle animations is where all the meat is.
[1] https://play.google.com/store/apps/details?id=ch.bitspin.tim...
This is really the way to go. Customize the UI to the platform make the app as polished as possible, but don't give up cross-platform business logic/unified deployment.
I agree with what you said, but I'm curious about Android Spinners. They look like select drop downs. Why are they called spinners? What makes them unique to Android? iOS of course also supports drop downs, and the UI implementation for a drop down actually looks like a spinner in iOS...
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.
I looked quickly through the article and the NativeScript web site, but couldn't find any. All I saw was rather useless marketing imagery.
You can check the companion apps on Google Play and Apple iTunes. Search for "NativeScript".
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://play.google.com/store/apps/details?id=com.telerik.Na...
https://itunes.apple.com/us/app/nativescript/id882561588?mt=...
https://play.google.com/store/apps/details?id=com.telerik.Na...
This is mostly the same as https://github.com/appcelerator/hyperloop
I’m very, very curious to try it.
I’m very, very curious to try it.
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.
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.
I would also be willing to try it, provided I didn't have to register with any services to do so
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.
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! ;)
Been there, done that, bought the t-shirt.
I would love to be proven wrong though! ;)
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.
These things are almost constantly breaking so good luck to the team working on this, its a hell of a problem to bite off.
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.
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.Na...
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/?
Also curious if you will be encouraging/hosting a components store similar to http://components.xamarin.com/?
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
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
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."
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?
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.
The name makes me think it's a language, not a framework.
I'm curious how this exactly differs from Titanium.
"No Mac machine required to build for iOS"
so this is like Appcelerator?
use javascript api to connect with native components and compile...
use javascript api to connect with native components and compile...
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.
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.
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.
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.
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
Edit: typo
Telerik's controls appear to be optimized for development during presentations and demos.
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.
Sorry, I didn't read the article. Just looking for an excuse to curse Telerik.
Why bashing a company without even reviewing the project? It's like saying F# is terrible, because it's by Microsoft, and without caring to look into what F# is. Be fair! Even the crappiest company can come out with a decent project!
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.
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.
$1,299 / developer
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.
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 :-)
But if you guys decided to change your mind and open the source, I will be glad to try :-)
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 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".
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 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".
It will be open sourced. Apache License Version 2.
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.