Mobile app is most most certainly going to be made using html and javascript in the time to come. Ionic and angular is great for building mobile apps with standard mobile UI elements like headers with back buttons and chevrons, pages that slides in from the side, modals and tab bars at the bottom of the screen. Everything is meticulously created in html, css and javascript. Scrolling is good enough for most usecases, but if your pages contains long list views with graphic elements the page starts to lag.
However if you use famo.us' list view scrolling is nearly as fast and smooth as native code on iPhone 4. On newer phones to difference between hybrid apps and native is unnoticeable. At the moment famo.us only has low level components, like boxes with html content. Standard back buttons, chevrons, tabs, action sheets and icons has to be imported from elsewhere. Famo.us only does fast bouncy animations, touch events and 3d effects. Besides famo.us is working on their phonegap/cordova alternative wrapper.
A combination of Ionics ease of use and famo.us' impressive speed would have been great. There's lot of promising little open source projects on github that either extends famo.us or integrates it with javascript MVC libraries.
I believe Brendan Eich was right when he said "Always bet on JS!". I bet mobile app development is going to be dominated by JavaScript and HTML.
What a dreadful notion, I hope this never happens. Development on mobile devices is a great way to develop on a web connected platform that reaches lots of consumers, but instead of using horrible, ancient tools that are expected to do things today that they were never designed to do at the time of their inception(HTML/CSS/Javascript), you can use capable systems languages like C(and now Swift, which I have no experience with but have heard generally good things about) and Java.
That I call traditional frontend web tech ancient and out of place today isn't even really an opinion - the deluge of Javascript/CSS frameworks, compile-to languages,and lists of best practices would suggest that something is wrong there. Web stuff is just way easier to get into so there are a huge amount of developers available, especially the types who spend more time yapping on their blogs about the latest overhyped software trend than actually writing software.
I don't know about animations and whatnot, but for games and image processing i.e. 2 enormous chunks of all mobile software, Javascript isn't replacing anything anytime soon.
I don't understand why someone would want to spend hours trying to optimize languages which weren't designed to run native software on a platform to be as effective as the ones that were when you could just write the software in the native language, to me this just seems like an exercise in futility. Even moreso considering the fact that Javascript and HTML are horribly unproductive languages, though I suppose since so many people know them well they can be more productive in them than in a language they don't know.
I don't understand why someone would want to spend hours trying to optimize languages which weren't designed to run native software on a platform to be as effective as the ones that were when you could just write the software in the native language, to me this just seems like an exercise in futility. Even moreso considering the fact that Javascript and HTML are horribly unproductive languages, though I suppose since so many people know them well they can be more productive in them than in a language they don't know.
I don't understand how you can fail to understand this.
People want to write cross-platform apps for mobile devices. The marketplace is pretty evenly split between iOS and Android devices, and anybody releasing an app probably wants to make it available on both platforms. However, the cost of using two entirely separate tooling stacks to do this could easily be far too high for small apps.
Your dislike of HTML/CSS/Javascript is pretty baseless too. Lots of developers like them, are productive in them, and don't feel that they're all that bad. The fact that compile-to-JS/CSS languages exist is meaningless – it's like complaining that assembly is useless because nobody uses it directly.
And bear in mind that JS now approaches ~0.5x native C code performance with Asm.js – this is better than Dalvik[1]. That opens up a lot of options.
>it's like complaining that assembly is useless because nobody uses it directly
Everybody always tries to make this comparison(WELL IF YOU WANT IT TO RUN SO GOOD JUST WRITE IT IN ASSEMBLY), and it really goes to show how little they know. Programmers don't write things in assembly because today's compilers can write much better assembly than pretty much anyone. No compiler can write C better than even a mediocre programmer, which is why if you want to write something that runs very smoothly or requires high performance stuff, you write it in a C-family or JVM language.
That aside, specifically your comparison makes no sense to me. Everything is assembly underneath, so I don't think anyone would say that it is useless unless they had part of their brain stem missing.
HTML and JS have no place on mobile(aside from fools trying to shove them on there, hence my rant), they could be completely removed from the equation and nothing would change, and people who actually want to build good products rather than SHIP AS FAST AS POSSIBLE AT THE LOWEST COST POSSIBLE ON EVERY PLATFORM SIMULTANEOUSLY SO WE CAN MAKE THE MOST PROFIT POSSIBLE FUCK IF IT RUNS LIKE SHIT could chug along making great products, with languages designed to make great products on that platform. The developers that feel they "aren't that bad" are probably ones who haven't used anything else and don't even care to try, which is why they are trying to make them work on mobile.
> Programmers don't write things in assembly because today's compilers can write much better assembly than pretty much anyone.
I don't buy that statement. In college we'd write a small program in assembler, then write that same program in C and compare the generated assembler code. The generated code was always longer than the hand-written code and often times significantly longer.
The main reason we don't write assembler anymore is we don't need to!
I don't know – as a developer with many years of experience, from assembly to web technologies, I think I'm pretty qualified to make this comparison :)
No compiler can write C better than even a mediocre programmer
That's not true at all – there are a whole bunch of examples which transpile other languages to C. The point is to work in a system that effectively communicate's ones intentions – that fact that it's C underneath is almost irrelevant.
Everything is assembly underneath, so I don't think anyone would say that it is useless unless they had part of their brain stem missing
I'd argue the same for the combo of Javascript, HTML and CSS, given that it's one of the few cross-platform tool for building user interfaces. Anybody arguing that it's useless is missing the big picture.
HTML and JS have no place on mobile(aside from fools trying to shove them on there, hence my rant), they could be completely removed from the equation and nothing would change
I mean, they clearly do. Otherwise, we wouldn't have a web, and every site that currently exists would be accessed through a native app. That's obviously silly.
and people who actually want to build good products rather than SHIP AS FAST AS POSSIBLE AT THE LOWEST COST POSSIBLE ON EVERY PLATFORM SIMULTANEOUSLY SO WE CAN MAKE THE MOST PROFIT POSSIBLE FUCK IF IT RUNS LIKE SHIT could chug along making great products
No, there's a distinct tradeoff to be made. Let's say you're a service with a small staff trying to publish a mobile app. You obviously need it to work across multiple platforms, given the current state of the market. In many cases, the cost of maintaining two separate codebases, and two separate teams, will simply not be worth the expense. If you are delivering a relatively simple app, then it's something that could quite possibly be built using the web stack – sacrificing some quality of UX in exchange for actually having a shipping product at all.
The UX of a native app will continue to be better for the moment. But the gap has closed significantly in the past couple of years, and I don't see any reason that it won't continue to do so, as platform developers and others work to fix the remaining issues.
The developers that feel they "aren't that bad" are probably ones who haven't used anything else and don't even care to try, which is why they are trying to make them work on mobile.
I've personally developed native applications for Android, iOS and Blackberry, and have also developed a couple of cross-platform apps that ran across all three with Phonegap. The UX wasn't as good as fully-native apps would have been, but building multiple apps would not have been cost-effective in these cases, and the output wasn't all that bad. So I guess that invalidates your point.
Sure there are languages that transpile to C, but they don't run as well as hand written C. I wasn't saying that compilers couldn't write C, I was saying they couldn't do it better than a human.
"instead of using horrible, ancient tools" (JavaScript=1995, HTML 5 spec=2014) "use capable systems languages like C" (Objective-C=1982, C=1972, Java=1994). WTF?
C-family languages are still the best languages for systems dev, they've aged well, and Java is good for it as well. Systems dev hasn't changed much since they were developed, mostly just more transistors and cores were shoved into processors and more RAM became available. And it still stands that pretty much you can do with a computer, you can do with C. This is NOT the case with JS/HTML. HTML was developed during the time of static webpages, and JS was literally cobbled together in 10 days, and meant to provide functionality where webpages could talk to a webserver off in the background and not have to refresh, and to make HTML more dynamic.
The rich web applications that have become standard today are not what HTML and JS were designed for, hence, as I said before, the deluge of frameworks and compile-to languages that try to put bandaids over Javascripts warts. Even huge players like Google push stuff like Dart because JS is so bad.
Few people have tried to develop a replacement for C(aside from fringe projects like Rust), mainly because it's good at what it does - anything you can do with a computer. Yes, Swift is meant as an ObjC replacement, but it seems more aimed at improving programmer productivity than fixing anything wrong with ObjC.
HTML AND JS WERE NOT DEVELOPED TO RUN NATIVELY ON DEVICES! WHY WOULD YOU WANT THEM TO RUN ON DEVICES?
HTML AND JS WERE NOT DEVELOPED TO RUN NATIVELY ON DEVICES! WHY WOULD YOU WANT THEM TO RUN ON DEVICES?
Please don't shout. HTML and JS were developed to run on any device, past, present and future. HTML is actually pretty good at presenting most UI state along with documents - the UI of the vast majority of native device apps is really not hard to present as html, the only roadblock is the vendors lack of focus on mobile web view performance. JS is a mixed bag, and as you say pretty rushed, and not the favourite language of many - I wouldn't want to write an app in it, though of course it is possible.
The choice developers are presented with here is to commit to learning each new API/Language on the continually shifting sands of OS vendor APIs for multiple vendors/devices, or to commit to an open but less performant toolkit they know will be around for a while, but which has the advantage of being stable, cross platform, and not tied to any specific vendor.
Clearly you don't feel the pressure of being tied to specific vendors and having to produce multiple binaries on a growing array of platforms both mobile and desktop, but others do, and this is mostly why they choose to use web tech on mobile or desktop. It's a very political and economic choice not one based on language syntax or capabilities alone, if you attempt to simply compare C and js on a technical level for example you will fail to understand why the choice is made. I fully expect that trend of web everywhere to increase if/when HTML starts offering more choice of languages (NaCl/asm.js) and perhaps more sophisticated layout (though for present uses it's not bad for that purpose). At that point, why choose a native API which will be deprecated in 5 years, when you can truly write once and run anywhere (web, mobile, desktop).
The people native apps benefit the most is OS vendors, because of lock-in, for both consumers and developers having a more open cross platform tech is clearly desirable (easy to switch platforms or for developers serve all platforms), even if not fully practical at present.
This comment would be spot on 2 years ago, but once you try libraries like Ractive or React, it's iOS/Android that begin to feel ancient. How do they not have data binding in 2014?
Also, having to maintain a separate codebase for each platform just seems inefficient. The solution doesn't have to be Javascript (could be C#), though Ractive and React make it surprisingly pleasant to write JS.
I use that term loosely to mean that my even-handlers only have to update the component's data, and the library takes care of updating the view.
That said, I've used Ractive for a while (on my own time), and haven't run into any issues. But I'm curious to know more and would like to try it out. Could you give me an example where data binding would cause errors?
I don't see what the problem is if people try to make things easier. As you said web stuff is easier to get into and development there is easier and this is a very good reason why apps should be easy to develop too. App should be as easy to develop as web apps and this is not a bad thing, people's time, energy, intellectual capacity will be saved.
Is this really where we're happy being as an industry? "Don't worry, since you've got the most powerful pocket computer ever shipped the scrolling is usually only mildly terrible."
But i installed the app on my nexus 5 and used it... It feels like i'm opening the browser. The app doesn't feel native. Input elements are weird. The dialog is weird. The animation is sluggish. And the spinner animation is moving in a weird fashion.
For a lot of apps thats allright. But if you want to create a killer app, please go native.
Yupp, it's sluggish but good enough for small time apps. Wait a few years for famo.us and others to work on the problem, and you will see hybrid killer apps.
My Nexus 5 is also sluggish in comparison to my iPhone. From the little research I did it has to do with the default webview used on Android. Hopefully this will also get better in future.
It's funny that the Genymotion screenshot clearly shows "for personal use" :)
The blog post says Genymotion "has a completely free option along with some paid options for larger groups of developers", which is a slightly different interpretation of what you can read on Genymotion website as the use cases there are divided between commercial and non-commercial.
Still a nice read, good luck to you!
You're not doing promises right however :) `$http.get()` etc returns a promise, so you can do all transforms and logic via `.then()`. The only time you should ever use `$q.defer()` is when you're wrapping a non-promise API. The bluebird library has a nice write-up: https://github.com/petkaantonov/bluebird/wiki/Promise-anti-p...
Promises are pretty great, too. I wrote some (now in production!) feature detection/facial recognition code using OpenCV through the node-opencv library, but as some of the big calls were async and I needed it to work in a somewhat synchronous way, I wrapped it all up in Q. Once you understand how they work, they can be quite great.
Just installed it and I think this is the perfect sweet spot for this kind of wrapped webapp. The app is simple (but useful) and still leverages native things like the select combo and date time pickers. The transitions between the two screens are smooth and the list scrolling feels great.
I suppose my only query is... why bother with ionic? This is such a simple application that it almost feels overkill, you could have used the cordova commandline tools along with libraries like iscroll and fastclick and you'd have had everything you've got here with less overhead...
I guess whilst using Cordova on it's own was also possible, it would, like you said, also involve including/setting up multiple libs. Ionic just sets you up with very solid boilerplate and then also comes boxed with awesome UI components. For us the slight overhead was definitely a good trade-off.
I wonder if Ionic Framework did remove the click-delay of +/- 300 ms for browser apps / sites. I tested a demo of the framework a while ago and the app just felt slow (perhaps because of the animation or what i thought was the delay on click).
It is removed. There are a number of browser quirks that Ionic handles so that all click events are handled accurately, and not just ones with an ng-click directive.
We just built a mostly done prototype of one of our products with Ionic in 4 weeks at my company, rewriting existing components to take advantage of Ionic. We ran into a bunch of Ionic bugs (on beta 13), and took a dive into integrating the beta 14 candidate with Angular 1.3 into the prototype (and came upon what looks like ng-animate bugs in 1.3) last night. We are also using CCA.
Ionic has pretty much been a joy to use, and fit exactly our requirements (we do hybrid web/mobile apps on my team, mobile being Android only since we do native iOS development). The article is pretty much on the mark, and you need to be careful when it comes to performance on mobile. Optimizing stuff like using the track by syntax with ng-repeat is vital. Taking advantage of Angular's superior testability and structure conducive for rapid app development (and having 3 Angular contributors on the team doesn't hurt) allowed us to build an impressive app very quickly, as well as avoid some of the nasty Ionic bugs we came upon (mostly related to their $viewHistory service and broken back button).
I haven't gotten to play around with the beta 14 candidate yet, but I was unhappy with how opinionated Ionic was when it came to the history and how it's expected that everything would inherit from a state with tabs.
I will say this though - if it wasn't for the decision to use Ionic, we would have been in a lot of pain trying to meet our deadlines trying to write a lot of this functionality from scratch, and we would not have had stuff like the native feel with the tapping & scrolling behavior that Ionic provides. Overall the Ionic team did a great job with the product, and I'm pretty happy with it.
I wanted to see how this app feels. Visiting the App Store, there is no app with this name. On my iPad, if I tap on your link, I am presented with (literally) a solid empty white square. Good job, Apple.
So FYI for everyone else not in the UK, this app is only available in the UK App Store. (But I had to fire up my Mac to find out.)
Thank you. I just installed it, took a quick look, and wouldn't have guessed this wasn't a native app. This is on an iPhone 4S. It seems like it's a little more obvious on Android devices from other comments but I was pleased with it. This definitely gives me some confidence in Ionic.
If there's any sort of app that works with this sort of thing, then yours is probably at the top of the list. The interface is super-simple, people are unlikely to use it often, and so on.
In this case, the cost of developing independent apps for Android and iOS (as well as other platforms, potentially) would probably be too high.
The experience wouldn't be suitable for anything used more intensely though, IMO. Scrolling on iOS is just "not right", in the sense that behaviour is different to native apps. Hover behaviour is different too, and some of the UI elements are also not quite correct (back button). Small things like that add up in a bigger app and cause a frustrating experience.
But it's definitely a good turn-around time, and FWIW I think you've made the right decision to take this approach.
And I have noticed them too, but I rarely ever cared. In fact, most people don't care, as long as it works, and it does. Another great example is Untappd, an app with millions of users and a 4.5 star rating on iOS.
Most of Netflix apps, including the iOS version, are not native. The Android Netflix app, however, is the exception, as that is native (perhaps that's the one you've been using?).
Are you a Netflix employee, by chance? A buddy of mine works there and told me that the only non-native app is Android, but he might be mistaken since he's only been there for a few months.
Also recommend to everyone who needs Cordova to look at AppGyver Steroids[1]. It's truly hybrid framework, though, still under active development. For example, Steroids has layers system, which basically consist of WebViews, but all transitions is native and Steroids gives you native controls such as NavigationBar and TabBar. I'm making an iOS app right now and I've got shared .styl, .jade templates and a bit of .js logic between web node.js and mobile app. From Ionic I use IonicIcons, and I love it.
In fairness, the comparison table pitting Eclipse against XCode should have included Android Studio, which (besides not being Eclipse) also includes a visual UI editor.
Just tested the app on my Samsung Galaxy S3. Seems to be working fine and the transition between results page back to search page is smooth.
The search form is offset to the right though where I suppose it should be centered. So the right side is touching the right edge of the phone while there is blank space on the left. It looks broken. Does anyone know what the problem is? These kind of issues are something I see frequently on mobile sites.
Mind me asking what version of android you're running? We've noticed this on a couple of android devices also, but not been able to pin down the problem.
Looks nice. I've been meaning to give Ionic a try, so nice to see you had a good experience with it. Did you check out Framework7? I've been using it with Cordova and it's provided a way to build cross-platform mobile interfaces quickly. It provide a native-feeling skin and interactions for your apps.
In your screenshot of the "Airport Parking Shop" in the Browser, besides the developer tools, the app itself is wrapped in a GUI that I have not seen before.
First I thought it was an ionic served GUI but I couldn't find it when trying out the Tab App example. Could you elaborate more on which tools you used for testing in the browser?
I've had a horrible first impression of Ionic just a week or so ago.
Like Cordova, Ionic can generate a "hello world" app for you. It served just fine on the browser but would not load on neither the emulator or my phone.
It is in alpha/beta so I guess I'll cut it some slack and try it once more in the future.
Ionic just provides a bunch of really useful components (angular directives) that's already hooked up and ready to use. This not only saves time developing, but testing as well. Also, comparing the Ionic components to jQuery mobile is not really fair. jQuery mobile is quite horrid in my opinion..
I guess it is good decision when the developers have a web background, but there are lots of options for developing native applications across mobile OS.
From my point of view, in Google Play the trade-off is you get fast updates but you can lose your app and reputation permanently overnight. I see algorithmic solutions are best for Google for most of the time. But as a developer in this case, I feel we are business partners with Google also helping them earn money. But when you are treated with robots without common sense, without human-reasonable answers. It takes your enthusiasm away. I agree with you that waiting one week is a problem. However Google Play's solution isn't that nice if you get bitten.
You built an app in two weeks that looks and feels like a hybrid app. Your app has 2 pages and a web browser for "Partner" sites. This app could have been built natively in 1 day each for iOS and Android, and then you would have native apps.
We only had a single dev working on the app, but our team of 5 helped out with designs, backend support etc. Already having the comparison API in place did help a lot.
The improvement doesn't necessarily come from the cordova side of things. That's still all the same old webview that gets wrapped up. The real difference is achieved with everything else that gets used to build the app. The Ionic framework avoids DOM manipulation where possible and enables hardware accelerated animations. Both these things is possible on top of plain cordova, but Ionic makes it so much easier and they have already done the hard work of figuring out what is going to perform best inside that cordova wrapped webview.
Any particular reason you dislike Angular? Have to say since I've been building with angular, I try and avoid jquery and any direct dom references completely. Think angular is fantastic.
I think AngularJS is too much effort to build the simplest things. I don't even see the benefit at all. I build all of my javascript apps (I hate using the word front-end apps) using jQuery and Flask backend. I don't even use asynchronous . I just don't see the point.
What's missing from jQuery that limits you but does not in AngularJS?
What's missing from Flask that limits you but does not in Node.js?
However if you use famo.us' list view scrolling is nearly as fast and smooth as native code on iPhone 4. On newer phones to difference between hybrid apps and native is unnoticeable. At the moment famo.us only has low level components, like boxes with html content. Standard back buttons, chevrons, tabs, action sheets and icons has to be imported from elsewhere. Famo.us only does fast bouncy animations, touch events and 3d effects. Besides famo.us is working on their phonegap/cordova alternative wrapper.
A combination of Ionics ease of use and famo.us' impressive speed would have been great. There's lot of promising little open source projects on github that either extends famo.us or integrates it with javascript MVC libraries.
I believe Brendan Eich was right when he said "Always bet on JS!". I bet mobile app development is going to be dominated by JavaScript and HTML.