Johannes Raggam
Jens Klein
Eric Brehault
Gil Forcada
Ramon Navarro-Bosch
#PLIPs
Cleanup and enhance icon and thumb aspects
=> still need help with tests
Simplify the Resource Registry
We agree the JS story might be simplified. This PLIP is about many different aspects and some are not totally clear (it assumes some complex aspects of the core JS resources management have to be mandatorily applied to any resource, which is not the case).
And most of the features described here are already existing (but lot of people are not aware).
Nevertheless we are opened to specific PLIPs or PRs if you think it could improve the situation:
HTTP 2 is not there yet, we think we can not abandon bundles for now (maybe in 2 or 3 years), but we could imagine a PLIP to disable meta-bundling in production mode (note: it can already be done by just setting merge_with=”” on each bundle registry entry, but maybe you imagine a global setting ?)
Ordering resources according the registry order could be done via a PR (no need for a PLIP here). It is obviously not useless for RequireJS compliant resources, but it might be useful for non-RequireJS ones.
Almost all the points about managing individual resources apart from core bundles are already possible as far as those resources are directly declared as bundles. If the “bundle” name is confusing here, we could rename “bundle” into “resource” and “resource” into “resource item” (or “resource component”), and maybe it would help.
It is already possible to create a resource without using RequireJS but the non-ordering might be a problem, so the previously mentioned PR might be enough.
The simplified version of the registry records might be interesting but should be detailed in a dedicated PR.
#Plone 5.1
We recommend to make the 5.1 release as soon as possible. The Release team seems ready.
I have to say that I'm quite disappointed with this review: resource bundling in Plone 5 is one of the chief causes of pain: it's totally overrated, completely needless, overly complex, doesn't work and must die quickly for the sake of Plone's future.
what do you mean by "HTTP/2 is not there yet"?
HTTP/2 was published almost 2 years ago and everybody who wants to use it, can use it now:
Apache 2.4.17 supports HTTP/2 via mod_http2 module
nginx supports it since 1.9.5 via ngx_http_v2 module
I personally set up one site a couple of months ago using Cloudflare and it was quite easy.
I think it's a pity we continue kicking the can down the road on this: a lot of third party add-ons will continue to lack support for Plone 5 until we have a clear path on doing things and a lot of people will lack interest on deploying in Plone 5 until this has been fixed.
if you don't like this PLIP, please consider proposing alternative solutions, but this needs to be fixed, the sooner, the better.
meta bundling is not mandatory: by setting merge_with=”” on all your bundles, nothing will be aggregated;
bundling is not mandatory: by making each of your resource an actual bundle (and I agree a rename could help here), you will get one file by resource.
So it is not clear to me what your PLIP would change here.
The FWT is not refusing changes regarding the RR, but what, in your opinion, cannot be done right now and should be possible?
Note: when I say "HTTP/2 is not here", I do not mean it is not possible to use it yet, I just say that the majority of my customers are not offering HTTP/2 support on the servers where I have to deploy Plone.
The complete resource bundle stuff is broken by design, it is rotten, it has to die. Point. I avoid further rant because it is either ignored or silently accepted (which is true in most cases).
We can do major changes for Plone 6, but not in the 5.x series.
Thus said HTTP 2 and dropping the RR is a major change. What we can do is to additionally support the HTTP 2 approach.
The current RR is far away from perfect. But it is not rotten. It works in its defined boundaries, such as using RequireJS and less. The TTW story is a big headache and was possibly a mistake, the scripts generated by buildout do work ok.
I do not defend the RR (Stockholm syndrome if I would), but it is wrong to do such a major change in a minor release. Adding features and fixing problems is fine. We can also start depreciating stuff.
nothing… nevermind; I have lost any interest on this and other issues.
I was tempted to PLIP about fixing the toolbar but seems to me it makes absolutely no sense, neither.
I still haven't found a single reason to upgrade to Plone 5; I'm totally fine with good old Plone 4.3: it's rock solid, highly productive and pretty stable.
I'll wait for Plone 6 then; let me know if there is any interest on discussing this or other issues at some point in the future.
FWIW, this excludes lots of folks still running nginx from system packages on distributions in the vintage of Ubuntu 14.04. I'm excited for HTTP/2 as a nice side-effect of my planned upgrade of my systems to Ubuntu 16.04 later this year, but in the meantime, tricky to assume that it is universally available on what folks use now.
It's very hard for anyone not deep in RR understanding to parse the differences in opinions like "rotten" and 'merge_with=""' or why TTW building doesn't seem to work all the time. The PLIP itself doesn't help as it just seems to say bundling is bad and old fashioned.
The only think that is clear to me is that RR is hard to understand, but just about everything about JS building is to me these days...
Is there anyone with a good grasp of this who can summarise the issues dispassionately?
I never said that; if you had read carefully (and dispassionately) you could have understood (1):
I'm not proposing not to bundle resources from a single source (Plone core, third party add-ons…), but not to bundle the resulting bundled/unbundled resources as one huge bundle on Plone.
Plone should bundle its CSS/JS resources in 2 batches, one for anonymous users and one for authenticated ones; @plone/framework-team should decide what to use and what to recommend for third party developers, but not enforce them to use it; please, read again the example to understand what I'm proposing. the whole thing is about removing the compilation/bundling part that seems to be a collection of hacks/hooks that are not working anyway.
seems the PLIP was not clear enough; but the kind of discussion I was trying to bring is what I expect next time such big changes are planned on future versions: think on other people problems also and not on solving yours only; better to implement evolutionary and not revolutionary.
I'm think the numbers on caniuse are wrong, if the numbers on netmarketshare are correct. If so, 47.2 % are using Windows 7, where http2 isn't available. + 1-2% using OSX < 10.11.
So, you are using http2 in production? Can you point me to a site? I'm curious.
Since you're making only 29 requests and not severall 100s, HTTP2 with an HTTP1 fallback is OK. I think I wasn't reading carefully enough your PLIP - re-reading it, you weren't suggesting unbundling everything, but to not bundle external addons and not doing the final meta bundling.
I think we should re-discuss this PLIP. But the PLIP itself should be refined, more precise and with a concrete concept, as it is a bit vague on implementation details. All the other PLIPs which target the resource registry should also be considered. I'll try to get some time helping here.
check again, the home page of that site makes around 100 requests in total, but we lazy load the content using collective.lazysizes.
anyway, making "several hundreds" of request to get a single web page is bad design no matters if you're using HTTP/1.1 or HTTP/2; I've seen that only with advertising networks: all of them are broken.