[SalesForce] Remove vertical ScrollBar from Lightning Page

Firstly the Lightning Design System doesn't support RTL out of the box: https://github.com/salesforce-ux/design-system/issues/308

At Vlocity we've added support, but it's not been merged in to SLDS as there have been questions and concerns about different approaches. For example see this PR for 2.2.x https://github.com/salesforce-ux/design-system/pull/438

However you can use our branch which is currently aligned with SLDS 2.2.3 (we're a little behind the latest): https://github.com/vlocityinc/design-system/tree/mgoldspink_Salesforce/master

To make this work, you need to sync up the branch and build the code as per the standard build docs for SLDS. This will generate additional .rtl.css files. In our visualforce pages we detect that language of the User using:

public static Boolean isLanguageRTL() {
    String language = UserInfo.getLanguage();
    if (language == 'iw' ||
        language == 'ar' ||
        language == 'ur') {
            return true;
    }

    return false;
}

Then in our VF pages we add the following logic to include the right stylesheet:

      <apex:stylesheet value="{!IF(isLanguageRTL, URLFOR($Resource.slds, '/assets/styles/salesforce-lightning-design-system-vf.rtl.min.css'), URLFOR($Resource.slds, '/assets/styles/salesforce-lightning-design-system-vf.min.css'))}"/>

Then the final missing piece is that element needs the slds-max-medium-table--stacked-horizontal class:

<table class="slds-table slds-table--bordered slds-table--cell-buffer slds-max-medium-table--stacked-horizontal">

I tried to make this code work inside Lightning but failed because Lightning seems to be only a subset of Aura.

Lightning is running a full copy of Aura. However, it's not running the current version of Aura. There's some lag time between what we have in Lightning and what we have in Aura; most likely, the introduction of ui:scroller means that we'll see it in the next release or two (obvious warning: we might never see it, for a variety of reasons). This is also the reason why, for example, we don't currently have a lightning:progressRing element, even though it's in the Salesforce Lightning Design System. Lightning as we know it is always at least one release behind SLDS.

How do you do it?

Today, you write really convoluted code, like the code you've found. However, I would also argue such code is overkill for the majority of use cases. If you're displaying "thousands" of items, or more, you may need to consider performance. If you're likely never going to show more than a few hundred items in a list, it's probably not a priority to be perfectly optimized.

Ultimately, what you're going to need is some custom rendering or something, and a complicated scrolling library. Or just go the easy way like Lightning does today, and just detect when you're within a few pixels of the scroll bottom and add more items. Or use pagination/filtering/etc. Naive infinite scrolling is "slower", especially on mobile devices, but should perform acceptably. Pagination, on the other hand, handles tens of thousands of records with ease, as I've demonstrated in a gist (note: yes, I realize it doesn't use newer Lightning features, it needs to be updated).

Do you know of any Salesforce roadmap to release their internal scroller component?

Even if we knew, we couldn't tell you, unless salesforce.com announces it publicly in an official manner, or unless you were under a Salesforce NDA (and even then, you'd learn through an official NDA'd channel, not the general community). Future Looking Statements (previously Safe Harbor Statements) are always prefixed with a warning that you should buy the Salesforce of today, not the Salesforce of the future. Anyone in a position to know what the roadmap looks like probably couldn't tell you, either, since that might be a violation of NDA.

What else could be of help to build a "good enough" solution?

That depends. What's good enough for me may not be good enough for you. For now, I strongly recommend pagination, even though SLDS would have us believe that infinite scrolling is a thing of the now. If you do implement infinite scrolling, consider a simplistic approach that simply updates the entire DOM. It's trivial to write, and it's good enough for Salesforce, so it should be good enough for us (for now).

The difference between pagination and infinite scrolling is that the user has greater control of the page loads. This is a Good Thing in the general sense. Nothing destroys a good user experience than having things repeatedly happening unexpectedly or unexpected slowdowns while just "browsing". For now, I would just suggest using lightning:datatable if it suits your needs, and if not, consider pagination. Infinite scrolling should still be considered a last resort for the moment.