The Official Ionic Blog

Build amazing native and progressive web apps with HTML5

When we started planning to build what soon became Ionic, we knew that we needed to take a native-focused approach to building the next great HTML5 development framework.

We felt that there were plenty of web-focused HTML5 frameworks, but few that treated HTML5 as a first-class citizen in the app store. We couldn’t ignore that people increasingly look to the app store to find apps, rather than browse the web for them.

One big difference that kept coming up between web apps and native apps is how they handle URLs. Web apps utilize URLs both for the developer’s convenience but also for the user’s, allowing people all over the world to link directly to content and using them to delineate parts of a user interface. Native apps, in comparison, don’t use URLs for UI interactions, or use them only under the hood for the developer’s convenience.

In a native app, a user will never see any URLs even if the app is using URL based routing underneath. Obviously there are no URL bars or browser chrome in a native app so having URLs doesn’t make sense. When used, it’s merely a convenient way to manage UI state for the developer.

Yet most current HTML5 development frameworks have kept URLs as a core concept, limiting a lot of UI interaction to those that can triggered through an anchor like . Things like switching to a new page, popping up a dialog box, or linking tabs. It’s probably out of developer comfort, but also because the history of HTML5 and web technology is rooted in the browser app. But even then, URLs were meant to link to specific resources on the web, not to control user interface interactions.

If you are familiar with native app development, you’ll know that native apps tend to utilize a lower level design pattern called theView Controller pattern (ignore the Model portion for now). The idea is pretty simple: you have a set of views (think of them as boxes or rectangles where UI elements are drawn), and then controllers that manage multiple views in tandem.

The UITabBarController on iOS is a perfect example of this. It takes a set of child controllers which each have their own set of views that make up each “page” in the tabs, and manages tabbing between them:

UITabController
(don’t forget to drink your vitamins, all day every day)

In the screenshot of the iOS Alarm app above, you’ll notice four tab buttons with four possible pages of the tab you can select. We are currently on the “Alarm” tab. The UITabBarController holds a reference to the UITabBar view at the bottom (it even creates it for you), and then when a tab is selected, the controller makes sure to switch the pages for you.

In a Web App, you might have a distinct URL for each page in the tab. That wouldn’t be the worst thing in the world for a hybrid/native app, but it soon breaks down when we look at more complicated native apps. For example, the great Yahoo! Weather app:

Yahoo! Weather

If you haven’t used the Yahoo Weather app before (highly recommended), it features one single pane that scrolls up displaying a variety of weather information. The user can also swipe in between each city they’ve added, showing weather for that city:

Yahoo! Weather Cities

Imagine trying to model this drag animation using a URL-to-City approach in a back or frontend framework that uses route based navigation. Let’s say the first page is /cities/current and the second page is /cities/Madison-WI. When the user starts dragging to the next page, what happens? Do we navigate to /cities/Madison-WI, or do we wait until they complete the drag? If the routing system uses the URL state to know when to render each page, then we are stuck trying to hack around the router.

Instead of being a convenience, URL-based routing becomes an artistic restriction.

Ionic: Native Applied to Web, And Back Again

To native developers, this all might seem like a pedantic exercise, but for web developers moving to native development, it is often quite a change to not use URLs for common UI interactions. We don’t just link to different pages using , we use more subtle tools often powered by touch, letting the user treat our app as an open canvas.

With Ionic, we wanted to apply these native design patterns to web development. And in doing so, we realized something really exciting: HTML5 was just as powerful and flexible as native development. But better still, it had some major benefits over native: it was faster to build in, easier to port across platforms, and known by a lot more developers.

We realized that if we could build an HTML5 framework that loved native design concepts instead of avoiding them, we could enable developers to build any kind of app they dreamed up, not just ones that worked with the URL pattern.

