I've been spending the last 2 years doing my best to lay the governance for a STB (Set Up Box) environment where we have app developers building HTML5 apps that provide the user experience. These apps are well developed but the STB runs a custom built webkit based browser which is not exactly "Google Chrome"like, so the apps appear slow and laggy. The best word used to describe these performance issues is "Jank", which is an actual word the industry uses to describe web apps that appear jittery and laggy due to dropped frames. This is most evident when you try and run apps with complicated transitions and animations in mobile browsers for example, where you see visual animations jump and play catchup.
In our STB environment I have tried by best to recommend best practices so our apps don't show too much "Jank". I've grouped these practices under the term "L-PEC" (Low Performance Environment Coding).
You can read some of these suggestions here.
But if I were to give just one recommendation which I feel makes a lot of difference, it would have to be
"Don't Touch the DOM!"
By which I mean, don't manipulate the DOM after you app has loaded in the browser. So don't read a DIV's width (or worse, its calculated offset values like offset()), or add a new DIV or delete an existing DIV etc.
But this sounds ridiculous right? these days we build apps that are very dynamic and we need to do a lot of DOM manipulation. With that in mind, my suggestion would be -
"Avoid Touching the DOM as much as possible"
So if you have to do it then, do it as less as possible. Also group your DOM reads and write together and utilize requestAnimationFrame() to set the window for when you can manipulate the DOM. This will prevent "Layout Trashing" which is one of the primary reasons behind "Jank".
(Read more in this article - "Preventing 'layout thrashing'")
But all this sounds too complicated to do, surely there must be libraries out there that have solved these issues which you can just use?
And the answer is yes, this issue with the DOM is so well known by low level performance engineers that they have created libraries to work around the issue. Most notably:
1) Facebook React - [which can be used thought of as the View in a MVC model]
2) Famo.us - [which is a custom library for high performance transitions]
The idea behind these libraries is the concept of a "Virtual DOM", which is a "Virtual" element tree maintained in JavaScript memory and is manipulated and managed here after which it is mirrored to the browser DOM using perform-ant reflow and repaint techniques like using utilizing requestAnimationFrame().
I've personally used Facebook React and Famo.us and there is a significant improvement when you test your apps on low performance environments like Mobile and STBs.
What do you guys think? Do you have any other library suggestions? Please comment and let me know...
In our STB environment I have tried by best to recommend best practices so our apps don't show too much "Jank". I've grouped these practices under the term "L-PEC" (Low Performance Environment Coding).
You can read some of these suggestions here.
But if I were to give just one recommendation which I feel makes a lot of difference, it would have to be
"Don't Touch the DOM!"
By which I mean, don't manipulate the DOM after you app has loaded in the browser. So don't read a DIV's width (or worse, its calculated offset values like offset()), or add a new DIV or delete an existing DIV etc.
But this sounds ridiculous right? these days we build apps that are very dynamic and we need to do a lot of DOM manipulation. With that in mind, my suggestion would be -
"Avoid Touching the DOM as much as possible"
So if you have to do it then, do it as less as possible. Also group your DOM reads and write together and utilize requestAnimationFrame() to set the window for when you can manipulate the DOM. This will prevent "Layout Trashing" which is one of the primary reasons behind "Jank".
(Read more in this article - "Preventing 'layout thrashing'")
But all this sounds too complicated to do, surely there must be libraries out there that have solved these issues which you can just use?
And the answer is yes, this issue with the DOM is so well known by low level performance engineers that they have created libraries to work around the issue. Most notably:
1) Facebook React - [which can be used thought of as the View in a MVC model]
2) Famo.us - [which is a custom library for high performance transitions]
The idea behind these libraries is the concept of a "Virtual DOM", which is a "Virtual" element tree maintained in JavaScript memory and is manipulated and managed here after which it is mirrored to the browser DOM using perform-ant reflow and repaint techniques like using utilizing requestAnimationFrame().
I've personally used Facebook React and Famo.us and there is a significant improvement when you test your apps on low performance environments like Mobile and STBs.
What do you guys think? Do you have any other library suggestions? Please comment and let me know...
This comment has been removed by a blog administrator.
ReplyDelete