To answer my first question: I asked google for "plone config.js" and "collective config.js" and found only two packages Plone.CMS and Mockup. So it looks like Mockup is not widespread, now.
After some days and nights I was capable to migrate our Plone4 JQuery-UI popup form code to Plone 5 utilizing Mockup. Now I noticed that our bundle (which will be included in a single page-template, only) is minified roughly 200Kb fat. Our initial JS code (26kB not minified) was blown up by the use of mockup about an order of magnitude. Maybe I did something wrong. But the mockup-minimalpattern example behaves the same.
Now let's think a bit into the future. Each add-on with JS in it will have to go to Mockup sooner or later. We have decided to go to mockup because without using Mockup in your 3rd-Party-Code you cannot access Mockup widgets. In our case we had no calendar-picker widgets in our AJAX-Overlays anymore.
You can put your resources in the plone or plone-legacy bundle. But in that case your resources will be loaded virtually at each request and what is then left of the proposed benefit of modularity?
In the end you will go for a seperate bundle to gain the possibility to be included on demand.** If each addon Bundle is at least 170KB (plus its payload) this overhead will become a heavy burden for Plone.**
I understand the need of a new and unified structure to deal with JS and CSS resources. But I have the feeling that the currently proposed solution is a step in the wrong direction. The same wrong pattern I noticed while on the task of migrating our Content-Type Icons. The Idea of using autoscaling font-glyphs for Icons has some appeal - but in the end It will produce also bloat, driven by the same wrong patterns (To avoid collisions you build your own font etc.).
In addition the usability of mockup is low and the complexity is high - It took me a whole day to transform the mockup-minimalpattern into a slightly different structure (changing identifier names, introducing namespaces) to fit better into our project structure and naming conventions. It is quite difficult to find out by try and error which parts of an identifier are "reserved words" used by the mockup framework and which parts you can change without harm. E.G. you should not change the "mockup-bundle-" prefix.
The TTW compiling of resources gives no support to find errors in the compile process of a bundle. In Addition online fiddling with a JS file in the editor and firebuck - edit - reload the browser cache is no longer possible. Yes, yes, we can use tests now. We can now debug the JS code without a plone running (But this is only an advantage if you JS code does not interact with Plone). But these advantages are IMHO not as big as the lost flexibility with the old (not so perfect) way of Plone 4.
My opinion is that some problems should to be discussed:
The bloat of 170KB for each additional bundle.
We may need a fine grained flexibility to load a resource on demand.
The process of compiling a Bundle TTW has to become more tranparent and give more feedback.
The fragility of the resource registry and its flaw to lockyourself out. A single not compiling JS-file in the Plone or Plone-Legacy bundle disables the complete ressource registry. Since one cannot delete registry keys - in the worst case you have to go into the debugger to delete the keys. This is not an obstacle for the developers, only - let an user/admin install a plone package with unclean JS code and the admin ist stuck and has no idea how to fix the problem. Usually unclean JS code comes with none or a broken uninstall registry.xml file.
Don't get me wrong. I do not like to start a "I hate Plone 5" flame. There is much more good than bad in Plone 5. But it still can be made better and I like to contribute to make it better.
In regard to your bullet points for action, I believe that three of the five issues you identify for work are already solved or well underway.
For the issue of the bloat of rebundling javascript like mockup that is required by a bundle but already loaded by Plone, work has been done and will arrive in an upcoming public release to allow bundle authors to identify "stubs" that they require, but which are already loaded. This work is already in the master branch of Plone and I believe will be coming out with the 5.0.3 release.
For the issue of the need for finer grained flexibility for loading resources, you may wish to take a look at the bundle/resource request api, which allows developers to suppress active bundles or include normally inactive bundles or resources on a per-request basis. Combined with the conditional statements available in bundle registrations it provides quite a lot of flexibility.
As to the transparency of the process of compiling a bundle TTW, at the least we have recently made some tremendous improvements in the documentation available for the resource registry and how it works. I agree that the TTW experience (the user experience) of compiling a bundle should probably become more verbose, but we do now have much better documentation of what is required and how things work. The new docs are not yet live but have been merged to the master branch of the Plone documentation repository
I agree that the fragility is an issue that requires addressing, as is handling problems like un-compilable js code. We should absolutely move forward on those, but perhaps things are a bit better now than you might think.
Again, thanks for your feedback, and I look forward to hearing your further thoughts on the matter.
for this valuable Information. I am glad to hear that most of my fears have been unneccesary.
Nevertheless I am also glad that I had outspoken my fears so now I can rest with the good feeling that there is taken care for them.
But there is one issue I only mentioned along the way - the Icon issue. I have come across some threads I think it was one from Keul and one from jensens, which like my person are not so happy with the glyph/CSS-Background image solution. Is there an alternate solution to expect?
From my perspective as integrator and 3rd-party package developer the learning curve of plone has become steeper and steeper with each version. Surely, it is the natur of development that it becomes more complex with time. But my fear is that we will loose more and more integrators and developers and therefore users which are no longer willing to cope with that extraordinary learnig curve. If I look for jobs on e.g. twago not even Django is requested much as development framework for small projects. Mostly PHP and Ruby based solutions are requested. The question is what to do best with this situation. Plone ist an outstanding solution with so many batteries included and therefore good suited to make small projects.
Plone cannot become like other simple frameworks where you can hack together what you like. But if intergration becomes difficult nobody will use ist. A big dilemma.
In Addition online fiddling with a JS file in the editor and firebuck - edit - reload the browser cache is no longer possible.
What do you mean? When you're in development mode, you certainly don't have to re-compile the bundle on every change. Just reload your browser and work.
The process of compiling a Bundle TTW has to become more tranparent and give more feedback.
It's a hard problem to solve. If you're doing heavy JS development, it'll be better to develop those on the file system.
The fragility of the resource registry and its flaw to lockyourself out. A single not compiling JS-file in the Plone or Plone-Legacy bundle disables the complete ressource registry. Since one cannot delete registry keys - in the worst case you have to go into the debugger to delete the keys. This is not an obstacle for the developers, only - let an user/admin install a plone package with unclean JS code and the admin ist stuck and has no idea how to fix the problem. Usually unclean JS code comes with none or a broken uninstall registry.xml file.
This should not happen. 1) hopefully the RR always loads and 2) if it doesn't, there is a backup noscript wrapped tag to delete bad bundles. What version of Plone are you on?
Don't get me wrong. I do not like to start a "I hate Plone 5" flame
No problem. It means we're not communicating something because I think we address most of your concerns.
Also, I don't see the big problem with font icons. There are many sites that make it dead easy to produce your own icon sets.
I'm not familiar with why this would cause more bloat than another method.
Just because something is new doesn't mean it's harder for new people or integrators on the whole. Font icons are easier to make, manage and use on a site than image sprites.
Also, not sure that search worked very well because I have a couple package in the collective using it.
Also, sort of a weird query. config.js is just a requirejs idiom. So any package using require.js could have a config.js. However, it is not necessary and can be configured without it.
I am currently a subcontractor for a small Plone 5 site (and my first commercial Plone5 project) with a small number of content types, some views, some forms...nothing fancy. My experience is not that bad. Going from Plone 4 to Plone 5 is not a big step if you have experiences with Plone 4. Key problem #1 remains the complete resource registry story (in particular with third-party JS modules) which is hopefully addressed in Plone 5.1. I did not spend much time in this project with resource registry and loaded the related resources directly inside the views when needed. The biggest change is the theming story with Diazo as official way to theme Plone. Honestly I never gave attention to Diazo in the past (Diazo has been around for a while) and so had dig a bit deeper into Diazo - at least deep enough in order to provide the foundation for customizations to be accomplished by the main contractor. It took me half a day to get the theming working with a dedicated theming package, a working rules.xml etc....The Plone documentation and the Plone training documentation has been very helpful here - in most cases very well structured and brought to the point. A weak point in the customization story is the customization of existing (view) templates e.g. when you add new fields to an existing type through behaviors. Viewlets are usually used to display the new fields...in the end I ended up writing a complete new view for a type or modifying an existing template using z3c.jbot.
Your points and observations regarding the role of Plone is true but only limited to Plone. Other solutions like Joomla, Drupal etc. have the same problems in the market. The CMS market as it existed several years ago is no more and changed a lot. Wordpress is king - for good or bad. We can not compete with Plone against Wordpress - too large, too complex, too expensive and Wordpress is technically catching up. And of course there is a trend to smaller solutions instead of requiring the "eierlegende Wollmilchsau". I do not see that PHP and Ruby are rising. Lots of projects request Python knowhow but in various new areas that did not exist several years ago.
If you are looking for a "small Plone" then you should clearly check out Kotti - I used Kotti with success in 3 projects over the last years and it is more approachable than Plone in many ways...of course not that sophisticated but very complete and hackable.
Though as a reasonable modern alternative, I naively wonder if SVG (background) image replacement is a reasonable strategy for an add-on with 1-2 actions or types needing some kind of icon, assuming that any add-on in a "just a bunch of add-ons" (JBOA) environment is going to have a CSS resource anyway.
One of the ideas behind using a font instead of lots of image files for icons was to reduce the number of files loaded. Since only the one font-file of the theme has to be loaded once.
But this advantage vanishes if every 3rd-party package comes with its own font. And it makes sense to have a own font because if you just put your icons in the plone font you may collide with other packages using the same char-code.
It is likely possible, but untested (AFAICT) in Plone 5, to use inline SVG inside CSS (data url scheme, possibly encoded using base64, which is inefficient, but still more streamlined than loading a font-per-add-on as an extra download if you already load CSS; anyway SVG is pretty compact, and front-ends gzip this stuff anyway). I have not tested this hypothesis, but may give it a try very soon on an add-on I am porting from Plone 4 to Plone 5 that needs two toolbar icons.
One argument against background images is that they have no "alternate text" parameter and therefore cannot give hints to screen-readers for visual impaired people. And the same holds for glyph icons.