So we decided to apply the View Controller pattern to a lot of the ways developers build UI interactions in Ionic. If you are a web developer that hasn’t had much experience with native development, it will probably feel a bit strange at first. We are confident that once you see what is possible when you free yourself from the URL, you’ll feel quite empowered to build great apps in HTML5.

  • Felipe Mendez

    like the jquery mobile way of handling links , but how to handle what i’ve learn with nodejs routes… i get the overall idea but i still can’t figure out the way of routing this complex javascript apps.

    • yesimahuman

      The jQM way is definitely convenient and good for web apps, but we are back to having to define each page of the app as something we can link to, and we are stuck in very rigid definitions of a “view” as something that a URL can identify.

      For many use cases, it’s not a big deal. It starts to become more limiting when we want to build more interesting UI interactions that are non-linear. When the framework treats everything as a navigable resource, it’s hard to really break out of that.

  • Roei Wagner

    When using the URL navigation approach, the android back
    button work as expected.

    How Ionic going to deal with android back button?

    • yesimahuman

      Hey Roei,

      The back button event is trivial to listen for, so our navigation controllers and such will handle it properly. In fact, I’m testing that right as we speak πŸ™‚

  • Perry Govier

    sounds pretty angular-ey πŸ˜‰

  • nicolasca

    Thanks for this interesting article.

    I have a question about that. URL navigation can be convenient for REST API.
    Will it be possible to automate REST resources call (like Restangular does)?
    Thanks

    • yesimahuman

      Of course. URLs are still a huge part of the data service layer, and we encourage their use. This is more for defining the UI and UI interactions, which we believe are better approached using the View Controller pattern.

  • Roei Wagner

    I can’t wait to start using Ionic, any estimate when you release
    it?

    • yesimahuman

      It will be November for sure. We are two weeks out, but it’ll be worth it. We are making sure on day one we have great documentation and a guide to help walk you through building something real.

  • Gregory Pratt

    Are you talking about something similar to this? https://github.com/angular-ui/ui-router

    As a web developer who loves PhoneGap and uses AngularJS with it, this framework sounds like an excellent approach to realising the HTML5 potentials. No URLs though will take a bit of getting used to!!

    • yesimahuman

      Hey Gregory. The idea is that you can absolutely use tools like ui-router if you want. The framework has a few built in View Controllers that do not rely on URLs for routing, but there is nothing stopping you from building your own that uses something like that.

      This is a very native approach, where the building blocks are there if you want to use them as-is, but many people subclass them and build their own functionality (not necessary at all, of course).

      So it’s not that we don’t use URLs, but that we don’t require you to use URL based routing for views, which can be overly restrictive when you want to build a very interactive app.

  • powdernine

    Nice article Max. I understand the idea that you don’t need URLs to build hybrid apps but I think URLs can be pretty darn useful and shouldn’t be immediately discounted. URLs (uniform resource locators) don’t have to be used for navigation but can be used by your app to locate resources, which could be other views, partial views, code, css, etc. either locally to the app or external. In small apps with few views/view elements there isn’t much value but when you get into large apps, especially line of business apps, you need to organize things and URLs are a great way to do that. If you find that URLs are in some way restricting the UI you want to build then don’t use them for that component. You don’t need to use them for everything. Finally, you are correct that the user never sees URLs but they don’t see a lot of things and I think developer convenience and maintainability are great reasons to use URLs in your hybrid apps.

    I’m looking forward to checking out ionic when it is released.

    • yesimahuman

      Yep! URLs are hugely useful for resource loading, and we use them often in Ionic for loading templates and other things. It’s more for the UI. The web has this URL -> page history, and when you start to pull in animations, dragging, and other gestures, it’s a very brittle way to model the UI.

      So all we are saying is Ionic will not restrict you to URL routing, but does use URLs for other things and will let you use URL routing easily if you’d like.

  • http://monokromatic.blogspot.com monokrome

    This article doesn’t really suggest anything. It mentions that the person has apparently learned to use controllers in a useful way, but doesn’t get into detail. The generic description as provided seems like how most JavaScript-oriented frameworks’ controllers work, anyway.

    However, it also tries to tie URLs into the argument while not really explaining why they are necessarily a “bad idea” for native apps. It should also be noted that URLs are very much specific to the use case. For instance, here are some properly formatted URLs that might not fit into the generic HTTP-style URL format that I feel has been implied by the article:

    postgres://username:[email protected]/database
    git://github.com:monokrome/monokro.me.git
    file:///home/monokrome/my_project.git
    skype:brandon-stoner

    These are all valid URLs that should be able to be passed through any decent URL parser. If your URL parser can’t parse one properly, it doesn’t understand how URLs work. You can leverage these types of URLs in better ways for your native apps, and you can express your application in more ways than are immediately obvious.

    URLs are good at providing a means of describing the location of a specific resource, as well as describing preferences/filters/etc on those resources – so, it’s usually more of a problem of not understanding the expected semantic usage of the URL more than it is a problem of URLs not being “the right thing”.

    If you want something that describes a specific resource in your app, and you want to be able to share it with people easily – I’d be happy to see something that does it in a way that is as powerful as current URLs are. However, I doubt that’s as easy said as it is done – because URLs solve this problem with a certain elegance.

    As for suggesting that frameworks are blocking your creating freedom by relying on changing application state with URLs, I don’t agree there either. Yes, URLs offer decent creative freedom. More importantly, however, URLs should never even be used to navigate around in a page. You should only use them to restore application state – and (at least) Backbone.JS completely supports this use-case. Any framework that doesn’t has major problems that make it’s usefulness very debatable. You have to explicitly provide { trigger: true } to trigger routing in Backbone, because it’s a bad practice to get yourself into.

    Overall, this article is suggesting a lot of problems that aren’t really problems at all. I hope that nobody gets too caught up in trying to solve them, because it’d be a lot of wasted time to finally figure out that it always worked well in the first place.

    TL;DR – What is this person even talking about?…

    • yesimahuman

      So since I posted this I realized I need to go back and make some tweaks, as my point wasn’t really coming across. Lesson learned.

      It’s not about avoiding URLs. Obviously they are how you interact with resources (HTTP or otherwise) and they are used in a lot of different places. They are crucial and we all love them.

      The point was more that, as web developers, we have been trained to build our applications as if they were running on a server or in a browser, using traditional URL links to move through different parts of the UI. Relying on things like the back button to go back in state.

      Since we are trying to get more web developers to start thinking natively, one of the biggest changes is using the lower-level View Controller concepts instead of just linking everything up with a URL. Believe it not but it’s actually a hang up web developers have when moving to native development.

      It might be a minor detail but Ionic will be a change from web based frameworks like jQuery Mobile or jQTouch where you use URLs to trigger transitions between pages, among other things. We are merely trying to set our future users up for the change in approach.

      • http://monokromatic.blogspot.com monokrome

        There is definitely a lot of truth to that. Developers seem to be stuck relying on URLs to do more than just save/restore application state in a shareable way.

        Many frameworks (including Backbone) make it harder to design your application around URLs, but developers are stuck in their habits and have a hard time moving toward a way of navigating around in browsers without using the normal means of navigation (IE, URLs) and it’s definitely a problem that should be solved sooner than later.

        The real problem is that it’s hard to solve issues where developers are stuck in their ways, and this is completely a developer issue at this point in most cases. Frameworks like BackboneJS make it harder to design apps around URLs, yet we still see developers doing it much too often.

  • lung220

    In the example of Yahoo Weather, the transition and animation would still work even with HTML5 push state. The difference is that the transition becomes atomic, which means user cannot drag half-way but then revert to the original city. Once the user starts swiping, it has to go to another city, and the URL would update after the switch is completed. This can be done using a simple `defer` and `promise` technique.