Migrating from jQueryMobile to OnsenUI

Does anyone have steps or pointers on migrating from jQueryMobile 1.4.5 to OnsenUI?

I see that main difference is that jQueryMobile loads the entire DOM and all pages at once thus making making interaction simple and it is easy to set value of any element on any page without pushing pages on the stack as with OnsenUI which uses templates.
Hence, my issue was passing values to other pages the first time they are pushed in OnsenUI.

So, how is that exactly coded and what methods/events to use?

Once the pages are pushed, would the elements value persist unless page is popped?

Since all pages are not loaded at once, does that mean, OnsenUI is faster than jQueryMobile?

@jamal All depends on the components you use. If you use ons-navigator to have a page stack, then you can call myNavigator.pushPage('pageName.html', { data: { ... } }) to pass custom data to the new page. Then you can use that data in the init event of the page. The data will persist until the page is popped, yes. There are also hide and destroy page events that let you save data before it’s removed. For more info, have a look at the guide.
I’m not sure about the last one since I don’t know the possibilities that JQM offers on this topic, but Onsen UI only creates pages on demand so I guess it’s faster than loading everything at the beginning.

@Fran-Diox, thanks for the info. Based on the guide, the closest component to jQueryMobile page strucure is <ons-tabbar>, so I intially hide tabbar, then show each tab on demand.
You now have setActiveTab(index) and requires a 0 based numeric value; can you also implement setActiveTabByID(ID), so it takes the string tab ID.

@jamal I think having more than one method to do the same thing (set active tab) would be confusing, and so far you are the first user who needs pushing tabs by ID instead of by index. Also, IDs can be repeated in the DOM if you push the same tabbar page twice, so it could lead to unexpected errors. Also, to be consistent we’d need to implement an initial-id attribute (like initial-index) and so on. Having a custom function like this is easy enough for those who really want to use IDs so I think there’s no need to change Onsen UI.

@Fran-Diox, I need to use IDs instead of index because it is easier to maintain. I am trying to mimic jQueryMobile.
Let’s say I switch tabs or change the order of the tabs within a tabbar, then indexes would change which leads to issues where the wrong tab may be displayed, but if I use an tab ID, then it does not matter if I move tabs around. If course I will have not duplicate tab IDs but have unique IDs. In jQueryMobile pages must have unique IDs and I am trying to have my transition to Onsen.UI as smooth as possible by using tabs as ‘pages’.

Anyway, I updated the custom function to the following which does what I want and there is no need to extend the OnsenUI: