This guide's main goal is to help developers to switch from iUI to Emy. It will show and explain the main differences between those two libraries. If you've never heard or used iUI before, it's really not necessary for you to read this, the Getting started guide might be a lot more interesting.
Since late 2009, i did contribute to iUI in many ways: themes, plugins, bugfixes, design & development of its website, documentation, ... but every time, for each single step, i did face some resistance to bring some new ideas & improvements to iUI's main core files (v0.5 was pushed to discuss more than a year before 0.4.3 finally got the new official latest release). Don't get me wrong, I have no anger about that neither personal recognition issue of any kind, this is a very common problem with OSS projects: asking or waiting for too much feedback before doing anything.
The iUI project was moving too slow. I did try for more than a year to get the rest of the core team to involve a bit more, or to let others to do the job. I even redone some (very boring) code cleaning job more than four times, to never see it accepted because of weird commit policy. Being stiff is ok when you have to deal with hundreds of commits per day (Webkit, Android, JQuery, ...), not when you are 3 people. Too slow, too rigid.
The other main reason is more personal. Since mobile web is gaining momentum, my situation has morphed from a "mobile web job seeker spending some time to contribute to an open source project" to a "self-employed mobile web consultancy & development company that needs a living & up-to-date codebase". In other words: companies are contacting me to implement, customize, improve or mobilize their in-house web applications. So, for my business sake, i needed to show and use a moving-fast up-to-date library. No significant official updates for more than 18 months is not acceptable, and i find myself using my own non-backward-compatible fork each time.
Those two reasons are why i finally decide to split my code from the iUI main branch & repo for good, and to move forward.
We are in 2013 (or perhaps even more at the time you read this), not in 2007 anymore. Modern browsers supports HTML5 and CSS3 pretty nicely, and the iPhone is not anymore the sheriff in town. We now have smartphones, phablets and tablets, running iOS, Android, Blackberry QNX, WindowsPhone. Some new players might hit our stores very soon (Firefox OS, Ubuntu Phone, Samsung Tizen, ...). Some say TV could also be the next big screen. With that in mind, we have no choice but to support those new platforms & browsers using their advantages & new functionalities.
So the first main big difference with iUI is that Emy fully supports styling, AJAX & CSS transitions on iOS (4 and above), Android (2.3 and above), Blackberry (6 and above) & WindowsPhone (8 and above). It also works just fine on Firefox OS.
Second huge difference with iUI is that Emy is using HTML5 elements rather than DIVs to define each views. The main toolbar is a Header element, each views are Sections. Then you'll find good ol' UL, FORM & FIELDSET elements in them. But we do not use DIV, UL or FORM as views: it's always a Section.
One other big change is that we talk about Views rather than Pages. This is a not an e-book library so why should we talk about Pages right? That might sounds like a small difference, but in fact, it means all Javascript functions you used to know in iUI have been renamed from xxxPages to xxxViews. Yes, you got it, it means we are 100% NOT compatible with existing iUI code, themes & plugins. We did or will port most of them by the way...
Emy is using CSS animations to perform transitions between two views, rather than CSS transitions like in iUI. It doesn't change anything by default, but you can create you own additional transition styles to use between two views. I know, it rocks :)
Last but not least, events callback. If you ever try to create something more than a testing demo with iUI, you probably quickly face the problem of loading a specific function or code when navigating to a new screen (aka Views in Emy). iUI event-log extension is a great help to do so, but you have to define everything in it or create some code by yourself based on attributes. For non-javascript saavy people, that was very obscur. Dry your tears my friend, data-onshow & data-onexit built-in attributes are here for that now! Just set them on the section tag element, and you're good to go.
We did remove orientation class & attribute on the body element. The exact same info can be set using MediaQueries so there is no need of Javascript to do it.
If browser supports it, we do use the hashChange event listener rather than a setInterval.
Form element toggle updates an input field, which means it's taken in account directly when you submit the form.
Since it's very convenient, we added a basic $() selector to select an element by its ID, or a list of elements by classname or tagname. Nothing more than that (if you need more, JQuery-compatible Zepto JS are doing the job fine).
Dialog views come with an opening animation.
Each View is minimum 100% height of the browser's viewport. In other words, the background color or image fills the all viewport even if its content is too small for that. This is called "fitHeight".
And a lot more you will love to discover...
Core javascript object documentation
If you want to learn all nitty-gritty details about Emy's javascript code.
Emy's CSS documentation
For designers, here is the complete guide of default elements and how we style them.
Emy community on Google+
Official community's talks, links, events & discussions about Emy
iPhoneWebDev Google Group / mailing-list
Last but not least, you may find some very useful support from this worldwide community
Follow Emy on Facebook
Like the Emy Facebook page to get latest images, links & news on the biggest network worldwide