Hacker News new | comments | show | ask | jobs | submit login
Ionic – A front-end framework for developing hybrid mobile apps in HTML5 (ionicframework.com)
178 points by ds_ on Nov 22, 2013 | hide | past | web | favorite | 88 comments

Listen -- I know there's a lot of negativity on HN and I try not to add to it. But seeing mobile web succeed is something I'm pretty passionate about.

I played with the left nav example and it doesn't use inertia. This is one of the most ubiquitous interactions on mobile apps so it's probably one of the most important to get right. And while it's good by mobile web standards, the lack of inertia makes it feel completely and obviously wrong if you're comparing to native apps.

The lack of inertia is indicative of either not setting the bar high enough or not having the technical chops to implement it.

The reason this is a big deal is because mobile web's reputation is to cut corners like this and get 80% of the way there and then give up. That's why native is kicking mobile web's ass.

The worst part about this is the web can do a lot of this (for example, see the leftnav I built here http://petehunt.github.io/react-touch/), it's just that very few teams are doing it right (Sencha is one team doing it right). So the reason this post upsets me is because they call themselves a premier way to build native-like apps with web technologies and then just further the stereotype that web technologies can't compete. It really bugs me.

Your argument about the left nav seems wrong to me. I use the HipChat app on Android and iOS and it feels just like ours does. I've never used a left menu that had the effect your demo has. In fact, I know we are using inertia because you can "throw" the menu over to the side, and I coded it based on a velocity threshold of the drag (we just aren't bouncing at the end, which is really not a universal style). Perhaps you are noticing a browser/platform specific issue we can fix?

I think your comment is a bit harsh, especially considering we've been working on this for all of two months and it's still in alpha. We have a long ways to go and we know it can and should be better. If you believe in the vision of making this the best way to build hybrid apps, then help us! https://github.com/driftyco/ionic

By the way, I did find your demo quite impressive. Nice work.

I've just used a bunch of iOS apps that have that effect and I've found that inertia is present in way more interactions than are immediately apparent. Zynga Scroller is a pretty good (pure math!) implementation of it.

Sorry that I was so harsh. I think the marketing copy turned me off a little bit. If this were presented a little less like "here is _the_ solution!" (when so many others have come before it) I would have been less of a jerk :/

I think what frustrated me is that you guys seem to have the right attitude and design to pull it off and I felt like the interactions weren't quite there. So please don't settle for anything less than perfect, no matter what it takes :)

I do want to point out that your design is great and the interactions are a lot better than most of the web stuff that's out there. And it looks like you've spent a lot of time working on developer experience which is great too; impressive for only working on it for two months :)

Sure, we could probably tone the copy down a bit :) If you don't mind, I'm going to see about getting some of the stuff in your demo into Ionic, that'd be cool.

You may find yourself switching to React if you do :) Also I wrote a blog about the frosted glass stuff: https://medium.com/p/87ce4a41019f

If there is one area that I've never been able to understand about Web Developers is the endless pursuit of making web "win" over native, you allude to it with your comment "That's why native is kicking mobile web's ass". Who cares? use the correct tool for the job, you don't see websites modern being written in Objective C and I can't remember meeting a mobile developer who was preoccupied with beating "web" tech.

/me - Runs and ducks as all the WebDevs throw fireballs my way.

Well I think that incremental delivery of applications, crawlability, URL bookmarkability and being able to push live updates are valuable features the Web has already solved. In general iteration speed in dev is better too (usually lower compilation times)

Don't forget the cost of managing multiple platforms and not having to have multiple dev teams. On the teams I've worked with that has been the reason for going with html5 apps.

How many businesses want to build the same product 3 times (at least) for different customers and will they be able to get it all implemented at the same time, or try to manage the differences when they are all communicating with the same backend service?

It's just a non-starter for most start-ups or non-technology focused businesses.

That depends on the "complexity" of their product.

For some viable is creating it in three different format.

> Native focused

How is it native focused? it's obviously an HTML/CSS/Javascript framework. It's not native to the plateform itself, since you are developping in a webview.

