Self-updating means that WordPress needs to be allowed to write to more places than just the "uploads" directory. Which is frightening, and a security risk.
Yes, but non-self-updating means tons and tons of sites run by lazy people end up sitting out there on ancient, known-compromised versions of WordPress forever, which is also a security risk (and arguably a bigger one).
It's a pretty safe bet that it will be in the US in the next 15-20 years as well (I know that's a sad time frame; the US has to reshape a ~$4 trillion entrenched market, which will take time). I say that based on the trends in the healthcare market. Insurers are being squeezed out of the bottom 2/3 of the market. It ultimately leaves only government coverage as the viable option for most people. About half of all people in the US currently receive some variation of government health coverage. Government-based coverage will continue to gradually walk its way up the income ladder by necessity due to costs.
Republicans were entirely unable to end the ACA, despite majorities & the Presidency. Its latest enrollment period saw a massive sign-up. The likely scenario coming up near-term, is Democrats take the Senate & possibly the Presidency (not the House). Healthcare will see gradual stapled on improvements that basically guarantees everyone coverage. Each time the Democrats acquire majorities, they'll put more pieces into place. It's most likely to start out as guaranteed catastrophic coverage for the middle & lower middle class (poor people already have free healthcare), that's the next logical step from the components the ACA put into place. It'll be a messy process, that will ultimately end in guaranteed coverage (most of the top 1/4 will keep variations of employer coverage that provide various perks). As each of these pieces get put into place, Republicans will find it nearly impossible to take them back away from people (as we just witnessed, it was wildly unpopular when Republicans tried to get rid of denial of coverage protections for pre-existing conditions).
Even the demo http://demo.django-cms.org (good luck getting in at the moment, though) shows how django CMS can reuse structured data from multiple applications that also integrate with its editing and publishing tools (in the demo, news, people, events, jobs, etc).
There are biomedical labs for example that use django CMS to publish information automatically. Obviously django CMS itself knows nothing about biomedical data, but it provides the tools that make it very easy to integrate those applications (which thanks to Django are themselves very quick and easy to build).
Then why doesn't the interface reflect the building blocks of the structured content?
Where the video says "The Django CMS interface", the interface is clearly page-centric, not structured content-centric. It has building blocks like "feature-visual", "bg-home.jpg", "feature-content", "container", "row", "column col-md-24" etc.
How is that structured content?
Perhaps it can do structured content, but then why doesn't the video put that front and center? Is this perhaps an "also" feature, for building landing pages? Then why does the marketing talk about "content editors"?
So perhaps it's just the marketing that oversimplifies things? :)
I've just gotten my first exposure to actually writing D8 code in the last few days. IMHO, you're allowed and thank you SO MUCH for this release.
I've been one of the skeptics on how big a change this was going to be for years, but now having looked at the delivered product I'm really impressed and really excited to move some old projects into it.
Probably because your comment is incorrect. Django-CMS is almost exclusively structured content, and since it's essentially an extension of Django, you can use standard django models within the CMS.
If you want more of a page based CMS, check out wagtail. Also pretty awesome, although in very different ways.
Not sure who down-voted you. In your defense you did qualify your statement with "...as demonstrated in the video...". I suspect the DV'er thought you made a lot of bold assumptions though, based on that one, single video?
This does not explain how the client-side cache is kept up-to-date. Cache invalidation matters. You want instantaneous updates on the client if the data has been updated on the server.
E.g. What if the like count has been updated?
Curious what solutions GraphQL offers for this. If it doesn't solve this itself, then what do GraphQL apps do today to solve this?
Facebook does have an internal solution for push updates, I believe they use long http requests. There were some talk of relay adding support for updates via websockets, anyone have any information?