Possible problem of Caching in 2.5.0 (vs 1.7.3)

[ldetomi]

Hi recently uploaded my version of LESS from 1.7.3 to 2.5.0.

It seems that new version has a "sort of cache" because is quickier to load but in the same time does not process recently modified files.
I correctly set LESS options with "env:development" (same setting for 1.7.3) and tried also to change settings about "aSync". Nothing.

Back to 1.7.3, everything return slower but edits are correctly recognized and processed...

[lukeapage]

Can you add more info?
e.g.
which browser, what exact options are you using?

can you help with debugging for us? That would help us fix it quicker.

[ldetomi]

Hi luke,
I tried both with Firefox 37.0.2 and 39.0 (developer edition) and problem is the same, I just re-tried with both browsers and both LESS versions, 1.7.3 and 2.5.0.

Here my LESS options (nont changed while switch LESS version):

less = {
       env: "development", // or "production"
       //async: false,       // load imports async
       //fileAsync: false,   // load imports async when in a page under a file protocol
       poll: 1000,         // when in watch mode, time in ms between polls
       dumpLineNumbers: "all" // or "mediaQuery" or "comments"
       //functions: {},      // user functions, keyed by name                      
};

In details, if I make an edit in a .less file and reload page, I see these differences between 2 LESS versions (I tried with and without forcing cache refresh on reload):

• 1.7.3 - window become totally blank and after few seconds page will display entirely styled and with last .less file edit perfectly visibible.
• 2.5.0 - window shows only html without style almost immediately, and after very few seconds (much more less than old version) everything is styled and loading finished.

In other words:
Old version seems have no cache and everything is shown only after all .less resources are parsed. New version seems to have a cache that speeds up loading but is not immediately reactive to edits, and in addition, naked DOM is anyway loaded (and displayed) immediately.

[seven-phases-max]

I suppose this is just "blocking" vs. "non-blocking" stuff. The blocking loading (i.e. the old behaviour) is sort of deprecated and somewhat anticipated by browsers now anyway (#2384). And the "naked DOM is anyway loaded (and displayed) immediately" problems is what #2735 is about to fix.

[matthew-dean]

Basically: "sync" XHR is out. It was throwing warnings in browsers as the option itself is deprecated. The reason why sync XHR was an option in the first place was to not show FOUC (flash of unstyled content).

But that's only one way to solve that problem, and sync XHR was deprecated as a feature for browsers because it's disastrous for page performance. What #2735 does (which was released in 2.6.0) is block rendering until styles are finished WITHOUT blocking XHR. I found this made page loading about 10x faster. However, you'll still get FOUC unless you set async: false. The docs need to be updated in this regard, because that technically means that "async" now refers to page rendering and not XHR requests. (XHR is always async as of 2.6.0.) I'm recommending that async: false becomes the default option, since it no longer has the performance hit that it used to.

So, in short, you probably don't want to use either 1.7.3 nor 2.5.0 if you're using Less in the browser.

[seven-phases-max]

So I guess it's safe to close this issue as not applicable anymore.

[matthew-dean]

@seven-phases-max I think so. Although, just to fully address the original issue, which was about the cache not refreshing after edits, I think that part too is actually as designed. The cache doesn't refresh unless the root .less file is updated. Probably it seemed to be refreshing the cache for any imports just because it was never caching. Until those recent updates, the cache wasn't used at all in a number of scenarios.