> the most advanced HTML5 mobile app framework - launched

it's basically some kind of Bootstrap + angularjs bundle. How is it more advanced than Sencha Touch for instance?

It's native focused in the sense that it's not meant for building mobile web apps. You are building apps to run in the app store with Ionic. Also, we are working on "native style" UI interactions that might not fit in a mobile web app.

Sencha Touch is great, but Ionic has a permissive license with an open source spirit. Sencha's open source version is only for open source apps compatible with the GPL, which is a big restriction. And, you can actually submit pull requests and contribute to Ionic. Plus the development model of Sencha isn't markup based, and doesn't use Angular.

If you are happy with Sencha, by all means, keep using it. We are ambitious and will be working hard to make sure Ionic is better than Sencha in most ways :)

I can wrap any HTML/CSS/JS framework into a native wrapper. That doesn't make it "native focused". All my apps are currently built with Phonegap and a heavily customized jQuery Mobile, then wrapped, compiled, and deployed.

Sure. We are actually focusing on providing a native-style programming model though: http://ionicframework.com/docs/angularjs/views/modal/

In this sense, "native focused" is not about what it does do, but what it doesn't do:

- It probably doesn't work in IE or Firefox, because it's focused on working inside embedded WebKit/Blink.

- It probably isn't appropriate for a "responsive" or "progressive enhancement" situation, because it's assuming it'll be in an embedded browser, on a known device, with js on.

I had expected the same, but in clicking around I noticed some code handling IE8 quirks.

You are right. This has nothing to do with native apps. It is just a css/js framework mostly leaning on angular.

When you see the word native, you expect native code. According to this framework, I can call any responsive site native.

you can write an OS in HTML5 and be native.

"Developping native mobile app in HTML 5" seems like something that would confuse a lot of people knowing technologies such as Titanium.

if i understood correctly, ionic is about "developping native looking mobile apps in HTML 5 / CSS". You don't create native UITableView using javascript calls forwarded to Objective-C Code, do you ?

I'm honestly not sure which word to be using, hybrid or native? I don't like hybrid because once the app is shipped, it's a native app and the user hopefully won't care or know which is which. Just because it's using one level higher of abstraction (i.e. only the web view for now), doesn't mean it's not a native app.

Hybrid is the generally agreed upon term for running a local app in a webview. A native HTML5 app would be something like a Win8 app using WinJS where HTML5 is a fully supported runtime.

I'd say you are for developing "Hybrid apps that look and feel completely native"

You might not like "hybrid" but it is, by definition, what you've built.

Agreed. We are tweaking the terms around.

In my book 'native' isn't clear cut but a mixture of 'able to interact with the operating system / hardware and not running through an extra virtual machine layer'. I can't quite reconcile that with JavaScript. I did look in the docs but they don't make much further mention of it.

JS compiles at runtime (or JIT), C++ compiles at build time. What's the big difference? Real hackers code nothing but ASM.

I'm not saying one is better than the other.

But I would say the main difference is OS APIs. Ability to manage memory, interact with filesystem objects etc.

That's one of the main reason for using web apps. I can trust them totally, because they're so sandboxed! They can't even read or write to filesystems!

But we as devs do care.

What do you recommend then? I'm happy to change it. I'm just not sure "hybrid" is clear that this is for building cordova/phonegap style apps, not for building mobile websites.

I don't understand where there is confusion:

mobile website = run in mobile safari, assets loaded over http

hybrid app = run in a webview, most assets stored locally, some data optionally loaded over http

native app = written in the officially supported language of the platform

Well, what was Facebook back when it used HTML5 in the news feed? The lines are blurring quite a bit. Just because you are abstracting one part of the app to the browser runtime (that can still easily access the native layer) doesn't change the fact that you are shipping a native binary at the end of the day. We have decided to go with Hybrid since it is causing confusion, but I disagree it's so cut and dry.

A quick perusal of the comments here makes me think that the issue is more cut and dried than you'd like it to be.

What _should_ the terms mean is a very different question than what _do_ the terms mean.

