Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Plugin Development Guidelines and Recommendations
While we try to keep the BuildFire.js framework as agnostic and web friendly as possible it is important to understand your codes environment to be fine tune your plugins for performance.
Mobile app users are extremely demanding and do not tolerate lag very well. So what you can get away with on web you may not be able to on mobile. The following are a list of tips recommended by the BuildFire dev team.
Perception is King
There will be times when the app will need to call a function that will take long and there is no way around it. When you encounter this is important to change the perception of the user to better tolerate the wait. A simple example of this is lazy loading. Technically if i were to load 100 images all at once, the total wait time for the list to load is much less than loading 10 at a time then waiting for a scroll event to load the next 10. However, for the user it felt almost instant.
Cache me when you can
BuildFire Datastore helps cache your data when loaded on the device. However, you shouldn't rely on this in your design. When possible cache results and images for subsequent loads then in the back end check if there has been an update and gracefully update the content. If possible don't re-render the entire DOM just update what needs to be updated.
Pick your JS framework wisely
Control using a framework like Angular to help navigate through views. This is fine since the
Control only lives on the Control Panel (web). However, The
Widget lives on the device and is under much more scrutiny than the
Control. Thus paying the toll of the Angular life cycle may in some instances be a detriment. While this shouldn't be taken as a blanket statement... Well written plain JS will always out perform frameworks.
Bundle API calls
As much as possible reduce the API traffic needed to load your plugin (at least on the widget side). Every environment has a limited amount of ports open to serve traffic. This means if you can combine to objects into one, you should. if you can bundle your js files into an
all.min.js you should if you can place a small CSS file in the html block, you should. There are many tools out there that help bundle files together while keeping your original source code modular
Don't Thrash the DOM (aka Layout Thrashing)
This is where many frameworks may help. However, assuming you are rendering objects on the DOM yourself (creating a
Table, a repeating
DIV, reading/writing values from elements ...etc). You want to make sure you have the document render as few times as possible. This will reduce CPU time, flickering and the over performance of your page.
Keep elements to a minimum
Every element needs to be computed in one form or another. There is a performance tax paid with each element that accrues quickly. A good rule of thumb is, if you can compose the same layout with fewer elements, then you should.
- Here are some good references: https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing
- Here are some good references: https://blog.tumult.com/2013/02/28/transform-translate-vs-top-left/ http://www.w3schools.com/css/css3_3dtransforms.asp
Avoid timeouts and intervals
While there will always be a use for delayed code you want to avoid using this technique when possible when influencing the UI. Especially, for animations. This also may inadvertently cause race conditions that are difficult to debug.
Test with throttling
- Here are some good references:
Nothing substitutes testing on a real device
- Here are some good references: https://developers.google.com/web/fundamentals/performance/poor-connectivity/