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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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?
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.
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.
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.
$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.
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".
[+] [-] peterhunt|11 years ago|reply
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|11 years ago|reply
[+] [-] _random_|11 years ago|reply
[+] [-] Rusky|11 years ago|reply
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.
[+] [-] KMag|11 years ago|reply
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.
[+] [-] CmonDev|11 years ago|reply
PS: no transpilation and other 3+ step "compilation" offers.
[+] [-] jerf|11 years ago|reply
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.
[+] [-] jtheory|11 years ago|reply
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|11 years ago|reply
[+] [-] Pacabel|11 years ago|reply
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|11 years ago|reply
[+] [-] yuchi|11 years ago|reply
I’m very, very curious to try it.
[+] [-] T-A|11 years ago|reply
[+] [-] marcoms|11 years ago|reply
[+] [-] mgkimsal|11 years ago|reply
[+] [-] jipiboily|11 years ago|reply
Been there, done that, bought the t-shirt.
I would love to be proven wrong though! ;)
[+] [-] increment_i|11 years ago|reply
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|11 years ago|reply
[+] [-] thousande|11 years ago|reply
https://play.google.com/store/apps/details?id=com.telerik.Na...
[+] [-] alanning|11 years ago|reply
Also curious if you will be encouraging/hosting a components store similar to http://components.xamarin.com/?
[+] [-] randunel|11 years ago|reply
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|11 years ago|reply
[+] [-] euroclydon|11 years ago|reply
[+] [-] TeeWEE|11 years ago|reply
[+] [-] LukeB_UK|11 years ago|reply
[+] [-] programminggeek|11 years ago|reply
[+] [-] joewrong|11 years ago|reply
[+] [-] yamill|11 years ago|reply
use javascript api to connect with native components and compile...
[+] [-] evo_9|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] recursive|11 years ago|reply
[+] [-] mattnibs|11 years ago|reply
Sorry, I didn't read the article. Just looking for an excuse to curse Telerik.
[+] [-] kolev|11 years ago|reply
[+] [-] notastartup|11 years ago|reply
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|11 years ago|reply
But if you guys decided to change your mind and open the source, I will be glad to try :-)
[+] [-] alanning|11 years ago|reply
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".
[+] [-] blagoev|11 years ago|reply