As far as end users are concerned there are only two categories: native and mobile websites (though they're more likely to describe them as "apps" and "websites"). Hybrid is a term used by developers to communicate a particular technology stack, it is a subset of end-user native.

Don't get me wrong, I agree with you. which is why we are making the change. I'm merely throwing out the other question because I find it interesting.

You could use a phrase instead of a word: "HTML5 bundled as native"

Woke up to see my project here on HN, cool :)

We just released the alpha, and there are some really important things on our roadmap for the next few weeks: Android performance, list virtualization (for huge lists), better scroll performance, and fixing bugs. Right now Ionic projects feel best on iOS but we want to change that.

Let us know what you think as we work on the beta!

Out of curiosity why not use standard scrolling on iOS?

We do support it, you can set overflow-scroll="true" on a content area to use it(http://ionicframework.com/docs/angularjs/views/content/)

But -webkit-overflow-scrolling: touch has some limitations. For one, you don't receive scroll events after a flick when the finger has left the screen. There are also some very strange issues in the mobile browsers with it, it's a buggy solution right now.

In order to build some of the more interesting UI things like pull to refresh, and then list virtualization (i.e. only rendering the active subset), it made sense to have more control over the scrolling operation.

But that was a decision I made a few weeks back so I might be wrong, and I would love to use the browser scrolling if possible.

Using custom scrolling behaviour makes the lists feel very out of place on android where a end of list bounce is not the correct visual cue

Yea, I'm thinking we will apply a platform-specific rule to those certain components, because I agree with you. One Android-specific thing we added was left-aligned header bars, but it's only a start. Android support is probably 70% of the iOS support right now, just given time constraints for the alpha.

I'm building a hybrid app right now. I can't see Angular and all its magic being a good fit. The provided browser controls in smart devices have horrible performance and are often several releases behind. Most are deceived thinking that a hybrid app that works well in a desktop browser will perform as well on smart devices. You will be disappointed. FWIW, I settled on Intel's App Framework after trying several popular frameworks.

As a side note, I'm surprised by how poor hybrid apps perform on Android. You would think Google of all companies would be pushing browser based technologies further.

First of all, thanks for this @yesiamhuman, I came across it a few days ago just when I was despairing of finding something with the right look and feel (somebody mentioned it in an earlier HN item about a curated list of CSS frameworks). It looks like it's exactly what I need.

For the project I have in mind, the client wants an HTML5 web app, not an App Store delivered container. On the docs, you state:

"Since mobile browsers often exhibit issues while in browsing mode that don't show while running under a "wrapped" native app, we recommend running all Ionic examples in a Desktop browser, PhoneGap or another native wrapper."

Can you elaborate on this a bit? What issues am I likely to see if I just deliver my project as an offline capable single page web app?

You know, it should actually work fine. We wrote that when we started the project but we've shifted our opinion a bit. One issue is that we have bad support for non-webkit browsers since we've focused on iOS and Android to start. But we'd love some cross-browser testing :)

Great, that's what I was hoping. The client is planning to stick with iOS devices so I may not test much cross-browser, but it's good to know we'll have options. Again, thanks for this and I hope I can find a way to contribute. I'm sure I'll have a few other questions, I just signed up over at your forum.

They're likely referencing mobile Chrome's habit of resizing text in unexpected ways. (You can really see this on HN, sometimes.)

The edge swipe gesture cramps my style in the browser itself.

Looks interesting, but it's not for me. My customers are not all using the latest and greatest.

"Our compatibility starts at iOS 6 and Android 4.2. We will never support devices older than this."

We made the tough decision to only support newer devices. We know it's not going to work for everyone, but the reality is that HTML5 animations and touch interactions don't feel good enough on old devices. We really wanted to make a framework that was looking towards the future, starting to take advantage of the increased power in newer devices.

There are a lot of good solutions out there that have better older device compatibility, like jQuery Mobile, which are probably a better fit if you need to support them.

While I agree with the decision to support iOS 6 and up, I believe Android upgrade paths aren't as clear cut. I'm working on a project with China-designed phones and many of them are using older versions of Android as a point of product differentiation.

Hope it's something you guys will reconsider.

Comment on the design of the homepage, there is nothing to visually draw the user's attention to content below the fold. When I loaded this page, it happened to be in a window at a perfect size to hide your overview content. I clicked around on a few pages before realizing it was on the homepage.


Looks awesome! I'm a huge angular fan and have been researching a bunch of frameworks and SaaS solutions for doing a mobile "app" so this should be awesome to get my feet wet!

Time for a weekend to-do app, because we don't have enough of them eh? :}

Some layout issues with Firefox for Android: https://www.dropbox.com/s/4q1svdsaqbqwkuc/Screenshot_2013-11...

Thanks. Our Firefox support isn't great at the moment. Also, we don't intend Ionic apps to be run in mobile browsers, but rather native UIWebView type shells. We are looking into support Firefox OS, though.

This kind of thing ought to be splendid on FirefoxOS, but the examples are disappointing at the moment.

For instance, it doesn't seem to be possible to interact with the side-menus example at all; and in the nav bars and tabs example, after tapping on the cat link, I could find no way to go back again (apart from through the browser back button, which wouldn't be present in an app view).

