As Sencha has shown with their FastBook demo it is more than possible to make mobile web based applications that look and feel as good, if not better than their native counterparts, but it is fair to say that in order to do so you need a deep understanding of the languages, browsers and design patterns that you are using.
So although we have many years of experience building complex, real-time trading applications in the browser we never stop experimenting, especially with new mobile devices, and my more recent experiments have been with hardware accelerated CSS properties on mobile.
Hardward accelerated transitions : The classList problem
- transform (both 2d and 3d)
I have had a great time with these properties, by combining them you can create almost any transition that you will find in popular native applications and they perform very well.
But I noticed a surprising issue, especially when translating complex DOM trees which I didn’t expect as the transition should be handled by the GPU (and is). The transition was always silky smooth but with complex trees there was a long delay before the transition begun. The problem got worse with larger trees.
Taking a look at the chrome console the delay was being caused by an expensive Recalculate Style. This was being triggered because to initialise the transition I was adding a class to my container element.
Even though the ‘transition’ class only contained a single property that shouldn’t really need to cause an expensive Recalculate Style it was happening anyway becuase I added a class.
element.style.webkitTransform = "translate(500px, 0)";
The issue can be seen at the codepen I put together.
For the timeline below i had this set to 100000 and tested in Chrome. Firefox seemed to crash at anything above 20000, IE11 was OK. If you experience this issue you can load the pen with JS disabled by adding ?
turn_off_js=true to the url which gives you a chance to change the parameter. You shouldn’t need to go so high to see the difference in the Chrome timeline.
The following timeline screenshot shows the issue perfectly.
Although this post has been heavily focussed on Chrome, I have ensured that the codepen works in the latest version of IE and Firefox. Safari should be fine too, however I haven’t done much investigation into how any of these browsers behave yet, please comment below if you find out.
If you are experiencing delays with your transitions check the Chrome timeline, see if some unnecessary Recalculate Styles are firing and if so you might want to make a similar change. Most great animations libraries such as animate.css use classes, which makes perfect sense, but could lead to the issue above.
It may well be that browsers resolve this issue in the future, I am not sure why they couldn’t already know that adding the ‘transition’ class doesn’t require a Recalculate Style. So at some point my advice above will hopefully becomes completely useless. Unless that is, you start using the Chrome timeline a bit more.