JUniversal vs NativeScript: What are the differences?
What is JUniversal? A new, Java-based approach to cross-platform mobile apps (used by Google Inbox and Google Spreadsheets). The vision of JUniversal came from some guys at Nokia who possess considerable expertise both in Java and in building cross-platform apps. They built this tool to provide an elegant way to translate source code and make it useful across multiple platforms. JUniversal offers you the freedom to write your shared code in Java and then translate it to C# (available now) or to C++/Objective C++ (coming soon). You can also combine JUniversal with Google’s j2objc translator to translate Java to Objective-C for iOS.
JUniversal and NativeScript can be primarily classified as "Cross-Platform Mobile Development" tools.
Some of the features offered by JUniversal are:
- OAuth (based on Scribe)
- Unit testing (JUnit)
On the other hand, NativeScript provides the following key features:
- 100% Access to Native Platform API
- NativeScript is free of charge as an open source project
JUniversal and NativeScript are both open source tools. It seems that NativeScript with 17.2K GitHub stars and 1.27K forks on GitHub has more adoption than JUniversal with 132 GitHub stars and 22 GitHub forks.
What is JUniversal?
What is NativeScript?
Want advice about which of these to choose?Ask the StackShare community!
Why do developers choose JUniversal?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using JUniversal?
What are the cons of using NativeScript?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
It is using the native components to build the UI and offers the best skills reuse story. All you need to know is JS/TS and CSS. Angular 2 is also supported which leads to even more code reuse across web and mobile.This is also the best way to access the native platform APIs directly.
NativeScript allows you to reuse your JS skills to build Native mobile apps without any sacrifices. It takes a bit to learn about all possible features, but each time you discover a new one you can't help but get more and more excited.
Comment from HackerNews (https://news.ycombinator.com/item?id=8998736)
This is how Google Inbox and Google Spreadsheets works. See the slides from my recently produced GWT Create Session (http://t.co/ZvoaHxCoZT). J2ObjC slide deck here (https://docs.google.com/presentation/d/1mW_Plm5jAygELf7qjVK7...) Videos of the conference will be online soon.
Prior to that, some 20% Googlers also produced the PlayN library (https://github.com/threerings/playn) This was taken over by Michael Bayne who added an iOS backend by Bytecode -> IKVM -> Mono conversion. I beleive j2objc and RoboVM backends exist now as well.
The major benefit of the j2objc approach is the avoidance of GC in favor of ARC, the conversion of message-sends into C-method calls when possible, and integration with existing iOS toolchain.
When we started, it seemed like an iffy idea, but after developing a product delivered to millions of users on a high volume site (gmail) that has 70% code sharing, and being able to simultaneously develop, test, and deploy across the platforms reasonably efficiently, a lot of skeptics have become converts to the concept.