The Engineer Who Wasn't

One of the places where LESS comes often short, is when one needs to have a mixin which acts as a function.

Mixins usually set the value of a property directly, for example:

.set-left-padding (@padding) { padding-left: @padding / @some-other-variable; } .set-left-padding(5);

But what if You want to simply calculate the value @padding / @some-other-variable and use it where ever you want? One would wish something like this:

WARNING: IMAGINARY CODE

.calculate-left-padding (@padding) { return @padding / @some-other-variable; } padding: 0 0 0 .calculate-left-padding(5);

But of course it doesn't work this way. Here's how you can get around it:

SOLUTION (work around)

.calculate-left-padding (@padding) { @calculated-padding: @padding / @some-other-variable; } .calculate-left-padding(5); padding: 0 0 0 @calculated-padding;

Obviously this solution has some drawbacks,

Foremost, the "function" works with a certain protocol, which is setting a variable which needs to be used immediately after. This can only been known by reading the implementation of that mixin since there's no such a thing as LESSDoc.

In webapps, sometimes it's necessary to show/hide heavy elements upon user's interaction. A good example is the pull-in menu found on most websites like Facebook:

That toggle needs to happen very very fast. Two solutions exist for doing that, and each one has its own penalty.

display:none

Setting display:none on the toggling element will take the element completely out of the flow when it is hidden.

Pros

It will not cause any paint/relayout time during the time it's not visible. It is important on heavy pages, for example when toggling a class on body or a major change of this sort, the less elements you have on the page, the faster it will be.

Cons

The moment toggle happens, the styling of all the elements inside will immediately get calculated by the browser, then a complete page relayout happens (since the new element will be inserted in the flow) and finally a complete paint. This fact will have a considerable impact on mobile devices.

opacity: 0;

Using opacity: 0; will simply make your element invisible, but it will still be in the flow and will still emit browser events.

Pros

Once the user has decided to show/hide the element, changing the opacity of your element (assuming you have promoted it to a layer already) will only cause a layer-composition and no paint/re-layout/layout-calculation. Layer-composition is a cheap operation on most devices, it does not consume any CPU or css/script access.

Cons

While the element is hidden (via opacity: 0;), Element will participate in whole #document re-layouts and paints which can be an overhead (window resize, or orientation change will cause a whole document repaint and relayout).

Homework

touchmove on iOS

Once you have installed a touchmove listener on your element, you will get all the touch events as long as the user moves the finger.

touchmove on android Chrome (at least until version 32)

When user moves the finger on the element, you will get

touchstart

touchmove (once)

touchend

In order to get all the touch events, during the first touchmove, you will need to preventDefault on the event object the first time.

These are some tips to be used when you are really really really trying to run your code fast. For example in graphic intensive game where you are trying to push the framerate up...

Avoid indexOf on arrays, instead traverse the array with a for loop and check for equality.

Don't shy from creating functions and outsourcing logic, browsers are massively optimized for that

Avoid instanceOf, instead use doctype.

cache the length of your array, when creating a for loop.

Avoid accessing the same member of an array multiple times, store it in a temporarily variable.

For comparing objects, come up with a string representation for that kind of object, cache it, then compare the strings.

Do not install eventListeners right away, instead finish rendering your dom, insert it to the body, wait for document.requestAnimationFrame(), and then call addEventListener on individual dom nodes.

Here is an example using some of the above.

Optimizing the dom is important if you are offering your HTML for Mobile browsers, or you need to run heavy html5 application on desktop (or both).

There are two situations where you want your web app to be blazingly fast:

Presenting a new state (navigation, opening an overlay/dialog)

User interaction (user clicking a button, filling out inputs)

Here are the reasons any of the above might be slow:

Javascript execution for dom creation/modification.

Browser layout-ing the new/modified dom structure

Reading your css, determining what rule belong to what dom node (calculate style)

Computing the layout of the page, sizes and positions fo each element.

Painting the dom nodes

compositing layers using GPU

Each of these causes have their own solutions.

Here goes some that I have found for each of them:

Javascript execution for dom creation/modification

Avoid jQuery, all together

jQuery is a great tool for doing dom manipulations with few lines of code, compatible with a vast variety of browsers, but the bowler plate around it makes it painfully slow for situations where we are begging for milliseconds.

Learn to use low level methods, such as appendChild, removeChild, createElement, addEventListener etc., they work across all modern browsers flawlessly.

$("<div class='my-cls'>").append(otherEl).click(myFn); //could be var element = document.createElement("div"); element.classList.add("my-cls"); element.appendChild(otherEl); element.addEventListener("click", myFn);

Avoid html parsing

html parsing is way slower than manually creating dom elements via document.createElement.

It's even better to use element.cloneNode(true) for elements which are often created (for example photo containers in instagram). Prepare a pre-made domNode which has all the structure you need, clone it for each case, then start filling it with dynamic information by accessing its children via element.childNodes or element.querySelectors.

function getTemplate () { var innerElement, template = document.createElement("div"); template.classList.add("my-element"); innerElement = document.createElement("div"); innerElement.classList.add("inner-el"); template.appendChild(innerElement); } function renderObjects (objects) { _.each(objects, function (obj) { var element = template.cloneNode(true); element.firstChild.innerText = obj.description; element.setAttribute("title", obj.title); document.body.appendChild(element); }) }

Avoid, at any cost, to read height/width of elements displayed

element.offsetHeight (or $(dom).height() for those familiar with jQuery) and element.offsetWidth cause a relayout and are poisonous for performance. Try to have your elements be predictable in terms of size (for example ask your server to serve photos with predefined dimensions or limit your text blocks to a certain number of lines in list items, it helps readability anyway)

Browser layout-ing the new/modified dom structure

Batch your dom changes

By batching your dom changes, you will prevent multiple re-layouts to happen. There are multiple ways to do so, each one appropriate for a specific situation.

Detach the main container, do changes and attach back

In some situations, where a lot of changes are going to happen to almost the entire page, it's most efficient to detach the top most node, under body, do changes on it, once finished attach it back to where it was. The crucial part to remember in this method, is to do the entire operation in a single javascript thread.

function showContact(id) { fetchContact(id).then(function (contact) { var tmpEl = document.body.firstChild; document.body.removeChild(tmpEl); //START your operations removeContent(tmpEl); addContactReleventClasses(tmpEl, contact); addContactContent(tmpEl, contact); //END your operations document.body.appendChild(tmpEl); }); }

Use document.createDocumentFragment

if you have multiple elements to be added to a container, on after another, prepare all of them, add them to a document fragment, and add the document fragment to your container.

Avoid having conditional styling or manipulation on container as much as possible

Any modification to a container, will cause the styling of all of its elements to be invalidated and recalculated. css :hover also causes the same effect.

Painting the dom nodes

Avoid expensive stylings

Gradients, box shadows, text shadows, images and webkit flters are very costly at paint time.

Understand and use layers

Certain css stylings cause an element to be promoted to a GPU layer. This has two main advantages:

Localizing the changes on children elements. if a change happens to an element belonging to a layer, it will not affect any other layers to be repainted

Applying translate (including animation) doesn't use CPU at all, it will simply ask GPU to move/scale/rotate the layer.

Although the disadvantage with this method is the memory consumption, one should careful not to have unnecessary layers.

Final thoughts

Don't make any assumptions, test, test, test

Develop on your least performant device, preferably mobile, old one :)