(This is with FirefoxOS 1.2, which runs things like the Twitter mobile HTML app quite well. Worth testing if you can get access to a FirefoxOS device, it'd be great to see this working well on it.)

I'm in touch with someone from Mozilla, hoping to get some support with making it work on Firefox OS. Just curious, are you using the ZTE?

No, I have a Keon, but the ZTE Open is very similar. They both have low-resolution screens (same as non-retina iPhones) which can cause trouble too. They are quite good lowest-common-denominator test devices, not so good as primary smartphones, though I'm kind of fond of mine.

I must say I find it a bit problematic, philosophically, that an HTML5 app toolkit should be designed for a single platform and should have to be "ported" to new ones. What about it is so platform-specific?

It's really that when we went to do things like animations and using some newer browser features, we threw in the -webkit prefixes and didn't test in a gecko browser. We were expecting to only stay on Android and iOS but we quickly realized we wanted to do more.


Also layout issues along with not being able to click on the examples link on this page. Wasn't able to actually use the examples. Android 4.4 (N4), aosp browser.


> How it can be easier, awesome and simple for serious development?

It probably can't, depending on your definition of _serious_, but for 90% of the apps being built, this is perfectly suitable.

Regarding the app store, I see now reason why this wouldn't pass Apple critique -- they've been accepting Cordova-based applications often and for some time now.

As for what it offers, cross-platform publishing is a pretty big win for a bevy of developers that don't see the point in writing separate native apps for applications where native performance isn't terribly necessary.

My experience with Appgyver Steroids has been impressive. Performance is very good. Whether or not it could have been faster written natively vs. being compiled to native code is not substantially worth considering -- it's fast enough, by a large margin.

I would say reaching 90%+ of apps means it can be used for serious apps :)

If you have the budget to build an incredibly detailed native app on all platforms, then Ionic really isn't for you. We are okay with that, you aren't the target user.

Also, PhoneGap/Cordova is really just a thin layer between a web view and the native platform. You can really send and receive any kind of data between it, which means you can do anything native that you want. The thing people get hung up on is that Cordova ships a designed API that does not give you as much control, but it's only a plugin away (something we want to build more of).

How easy would it be to port a quite complex app from AngularJS/Bootstrap to Ionic and would it make sense?

Well if you are using ngRoute with ng-view, it's easy to add in the nav bar animations and nav stack stuff: http://ionicframework.com/docs/angularjs/controllers/nav-rou...

Otherwise, it should be easy depending on what your layout is. I'd be happy to talk more about it on the forum or feel free to email me.

Sorry to be a jerk, but just want it to look as good as possible...there is a typo up at the beginning of the lede copy:

Free and open source, Ionic offers a library of mobile-___optmizied___ HTML, CSS and JS components for building highly interactive apps. Built with Sass and optimized for AngularJS.

:derp: fixed, thanks

