Let’s assume you have an application that looks at the last 100 payments performed with a creditcard and displays a graph for these with the payments grouped into different categories (food, car, sports,…). Instead of the server performing all the grouping and calculating you decide to take advantage of the processing power on the clients (which is what google does for GMail) and only send the clients a list of payments.

There would be logic that takes the payments, groups them into the categories and calculates the totals for the different categories. That logic does not depend on the UI but is performed on the client side and is UI independent client logic.

On the other hand, there must also be logic to render these things onto a graph. This will probably involve drawing or rendering images and will require logic to see how big a certain part of the graph needs to be rendered. This is logic that depends on the UI and is performed on the client side so UI dependent client logic.

Now, if you have different applications (native apps, mobile website) they would all have the same logic to group the payments. What would differ between these applications would be the way the graph needs to be rendered. Hence the former is UI independent, the latter UI dependent logic.

UI Independent client logic

For most applications, this would be the model in the MVC, MVP, MVVM, … patterns.

The model is all the data and business logic needed to run an application.

In old incarnations of the web, this was all done server side with the browser only presenting views to the user. Now, more applications are running some/most/all of the model within the browser. Ideally, an application should run as a set of APIs without any reference to views (DOM elements) or view binding logic.