We have gone over this how many times? Shipping with Volto DOES NOT imply any changes to anything in Plone classic.
I didn't say it did. I said there will very likely be no more mosaic development, ie mosaic is effectively dead. Why does no one read?
As always with Plone it depends on the people, not on a decision here. Mosaic with site-layouts is very useful if building SSR applications, it simplifies a lot. I am sure it will co-exist for long time. Mosaic-the-editor is an old grumpy piece of JS nobody loves. While its features are great, I dont now one person who is eager to touch it....
I just had the pleasure of making a new Wordpress theme with the Gutenberg editor. Compared with that, I would say the Mosaic UI is greatā¦ in fact, the only thing I am missing (for the editor) is that tiles can contain tiles (a 'fill-slot, maybe'?)
I see red when people declare X is dead... Let me just add that CastleCMS demonstrates clearly how Mosaic is still !@$@$# fantastic. If you havenāt seen it in action, I will be happy to give you a demo. It will blow your socks clear off.
Do you have a video of Mosaic in action laying around? Or is there a talk from a conference or such?
I do not know of any off the top of my head, but maybe I could just record a demo of CastleCMS. I would like to āin my spare timeā ā¢
Seriously, every time I demo CastleCMS, people do not say āoh, I donāt like those tilesā... they say instead āthis is fantasticā (about the tiles, but mixed in with all of the other features of CastleCMS too). On its own, when I show Mosaic to individuals or to clients, they want it in their site. So while continuing development of Mosaic is currently not very active, maybe it is already good enough for most.
My vacation starts in 10 minutes, but here is something very simple made just now, if it should be of any use ā¦ https://youtu.be/Kdn8kFeEGkw
tnx, @espenmn ! and have a nice vacation
Agreed. For SSR the Blocks white paper still feels valid. Although, I wonder, am I still the only one running that with ESI? With ESI it also simplifies more complex things like customization: Varnish supports recursive ESI. Therefore we were able to implement cached customizable tiles easily. The first tile rendering just renders a new ESI tag with the options user had selected and all users with the same selections would get the same cached version.
A bit late to this party, but I have developed calmjs as a solution for the organisation I work at, but it is done at the Python package level for the most general solution. Along the lines of what others have said, we also took the same approach where front-end only packages are placed onto npm while the Python packages make use of calmjs to declare dependencies upon them, and with the help of additional calmjs packages that provide additional integration, such as for bundling with webpack/r.js or testing across all browsers with karma. Any additional JavaScript sources that must be shipped with the Python package (for final integration) can also be used, tested and bundled by this integration package.
The key issue that really got me started working on this was that Python package/framework developers never provided a good cross-platform/framework integration with external tools, such that we are now stuck in a situation where Django JS sources and Plone JS sources can't be reused in a more general manner, whereas with the use of a more generic integration at the distutils/setuptools level would have make this at least possible with much lesser effort.