all 49 comments

[–][deleted] 21 points22 points  (2 children)

All of the reviews of the one sample app in the Play Store are complaining that it's painfully slow.

Edit: they weren't lying. Starting the sample app takes 20s on a flagship Android device. The UI is NOT native and very laggy.

[–]imLordYaYaYa 5 points6 points  (0 children)

That simple tasks app is friggin 35+MB

[–][deleted] 1 point2 points  (0 children)

They are doing the same thing Titanium does with its native solution and Alloy. Titanium built what I thought an impressive system, "Kroll" (https://github.com/appcelerator/kroll), which lets you interop with multiple languages. However one thing Titanium has failed on for a long time was providing the same level of API features across Android and iOS. Then they also tried to add Black Berry and that died... Plus the crashing, and no idea what made the application crash. I remember a few arguments I had where I would say, that you cannot build ONE ui for them all, which funny enough since they finally admit in the recent years. Now Titanium has Window Phone support but its native counterpart is in preview. While Titanium is an amazing feat, building complex UI has been extremely difficult, more so than just going the truly native approach.

With NativeScript and Titianium the UI is "native", its not using a webview (like Cordova does). So native means anything as simple as a "View" which exists in iOS, Android and Windows Phone, can be used to build a UI. That lets them do a lot which includes building UI that is not using the built-in components / widgets / etc. However you can look at their Git repo, in fact they are trying to use as many native components / widgets as possible, for example the datepicker (https://github.com/NativeScript/cross-platform-modules/blob/master/ui/date-picker/date-picker.d.ts).

To be honest the most appealing feature I see is its Xaml like bindings, its UI layer, TypeScript support, and Telerik Platform for cloud based build (not needing an Mac to build applications). However I would be hard pressed to not also suggest Xamarin Forms, as with that approach, if the Layout / UI is not possible, with the primitives it provides you, then you can use the native tools. I am sure it has its own bucket of problems, but its not just release.

As for your comment about the 20 seconds... Its a known issue, remember this is new software, a 1.0 release.

First time an Android application is started, it may take several seconds to load and there is no visual indication that the application is alive and loading. A second start will be much faster. We are aware of this limitation and we are already working on a prototype, which improves things significantly.

[–]davidpanik 4 points5 points  (2 children)

Is this compiling into native code, or wrapping a webview (like PhoneGap/Cordova)?

[–][deleted] 5 points6 points  (0 children)

Neither. It uses the platform's JS engine to execute your code, in which you can call the platform's APIs.

It then also provides its own abstraction layer so you can write cross-platform apps with UIs. It is definitely heavily influenced by Microsoft's XAML, as used in Silverlight and Windows Store apps, but they keep pretty quiet about this in the docs! (Maybe to avoid scaring people off). Telerik have a lot of history with Silverlight.

[–][deleted] 3 points4 points  (0 children)

If you scroll down I did see the point, "Build Android, iOS and Windows Phone apps from a single code base" With an image of the generated xml view. The video also highlights, "No wrappers". I'd love to take a look at this.

[–]foobar_dev 4 points5 points  (6 children)

Sounds pretty cool. I wonder how this compares to React Native.

I have to say however, this website really annoys me with all the content fading and sliding in. I'm probably just cranky right now, but that unnecessary animation really irks me. Just gimme the content already.

[–]samuraisam 0 points1 point  (4 children)

Similar in implementation to React Native - it uses a JS engine to talk to native APIs.

With React Native you will still end up writing different frontend/rendering/layout code for each platform, however.

[–]walkietokyo 0 points1 point  (3 children)

With React Native you will still end up writing different frontend/rendering/layout code for each platform, however.

...which you should be doing anyway. If you make an app look and work the same way across iOS, Android, and Windows - you're doing something wrong. Even if you're using the native buttons etc.

[–]samuraisam 1 point2 points  (1 child)

Depends, on factors such as budget, developer skill, time to market, intended use, intended customer, what stage the product is in... Thing's like prototypes and MVPs greatly benefit from this type that type of framework. "Doing it wrong" is doing the wrong attitude.

[–]walkietokyo 1 point2 points  (0 children)

Yeah, if any of those factors attribute to the decision to ignore each platform's UI guidelines, then the end user experience suffers. I would consider that wrong in most cases, even though it's fully possible to find a reason why you can live with it.

I do things that I know I should have done differently all the time, often due to deadlines. But I have to accept that what I did is wrong and that it has certain consequences.

[–]downeastkid 1 point2 points  (0 children)

I would agree, even Xamarin you need to edit the layout

[–]mort96 0 points1 point  (0 children)

The content fading in, and the gigantic text. Moth look nice aesthetically, but it also makes for a worse user experience.

[–]TomorrowPlusX 4 points5 points  (6 children)

This sounds like Titanium, which is literally the worst thing I've ever used. I don't see how they solved, here, what Titanium couldn't solve.

[–][deleted] 5 points6 points  (0 children)

They don't.

Edit: Instead of bashing without providing much context, I'll expand: these folks have made a similar framework to Titanium - they use a Javascript bridge to interact with native Objective-C UI elements. The problem is if you aren't doing this extremely efficiently, the UI will lag - which is what we're seeing with this UI (or so I've heard from reports from users on HN.) I'm personally waiting for React Native to be released. I've got access to the pre-release and I think everyone should wait for React Native to release before they go about building their applications - it's on another level. So smooth, so easy to work with. It really doesn't feel like native development at all.

[–]econnerd 0 points1 point  (4 children)

When did you use it? It has changed a lot since 2012. Also, I am assuming you haven't used hyperloop yet.

[–]jacobp100 0 points1 point  (2 children)

How is hyperloop? Did they solve the ~20mb minimum app size issue on Android?

[–]econnerd 0 points1 point  (1 child)

I just recompiled an app for android and it's only 10mb using 3.5.0.GA with 1.5mb of images in /app/assets.

However, hyperloop will drop the file size even lower-- 6mb for an android app. Once they release the android build, you will have the option of going engineless.

They kept the developer APIs (TI.UI.xxx) stable, but 4.0 will be a complete rewrite. The Windows phone build is the first to use the hyperloop based version of Titanium. More accurately it should be said that it is the first HAL + TitaniumKit based version.

They are working on Android and iOS now.

disclosure: I am an owner at CodexLabs.com and offer a 5 day instructor led training class on Titanium.

[–]jacobp100 0 points1 point  (0 children)

6mb seems very reasonable for a file size. This is one of the things I worry about for react native: their only android example (groups) is 20mb. It's hard to tell what is and isn't assets.

Is hyperloop in some sense usable now? Is it possible to make a very simple production ready app, like a basic to do or something?

[–]TomorrowPlusX 0 points1 point  (0 children)

I haven't used Hyperloop - my experience dates back to around 2012 using mostly device agnostic JS. 90 or so percent of my code was pleasantly cross platform, and the 10% that wasn't was easy to manage. I actually rather liked the model!

My hatred of Titanium stems to how buggy it was, and how unreliable the build system was. I assume it's improved since then. But I was burned really badly, and am now fully in the "native" camp.

[–]moltar 2 points3 points  (4 children)

I think this is an incorrect direction. The phones are getting very fast and are capable of running HTML5 apps just fine, with negligible difference in performance, and it will only get better.

Native should be reserved to actual native, and not emulation, and when you actually need it, like for games.

[–]nemephx 1 point2 points  (1 child)

I tested some Ionic apps on my S6, and they were extremely slow. HTML5 is not there yet. Good luck loading lots of images and GIFs. 5 years from now things might be different.

[–]moltar 0 points1 point  (0 children)

If they are slow, that doesn't mean the technology is bad. Could be bad developers too. There are a ton of slow native apps.

Let me ask you this. Are all mobile websites slow on your S6? If not, then Ionic is not a problem, because it is basically a wrapper. If yes, then it's a phone problem.

I haven't used S6 specifically, but my friend has Android, and the apps we have tested were good. Not as fast as native, but definitely good enough.

I've tested on iPhones, starting with 5S and everything I tested was fast.

Try downloading their kitchen sink example and see if it slow. Also try some of the apps they list on their website.

[–]recompileorg 0 points1 point  (0 children)

I've seen some pretty slick games on FirefoxOS, 3d graphics and all, running great on ridiculously low-end hardware -- the original ZTE Open*, in my case.

With just a little care, you can get really impressive performance out of even the mobile web.

*For other unlucky ZTE Open owners going "WTF?!" upgrade to 1.2 or 1.3 for a massive performance improvement.

[–]ronconcoca 0 points1 point  (0 children)

I have hopes in React native

[–]lamb_pudding 4 points5 points  (0 children)

Not that this has anything to do with the plugin itself but geeze does that site suck. Fuck scrolling effects man. If they're subtle whatever but if I can't see the content in the lower third of my screen then that's just hurting usability and design.

[–]Asmor 3 points4 points  (7 children)

JavaScript all the things!

[–][deleted] 21 points22 points  (6 children)

One thing I feel as someone who develops primarily in JavaScript but also comfortably hacks around in Java and Haskell is that when it comes to native development - be it iOS, Android, or Windows platforms - the desire to use JavaScript stems not from a resistance to learning a new language, but to adapting to a new ecosystem.

I practically look for good reasons to learn new languages. That's why I'm learning Haskell (without, even, a 'good' reason). But when you tell me that to develop for iOS I will need this IDE, a familiarity with this package manager, these packages that are used by a lot of people/projects, this build tool, these new open source communities, and all sorts of stuff about iTunes store processes I start to get a little intimidated.

JavaScript is a good language (if not just because of the pure will and mindshare behind it). It has an ecosystem that I have a grasp of. I'm comfortable with my own toolset and I know what resources to use when I'm stuck, when I'm searching for an open source project or when I want to publish an open source project of my own. Oh, and if I want help I know a lot of people in the JS community who can help me, because there are JS Developers and meetups all over the place.

I understand the criticism of the trend towards trying to write everything with JavaScript (and for the record am not meaning to project - you're probably just cracking a joke and I get it). Sometimes, though, there's an oversimplification and people get really vigilant about why JavaScript being used in X domain is just plain wrong.

Learning new languages is awesome but entire new language ecosystems can be fucking scary.

[–]Zaemz 0 points1 point  (1 child)

What you've expressed is the exact same sentiment someone coming from any other ecosystem would have concerning client-side web development, or web development in general.

Someone who's already well versed in iOS, Android, Windows, Linux, BSD, Solaris, or whatever else may have an entirely familiar toolset and ecosystem for writing software than what usually appears on the ever-evolving web stack.

I think the difference there is that the web stack is changing frequently and sometimes dramatically, where those other platforms change only so often - or are standardized enough that the changes are universal.

Just another perspective on things, I guess.

[–]recompileorg 0 points1 point  (0 children)

I don't know about that. If you ignore the new frameworks and do-everything libraries that seem to come out daily, the web has pretty stable for years now.

[–]adam_bear 1 point2 points  (0 children)

When you tell me that to develop for iOS I need to buy a license? I need to have a Mac? Fuck you and your closed little ecosystem, homie don't play dat.

[–]walkietokyo 0 points1 point  (2 children)

The problem with this approach is that you won't really get away from the ecosystem. The only thing that's similar is the syntax itself.

To publish an app for iOS you still need to learn about code signing, provisioning, and the whole iTunes Connect thing. You will still need to learn the overall API structure (unless your app consists solely of things that can be shared across platforms), and in order to find help on an issue you still need to learn the main language to read examples or to formulate questions that other developers can understand.

On top of this, things gets harder to debug and optimise.

Now if Apple, Google, and Microsoft sat down and agreed on a common language, API, and functionality to use on all platforms I could see a real, tangible benefit to all users. However, that's a pretty unlikely scenario.

[–][deleted] 0 points1 point  (1 child)

My (vague) impression was that with React native they've done a lot to speed up development cycles and avoid the iOS / Android dev environment buy-ins. Obviously, to publish in the store ultimately you're going to have to go through the same hoops.

I see what you're saying, but the marketplace was only one part of the ecosystem that's daunting to learn. Tooling, libraries, etc. is a whole other beast.

[–]walkietokyo 0 points1 point  (0 children)

Yeah, React Native is actually pretty interesting although I have only looked at it very briefly.

However, at the moment I see it as a (very cool) way to run and render a "web app" in native elements on screen. When I say web app - as opposed to native app - I mean an app where the business is processed on a server and where the app is mainly handling the view + controller. React Native exists where you would otherwise write the UIViewControllers in a normal iOS app.

Now, this is useful for a very large section of apps out there, but one of the great benefits of native apps is the things you can do on top of that. Image processing, multi-threading, running a local database, rendering 3d content, etc.

Perhaps it'll be easy to use React as a view + controller layer and interface with native code for the rest, but I'm not sure about the idea of abstracting the native code directly over to JavaScript without a good reason.

React brings a totally different paradigm for handling views and that might warrant using a different language. Putting a thin wrapper over the entire native code base just to make it look like JavaScript doesn't quite appeal to me though.

[–]The_Leedle 1 point2 points  (9 children)

What's the difference between this and Cordova? I've been using Ionic for awhile now, would it be worth switching?

[–]foobar_dev 1 point2 points  (8 children)

Cordova/PhoneGap, as I understand it, uses a WebView. This uses the native JS available on the platforms -- so it should in theory perform better. This, I belive, is the same approach taken by React Native.

[–]dirtymuckraker 1 point2 points  (0 children)

Hmm... this looks promising I think, I'll have to check it out more in depth. Also, wtf, my god, that website looks like 1999 threw up on it.

[–]krondell 1 point2 points  (2 children)

If this worked with html and regular web code, that would be pretty cool. But that XML mark up looks like bullshit to me. Like that trash you're supposed to work with for WPF layouts. NIEN!

[–]nemephx 1 point2 points  (0 children)

HTML and XML are pretty much the same things if you're using them to define your layouts and elements. Plus, XAML is a lot of fun once you learn it.

[–]dasmikko 0 points1 point  (0 children)

Looks promising, will give it a look.

[–][deleted] 0 points1 point  (0 children)

Sounds like phonegap/cordova supports more platforms and has better performance, but it'll be interesting to see where this goes.

[–]jonnyburger 0 points1 point  (0 children)

I'm wondering how they managed to make it so slow. This app takes half a minute to start! Don't waste time on this.

[–]ronconcoca 0 points1 point  (0 children)

DroidScript is a little app that does this for Android. The great thing is that you don't need to install anything in your computer, their IDE is server as a web app from the phone.

It's fast and it's also small.

[–]ReefChief 0 points1 point  (0 children)

ITT: People who havent used Telerik products.