How does Ionic relate to different screen sizes, orientations and resolutions? Would responsive layouts be viable or is that out of the scope? The way I see it now is that it is targeted at phones and not so much at tablets.

BTW, the word 'which' is in the wrong place on the components page: "The advantage here is that the devices Ionic which supports, all support flexbox."

BTW2: in the Getting Started guide, chapters 4 and 5 have no link to the next chapter at the bottom.

>Performance obsessed

>zero jQuery

Perhaps I've not been keeping up with the latest JavaScript news but is jQuery considered slow? jQuery 2 is a lot lighter and works well on mobiles.

As a funny relevant aside http://vanilla-js.com/

It sometimes work well on mobile. I think the best approach is to build it in jQuery, if it doesn't perform well, figure out what's slow and replace it with pure DOM.

This generally results in replacing some jQuery calls in methods that get called a lot, e.g. touchmove, requestAnimationFrame, etc.

Well, according to small tests, jquery's selectors are slower than the 'native' selectors; findElementById for example is at least twice as fast as jquery's $('#someId') call. But that's because jquery has to parse the query first.

It's a productivity versus performance thing, really. Native JS is often faster than the same thing in jquery.

You could still include jQuery in your app if you wanted to. However, the Ionic framework itself does not run on top of that extra layer, especially when native javascript and hardware accelerated CSS transitions will be faster.

Angular people try to avoid the extra dependency whenever possible, as most things can be accomplished with jqLite. Beginners often use jQuery when there is a 'more angular way'.

Non-developer here. Can someone explain how this compares to something like Titanium and what benefits it provides over other HTML5 Mobile Frameworks?

From my quick review, Ionic is a framework for building mobile applications using web standard technologies (HTML5/JS/CSS). You then build your application using PhoneGap -- which builds a native mobile application wrapped in a WebView. This would be similar to writing a web app using jQuery Mobile and building a mobile app using PhoneGap. Ionic gives you a nice starting point, just like when you use Bootstrap for a website instead of writing all of your styles from scratch.

Titanium apps are written in JavaScript (using Titanium libraries) that hook into native functionality. Your apps are then compiled into fully native mobile applications (not WebViews). It really comes down to the differences between running fully native apps vs. web views wrapped in a native application. There is a good explanation of the differences between here: http://stackoverflow.com/questions/17249500/xamarin-2-0-vs-a....

For web developers, Titanium won't exercise your existing knowledge base. The license is also not as clearly open source and free to use as Ionic, even for commercial apps. In terms of comparing to other frameworks, we have a lot of mobile-specific UI interactions that most others don't, like draggable side menus, pull to refresh, etc.

Good point about the licensing models. That is a very big difference as well.

Blog post: Where does the Ionic Framework fit in?


Is there like a demo app that we can try/download?

I was wondering myself. What could be better for selling a framework than a well-done advanced demo app in all major app stores?

We are working on it!

I was about to ask the same question, great to hear that it's being worked on. Also good job on the documentation, clean and well organized.

I think it's cool and could be usefull. I'll try in my next project. Thank you.)

I'm attaining all of the goals of this library with MOAI right now, still going strong .. funny thing is, it does require platform competence, but if you get your own VM and frameworks going, suddenly everything is a target.

Ionic is modeled off of popular native mobile development SDKs, making it easy to understand for anyone that has built a native app for iOS or Android

Surely that's the wrong way around?

Looks great, I'm excited to try it out on my next project.

Question - what does one gain from using this over raw Angular itself, or something like Yeoman for generating a scaffold?

Well, you don't get any UI stuff if you just use raw Angular. Ionic has a lot of interactive UI elements that come with it, like side menus, gesture support, tab bars, nav bars, etc: http://ionicframework.com/docs/angularjs/

An easy answer are the components which are already built for mobile: http://ionicframework.com/docs/components/

And if you're already familiar with Angular you'll see that Ionic gives you a big step forward in your development, and you still have all the power your looking for in writing your own from scratch.

The pets sample doesn't render on Windows Phone. I get a blank screen and only the home icon shows up.

Your examples are ugly and most of the options don't have animations.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact