Since we usually blog or tweet about plone.restapi updates and planet Plone currently does not aggregate our company blog, I will start a new discussion thread here with updates on plone.restapi and the headless CMS idea.
Beethoven Sprint Bonn:
In March 2017, 14 Plone developers from eight different countries gathered in Bonn to advance the vision of Plone's future as a headless CMS.
Thanks for putting that up. It seems to be very heavy on the "what" and not on the "why". The why section seems to be
Web technologies continue to change at a very high pace and so does the CMS market. Traditional Content Management Systems have a hard time finding the balance between the stability that is required to manage long living content on large projects and the requirements of modern websites and with state-of-the-art JavaScript front-end technologies.
Content Management Systems need to evolve from systems that manage and render content to managing arbitrary “resources” and factor out the rendering part in order to be able to keep the pace of a fast-changing front-end ecosystem. Plone has been able to provide stability and scalability for long lasting and large projects over the last decade. plone.restapi will allow us to combine that with latest and greatest JavaScript front-end technologies and libraries to build state-of-the-art user-friendly user interfaces.
This is a bit hard to understand but I think reading between the lines the problems being solved are
our js is out of date and we need to keep pace.
build a better UI
Neither of which are "problems"
What I'm trying to understand is
what is the risk if we don't keep pace?
are we changing all JS in plone again? or just the editing UI?
What are we likely to lose?
What are we likely to have to relearn?
What is the experience going to be like for the average integrator upgrading to this version of Plone?
Will it require changes to themes? plugins?
What are we hoping to gain? Esp in regard to end each of our user types: users, integrators, plugin developers,
Is there a prediction for how it might encourage new users of Plone? Who would those new users be, how would they find out about Plone and how likely is this headless version going to complete against other headless CMS now and being developed?
The new UX: Is there a set of known problems it is designed to solve?
Is the UX to change the features of managing content or is it just changing how the current UI is styled?
Optionally, disable all front-end access to the current Plone UI
That's it. Now try to imagine the possibilities. Plone becomes the backend, plone.restapi gives you JSON access to it, and you (or someone) build an application on top of it, which does not necessarily have to be a CMS.
This is not a new version of Plone. Nobody is changing the UI, UX or the JS (yet, though there were discussions at PLOG about the resource registry, but that is completely unrelated to headless, and I'm sure there will be a separate report). It is a different offering with "Plone inside". In the short/medium term, this is not going to impact current users, integrators, developers and clients in the least. Nobody is required to relearn anything or upgrade to anything. It's a different market, and if you want to play in it, then you can learn plone.restapi and use it for the framework of your choice.
Here are the use cases for Plone + plone.restapi:
Plone classic, as we know it and love it. Same market, same clients, same users, same problems. But you can already make REST calls for your own purposes.
Build a different public front end, and use the classic Plone UI as its "admin interface" for editors.
Ignore the Plone UI completely, build everything from scratch.
Victor and Timo's post also talks about switching backends, so that's another aspect. We'll see.
In the long term, the availability of this model will no doubt spark changes in the Plone UI itself, and then your questions will be relevant. In particular, I think nobody really has an answer to how add-ons will need to be written to plug in to Plone in this model. We are just not there yet. However, there are already experiments under way, for example, Rob Gietema is rewriting the Barceloneta UI in React. But I'm not sure if this is anything more than a demo, cool as it is. But I think it's too early to freak out.
Ok, I just looked back at the blog post and realized there is a large section at the end about Pastanaga. This is a proposal for a new UI for Plone from Albert Casado, who is a UX designer, esteemed and known by many of us. There was much enthusiasm for Pastanaga at PLOG, but also no decision about it. It might become the new theme and UI for Plone 6 or 7, it's all completely open.
I just want to clarify that this UI and Headless are completely orthogonal topics, for now, so it would help discussions if we did not mix them up.
restapi is fine. I get that. It was all the rest of "future of plone", changing the UI, upgrading how JS is done etc etc that I am trying to understand. There is where a lot of effort is doing into it seems.
I'm trying. no one is freaking out. Just concerned that this all seems like a lot of effort so its for everyones benefit that we spell out the benefits and risks right? I'm not trying to give stop energy, just trying coax some more of the conversations out of PLOG that are obviously not said explicitly in that blog post so I can understand.
@djay the main take away, I was in PLOG but not much involved in restapi/headless discussion, is that with the very same Plone you have yet-another-way to do things.
In this case, as is aiming to be a complete layer of abstraction, you can start thinking that the only language a backend and frontend developer will ever have to speak to each other is plone.restapi, no more templates, no more portlets, no more diazo...
Of course that will be your choice, if not, you can happily ignore it, or do a mix of it and do some parts with restapi, some with traditional server side rendering.
@gforcada. so its not the "future" of plone then... its another set of things to understand for some specific use cases when you want create a SPA with plone?
If the whole Plone editing UI is being recreated again in react, surely that means there is a plan to drop the existing code for the editing UI right? If so, any plugin developer has to develop using react right if they want to have some editor facing UI? It seems supporting two editing UI's seems a burden right so that doesn't seem to make sense.
But there will always be support for diazo, theming, portlets (or mosaic) and public frontends that don't require JS for published content correct? Also for password protected intranets? What about patterns? Front facing JS? is the idea to phase that out?