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.
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.
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 :)
/me - Runs and ducks as all the WebDevs throw fireballs my way.
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.
For some viable is creating it in three different format.
> 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?
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 :)
- 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.
When you see the word native, you expect native code. According to this framework, I can call any responsive site native.
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.
But I would say the main difference is OS APIs. Ability to manage memory, interact with filesystem objects etc.
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
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.
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!
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.
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.
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?
"Our compatibility starts at iOS 6 and Android 4.2. We will never support devices older than this."
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.
Hope it's something you guys will reconsider.
Time for a weekend to-do app, because we don't have enough of them eh? :}
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 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?
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.
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.
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).
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.
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.
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.
This generally results in replacing some jQuery calls in methods that get called a lot, e.g. touchmove, requestAnimationFrame, etc.
It's a productivity versus performance thing, really. Native JS is often faster than the same thing in jquery.
Surely that's the wrong way around?
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.