Epic: Modernise CMS UI Technologies

[sminnee]

SilverStripe foundational CMS UI technologies are 5-10 years old, and are largely based on an abandoned internal project by our former CTO (Entwine). In 2015, we've started removing this technical debt through the new assets and campaigns sections, with a large investment into new tooling. This effort has often been synonymous with a "React GridField", but goes deeper in how the CMS is built.

It is important to complete this effort by rolling it out to the main CMS sections. This will provide a consistent developer experience for customising the CMS.

Benefits:

• CMS Authors: Faster UX, easier addition of modern approaches such as offline support, background refreshes (web sockets)
• Community Developers: Reuse existing frontend knowledge for CMS customisations
• Product developers: Faster turnaround for new UIs
• Product designers: More consistency and collaboration through component-based implementations (pattern library)

Risks:

• Any delay drives us to new UIs (e.g. content blocks) in old technologies (Entwine), or a hybrid approach that's brittle and will become a maintenance burden
• Higher level product efforts (e.g. content blocks) can get blocked by unexpected core work to support the required UX under React
• Since this effort will affect basic development activites (e.g. adding a new field), hence is hard to introduce in small increments: API changes are only allowed in major releases. We need to investigate if its possible to run a parallel, optional module with 4.x compatibility, without duplicating efforts

Note: Please install zenhub.com to see tickets associated to this epic.

[micschk]

Not sure where else to leave this, but as a developer I'm finding it increasingly cumbersome to work with/around react in Silverstripe. The whole react 'ecosystem' is overkill for most of our own projects (for our front-ends the benefits are not worth the hassle) and we're usually (still) managing just fine with a mix of plain JS, jQuery and VueJS.

I know Silverstripe has chosen to adapt react for the CMS/admin area and maybe I'm just getting old, but I find having to work with react in order to be able to make tweaks or PRs, quite a barrier (actually keeping me from contributing). Also it seems basic stuff like tag-field, password-field, toggle-composite-field, just to name a few, used to be way easier to use outside the admin area in non-react projects. I'm now finding myself having to re-create basic functionality which has been locked-into react, or having to update this functionality from older SS3 JS. It's also not as easy to lookup the JS and see how it works/how to tweak it in SS4 anymore, since only the minified JS is included.

Of course the whole framework and also the admin has become a lot faster due to the react/preprocessing tools in use (besides general php improvements). But for us (tiny team), the most valuable USP of Silverstripe used to be its simplicity & extensibility - being able to add simple custom functionality easily, also within the admin area with stuff like betterbuttons. Currently it seems you first need to add/extend five different classes of PHP, install a set of blackbox preprocessors and languages and be a front- and back-end virtuous in order to use some react hooks just to tweak a few behaviours or add some functionality within react-based areas.

Effectively it seems Silverstripe has become a much better/faster CMS, but the CMS & admin areas in exchange have become less easily tweakable and also less welcoming to starting web devs (IMO).

This is meant as a signal, not necessarily as a complaint :-) I'm curious to hear how other devs think about this.

[michalkleiner]

I'd second that, @micschk. Well written.

[IsaacInsoll]

I agree with @micschk

[christopherdarling]

Agreed here too tbh.

[lerni]

The discussion or the comment here say similar things about customizing the CMS: https://forum.silverstripe.org/t/introducing-typescript-to-our-front-end-stack/2692

I really enjoy the CMS improvements but also agree with both posts in regards of customizing the CMS.

[micschk]

This is not meant to insult anyone, and I appreciate the hard work a lot of devs are putting into Silverstripe, as well as Silverstripe the company making it all available open source. But long story short; for us as a small development company, Silverstripe is currently losing some its strongest selling points. For client-businesses the best aspects of Silverstripe used to be its stability (tech stack wise) and the relative simplicity to develop valuable functionality for clients on top of the framework & CMS.

It's currently becoming more and more of a burden to maintain existing client projects for us as the technology stack seems to keep growing and existing projects needs reworking over and over between updates. For example we recently got budget to update a client project to v4, only for it to need work yet again within a few weeks after finishing because some components/module having switched over to GraphQL/react. Details spared, but this situation is very hard if not impossible to justify to a client which I have just convinced to do the initial update so the system would be future proof again for a couple of years.

Another example I recently came across is a (much appreciated) writedown by Adrian of the steps required to create a module for a combined text input + dropdown field. I cannot help but think something basic like this should never be that much work/involve that much coding languages and could actually be accomplished in only a few lines of php, one template file and maybe some JS in previous versions of Silverstripe?

I have spoken to a few developers about this and it seems this sentiment may be shared. Personally, business-wise I feel it would almost seem feasible to create a "community fork" of SSv3 as feature wise not so much has changed since then (not to say V4 isn't better in a lot of areas, but from the perspective of a client they can manage their content equally well in V3 and I can sure develop a lot faster on top of it).

Just look at the amount of "meta" files recommended to include in a basic module (from module skeleton). I'm afraid this is undoable and unmaintainable at least for us. And this doesn't even consider the front-end preprocessors etc required...

I've made this comment on the forum here and there as well, but I'd be very interested in an assessment by Silverstripe, of the amount of time/work actually spent on converting everything to react over the past years (including the all the GraphQL stuff). I doubt it still warrants the anticipated benefits (not sure what these actually are/were other than just replacing Entwine), and we're only even half way done.

Besides that, I hope for other (community) devs to chime in on these issues... (Sorry to spam) @joshkosmala @jeffwhitfield @undefinedoffset @dnadesign @wilr @tractorcow @jonom @colymba @bummzack @stevie-mayhew @sheadawson @ryanpotter @lekoala @heyday @bringyourownideas @axllent @silvershop @phptek @kinglozzer @unisolutions @thewebmen @pstaender @oddnoc @nglasl @markguinn @littlegiant @gorriecoe @briceburg @bigfork @benmanu @betterbrief @silverleague @zauberfisch @webbuilders-group @sunnysideup @stojg @richardsjoqvist @plato-creative @littlegiant @i-lateral @fullscreeninteractive @dynamic @firesphere @adrexia @xddesigners @wernerkrauss @titledk @toastnz @syntro @spekulatius @nyeholt @meldgaard @markguinn @sminnee @camfindlay @patjr

[lekoala]

@micschk I tend to agree with you. Some things that used to be easy in SS3 are more difficult in SS4. For me, there was not much added value in the new paradigm. I don't like react or graphql, and as a php dev, I don't like to have to bundle, build and process js files.

However, it's still possible to use "old ways" in the admin side once you tweak things a little. For instance on my base module, I've built a simple (and a bit hacky) jquery plugin that is in charge to apply jquery module to a given html node (https://github.com/lekoala/silverstripe-base/blob/master/javascript/ModularBehaviour.js). It's basically what powers all my custom form fields (like select2, cleave, inputmask) and, as a added bonus, it's usable on the frontend as well :-)

My main grief is that developping things for the admin side is most of the time not applicable on the frontend and vice versa. At least with my method, I can have one code that apply everywhere. Of course, I'm locked with my current technology but since that's my methodology I'm happy with it.

I also believe that it would be nice to have some work done on a community fork of ss3, i have some big projects that are just too big to migrate so for me it would make sense to improve things on the SS3 side of things as well. I still hope that it would be possible to FINALLY upgrade jquery since it's super easy to do and only require dropping IE which is acceptable these days.

[kinglozzer]

In terms of why we’re moving away from Entwine and jQuery, @micschk described that pretty well above. Performance, security, maintainability (yes React is complex, but Entwine is a black box that hasn’t been updated for 5 years) and extensibility all factored into that decision. I think everyone would accept that something had to change, so then it comes down to choosing a tech stack. Given the complex UIs in Silverstripe, we needed a modern component-driven library with some beefy state management: React & Redux fit that description perfectly and have enabled some brilliant new functionality since. Yes there are alternative libraries, but without going through the same (very long) journey with them we’ll never know if they’d make these problems better or worse, or introduce their own problems.

The whole react 'ecosystem' is overkill for most of our own projects (for our front-ends the benefits are not worth the hassle) and we're usually (still) managing just fine with a mix of plain JS, jQuery and VueJS.

Yeah we’re in the same boat - VueJS + GraphQL is as complex as our projects really get with regards to frontend stuff. That’s probably part of the reason React can be off-putting for contributions: we basically never use it in our projects, so it’s unfamiliar, and to then jump into a really complex React app like the CMS to make a “simple” change/fix is difficult.

For example we recently got budget to update a client project to v4, only for it to need work yet again within a few weeks after finishing because some components/module having switched over to GraphQL/react. Details spared, but this situation is very hard if not impossible to justify to a client which I have just convinced to do the initial update so the system would be future proof again for a couple of years.

Sorry that you’ve had that experience, but for balance I would like to say that our experience of updates has been very smooth ever since semantic versioning was introduced. I haven’t seen many complaints about updates breaking things, so hopefully that experience was an unfortunate one-off!

Another example I recently came across is a (much appreciated) writedown by Adrian of the steps required to create a module for a combined text input + dropdown field. I cannot help but think something basic like this should never be that much work/involve that much coding languages and could actually be accomplished in only a few lines of php, one template file and maybe some JS in previous versions of Silverstripe?

That’s partly because we’re still in the awkward position of being part-React rendered, part server-side rendered. You need a PHP file for field scaffolding and a React component - ideally that would be all you need to build a CMS UI component. Right now the .ss template and Entwine code are required for “legacy” CMS contexts like pages/modeladmin. That sucks, but I’m not really sure there’s anything we can do about it short term.

I doubt it still warrants the anticipated benefits (not sure what these actually are/were other than just replacing Entwine), and we're only even half way done.

I disagree - I think we’re still only seeing some of the benefits of the newer UI technologies. Compare the old assets section to asset-admin for example, or the old elemental to the current one: if we see the same sort of improvements across the board in the CMS, I think we’ll be very happy.

Also it seems basic stuff like tag-field, password-field, toggle-composite-field, just to name a few, used to be way easier to use outside the admin area in non-react projects. I'm now finding myself having to re-create basic functionality which has been locked-into react, or having to update this functionality from older SS3 JS.

My main grief is that developping things for the admin side is most of the time not applicable on the frontend and vice versa. At least with my method, I can have one code that apply everywhere.

I’ve recently become increasingly happy to accept modules that only work in one context: otherwise you end up with, for example, form fields that load a legacy version of jQuery and Entwine into my otherwise nicely optimised site. Ultimately as the CMS moves over to be more and more React powered, I wonder if we’ll see modules diverging into CMS-only modules and frontend modules?

We’re in an awkward place where being partly React-driven and partly Entwine-driven makes development & customisation of CMS components more difficult than it needs to be. All the while Entwine is lingering in the CMS, people with existing Entwine-compatible modules will likely do the bare minimum to get them working and then leave them. I know that, because that’s exactly what I’ve done with some of my modules!

I think we need to focus on finding specific issues devs are having when writing React code and see what can be done do to improve them.

[UndefinedOffset]

@kinglozzer to your last point about where devs are having issues. Here's a couple off the top of my head:

1. Installing the nessicary packages to build dev builds of the admin module's JavaScript bundles (see point two) fails on windows due to the silverstripe webpack-config package. I can't give you the specific error because I'm away from my primary dev environment at the moment (yay vacation lol). But if memory serves its something to do with the bin folder in its node modules I think around a binary missing in there? I'd have to try again to be sure.
2. The errors that come from the production builds of the components from the admin module are petty useless for troubleshooting problems. "a is not defined" doesn't really help much, when the real error is related to a property of that component being required when the readme for that component doesn't mention that.
3. Docs in general for extending or using the built in react components could use some love, especially for people new to react and that whole workflow. For the former more easily accessible docs (say on docs.silverstripe.org not just buried in the source repo) for what components are exposed for use though injector as well as how to use them would be helpful. If the latter it could be as simple as some links to resources elsewhere on the web to understand how to get started with the concepts. But it could also be improving the existing docs so the are a bit clearer and simpler for someone just getting going with the concepts.

Just a couple thoughts off the top of my head. I know when I started working with react for stuff like webbuilders-group/silverstripe-add-to-campaigns it was hard to get my head around things based on the docs.

[Firesphere]

I think everyone would accept that something had to change, so then it comes down to choosing a tech stack.

I do not disagree with this, it is absolutely a fact that Entwine has become the primary "Technical debt" in Silverstripe. However, although I obviously never had any input in the choice to use React for the CMS, I have found that a lot of web agencies are starting to shy away from Silverstripe, because of this decision.

The reason being, is that the easy way it was to add, change or update fields, as described by @micschk , has become a burden. One of my last jobs as a fulltime web engineer, was upgrade a very complex CMS build, to Silverstripe 4. The change to use React, the renewed search field implementation, and the general changes that came with it, were so complex, that I am at this stage unsure if the project ever finished due to this complexity.

---

With VueJS, Vanilla JS, Angular JS, Backbone JS and of course jQuery, even engineers that used to primarily do PHP/backend things, now had to learn 2 or 3 new javascript frameworks, only to be able to a simple task of a customised field. for example, fields that rely on jQuery to function (for example Select2), then possibly a React component to actually show the field, and of course the PHP backend to render the field template. This has become a behemoth of requirements for a simple task. (As per Adrian's post)

Another issue I have with React, is it's complexity. I have worked with VueJS, Angular, Backbone, jQuery and Vanilla JS, but never have I found a library so complex as React. I am personally not a frontend expert (really, don't ask me to do a pure design/UI project! :P ), but the time it took me to understand the basics of the libraries mentioned, was a lot less than when I even touched React. As I am not a software engineer anymore, I do not even want to touch React on any hobby project I have. If needed, I'd rather hack myself around it, than needing to learn React. It's not worth my time.

I absolutely agree, that a single library, with a consistent implementation in the CMS is a good thing, but the benefits of React, to me, do not outweigh the amount of overhead it brings to the people that have to work on custom Silverstripe CMS implementations. It is however, at a massive cost to the community.

When it comes to the usage of javascript, I've learned a motto from one of my former colleagues, Jess: "Your javascript should not exceed the size of the original PacMan" This mantra has stuck with me. But by now, a lot of websites, be it the frontend or the CMS, require you to download multiple megabytes of javascript, only to display a single form field or image.

In part, this is also due to the javascript ecosystem, and the amount of libraries out there. And I'm not even kidding, BananaJS exists. The javascript ecosystem is so volatile and constantly changing, it has become impossible to keep up with.

// More to come // ping @elliot-sawyer

[sunnysideup]

Awesome discussion. Thank you all for your ideas and candid sharing of highs and lows.

I don't have anything important to add, but would like to add a few notes in case it helps anyone.

Also, I think we should add @unclecheese and @chillu to the discussion.

In order for Silverstripe to survive we need to:

A. Tap into the rich tapestry of PHP packages - hence SS4 has namespacing and we use composer.

B. Tap into a rich front-end framework, like ReactJS.

C. Get better at creating and finding existing modules (we are doing our bit with http://ssmods.com).

This takes us away from the lovely ecosystem that was SS3 where you understood almost everything under the hood and you could tinker to your heart’s content. However, I don't think that is viable anymore as we would simply end up more and more behind. Believe me, I totally understand the frustration of being thrown into these giant systems and feeling utterly lost. I do too! But going back to SS3 definitely seems like a bad decision.

Secondly, for better or worse, ReactJS has been selected as the front-end framework of choice. I have never written a line of ReactJS in my life, but my team has and I generally get a sense it is a good choice. It could have been worse! It is more how we use it that is the issue I feel than React as such.

Also, when I look at shopify, they are super proud of having a GraphQL Api - and so should we. Let’s make it fly!.

Next steps, as I see them:

1. Get rid of entwine, urgently, as it seems to be an ongoing excuse for anything awesome. What are we waiting for?

2. Write quality Docs for the CMS in relation to ReactJS, etc… and a few example projects for good measure.

3. Build more scaffolding and guiding in the code itself so that the setup is not so cumbersome, “random”, and magical for CMS components. The way the private statics work for DataObjects is the way to go I feel - i.e. a few settings create a lot of code.

4. Make it super simple (i.e. opinionated) in the way we work with ReactJS so that anyone can do it and there are clear steps to follow.

5. Don't forget about our shared goals:

   • make a CMS that is awesome for content editors
   • Make it FASTER to develop custom CMS implementations

If there is any CMS that does this better than Silverstripe? If so, how can we make use of their ideas and code?

A couple of things I would like to improve, with a magic wand

While we are talking about the CMS, here are few things I would love to see in the CMS. I think it may be of use here as I am curious if any of you see this differently and what else may be important, in order to consider how “new” / “old” ways of doing things may help us get there.

1. more use of icons, for all the obvious reasons. Every DataObject should be able to be assigned an icon out of the box and these icons should be everywhere as this would make things much more visual and easier to use in the CMS.

2. make it super easy to have step-by-step screens in the CMS that are a bit like the Windows Wizard I remember from 20 years ago ... Step by step completion of key data.

3. have a super simple way of implementing ajax reload anything (this is React I guess). Maybe we can have some basic code generator to set up the basics?

4. Often it is hard for a content-editor to see how the front-end relates to the back-end. For this purpose, I recently wrote: https://github.com/sunnysideup/silverstripe-elemental-edit-me-button. If logged in, you can now click on an edit button in the front-end to go straight to an elemental block to adjust it, with the option afterwards to return back to the front-end. The reason for this is that a common work flow is something like this:

a. editor reviews front-end b. editor realises something needs to change c. editor goes into the back-end and has a hard time finding what needs editing (gives up and gets frustrated).

The disconnect between the front-end and back-end is a big issue I feel.

5. We need a single line HTMLEditor that just works out of the box without much effort so that we can make it easy to edit titles with multiple colours, etc...

6. The paradigm in the CMS is: edit by record. I feel we should have, out of the box, a system that allows you to edit by column (e.g. edit all Meta Titles on the site, in one go). We have tried to build this in the past: https://github.com/sunnysideup/silverstripe-dataobjectsorter/tree/master/src. I feel this approach could work nicely for a lot of user stories - e.g. I want to review what pages have “ShowInMenus” ticked and adjust a few.

7. We need to focus more on front-end editing. We wrote a module for that in SS3 (https://github.com/sunnysideup/silverstripe-frontendeditor) and actually found that you can create a beautiful editing experience on the front-end, pretty easily (tapping into the getFrontEndFields method (or something like that)). Taking this one step further, you can also look at SquareSpace and see that they do what is best: content editors edit things in situ, rather than in a separate CMS part (i.e. you see something, you click on it, you edit it, save and done). Of course there is a place for both, but I was interested to read about the idea that CMS fields do not work on the front-end. I think that is a missed opportunity.

8. The gridfield header needs work, e.g. add existing related records (and remove it) is hard to understand for users, search is messy, etc… Having an amazing gridfield is the key to success. Most of the gridfield works awesome and enhancing a few tricky bits with make a world of difference.

9. Ability to link to a specific tab in the CMS (e.g. www.mysite/admin/edit/Page/1#socialmedia, would take you straight to the social media tab on the home page (in the CMS)). This should be a matter of three lines of JS (i.e. check for hash, check if hash corresponds to tab, click tab…, when tab is clicked, push hash to URL). If I knew what JS file I could edit, I would do it tomorrow ;-) The reason this is super useful is that you can send a client straight to a tab to edit something.

10. I recently tried to set up a "view history" field in the CMS (similar to the SiteTree History tab) and this is when I saw the spaghetti of code changes required to make it work as I think some of you describe above. Be sure, I did not implement it. It looked like too much work and too many things that could "magically" break. This sort of stuff should be improved!

Our involvement with creating a custom CMS experience

We have not been involved much in making anything for the CMS itself. It is basically too hard for me. Even in SS3 this was hard. Sure, we have created lots of CMS fields, of all variations, but doing anything else often ended up in the too hard basket. The main issues we found:

• hard to include additional CSS / JS properly (massive block of HTML, hard to understand how existing JS / CSS was all working together and how to make specific CSS load in specific places).

• it was tricky to have stuff updated before a full reload. I think that is really at the crux of a CMS logic. You want it to have that App experience where you update something and everything instantly knows about it.

  • it is hard to add buttons that do stuff, especially async.

  • advanced validation is hard to implement.

What we often end up doing is to create custom front-end solutions for editing custom stuff - e.g. prices per country for e-commerce (stuff that should really be done in the CMS) and simply linking to it from the CMS. Unfortunately, while the individual things may have worked, this does not look very professional for the client - i.e. having the same look and feel as the CMS makes it feel more connected.

Having said that, a few months ago, I wrote my first Left And Main, ever, and it turned out to work really nicely and be simpler than I thought. I could not find any good documentation, but I simply copied another Left And Main and worked it out: https://github.com/sunnysideup/silverstripe-site-wide-search.

Examples of other things we have done to make the CMS better:

• cms edit field (button that makes it easy to let content editors edit a related object and lets devs create links within the CMS to various records, without too much thinking).

• make pages sortable in list view (as opposed to sitetree view)

• a bit of CSS to make the grid fields easier to understand (they often seem so spread that it is hard to see them as one thing)

• add field_right_titles as a standard private static so that fields are more descriptive for content editors and devs can add these more easily.

• add a checkbox set for many-many relationships where there are a limited number of records (to make the selection way faster).

  • perfect cms images: tell content editors exactly the perfect size for uploading images (enforce, if needed), etc...

  • site wide search: allow a content editor find any record that contains a certain word of phrase (great for find and replace).

None of these are very serious changes and I feel the reason we have not delved deeper into it is because we assume it is too hard, based on the few forays we have had into the deeper layers of the CMS.

What may also be of use:

Also, what I found weird is that each project and every module has its own webpack. Hence I developed an independent webpack module: https://github.com/sunnysideup/silverstripe-sswebpack_engine_only. The way it works is that it separates webpack from individual projects and modules. It needs work, but I like where it is going. We basically have one webpack that is simple and works, we take it from project to project and improve it as we go (and back-port those improvements to previous projects). Yes - you can still add your own vendor modules as you see fit, etc…

Also, we keep working on our SS4 upgrade module: https://github.com/sunnysideup/silverstripe-upgrade_to_silverstripe_4 and I would really encourage anyone to reach out if you want to use it. It makes upgrading less costly.

Lastly, I have been working on this module: https://github.com/sunnysideup/silverstripe-modulechecks. It is in a complete mess, but my long-term goal is to have some sort of automation to keep our modules up to date. It will work in conjunction with https://github.com/silverstripe/silverstripe-module.

[spekulatius]

These days my work focus switched to more to Laravel, I'm still a big fan tho :) I think, most here agree that we seeing strong improvements with v4 and addressing the tech debt is due. No doubt it's a big move forward and should be kept in mind as this. Change is never painfree and I can relate to many of the feelings shared above:

I can relate to @Firesphere' thoughts on React tho. Sure, it might be your natural choose if you know React and the large ecosystem well. Otherwise maybe less so (due to learn curve, complexity, etc.). At the end, most of us start to see everything as nails to some degree. It's part of human nature to develop preferences.

I wonder how many SilverStripe devs saw React as a suitable solution for a website when v3 was at it's peak? My gut feeling tells me it wasn't that many. I still see jQuery regularly. My work is mostly with Vue (and Alpine for simple websites) these days. For me personally, I wouldn't pick React for most sites as it doesn't feel like a good choice for the regular "bunch of pages with three forms and a newsletter modal"-type of website.

The introduction of React moved the SilverStripe community into a new direction. For some people it might have got more attractive and for some less. That's what any large change does. I think devs who choose jQuery/VanillaJS/Alpine/Vue "to do something quickly" on the frontend won't be starting to learn React. I'm in the same boat as @Firesphere here. From a purely technology-based point of view: Is SilverStripe more attractive for React developers now or is the community benefiting otherwise (more reach or external contributions)? I can't speak about community benefits as I don't know enough about this. A biased feeling regarding this: I feel React devs are more deeply rooted in the JS space (than for example Vue/Alpine devs) and less inclined to use a PHP-based framework/CMS. If holds true, it probably limits the benefits for SS.

How to deal with this? Well, I don't think there is an easy answer. But here are some thoughts:

Laravel takes an interesting approach. It's coming with Laravel Mix - a wrapper around webpack which allows you to isolate the JS world somewhat and giving you a simple helper to handle and extend frontend. Maybe this is an idea to help smoothing the rough egdes of JS world for SilverStripe devs? I follows the idea just minutes ago posted by @sunnysideup.

I'm not sure a community fork of v3 would get more than the bare minimum of security fixes. Even these would fade out at the end. Plus the same core issue remains: Entwine is unmaintained. So sooner or later it would have solve the same problem the main project already works on. It would have the free choice of options tho and maybe could address issue differently.

So much for my two cents.

[bummzack]

While I haven't built any new SilverStripe projects for quite some time now, I still do maintenance and support for several of my previous projects (SS3 and SS4 based). Personally, I've always liked the roadmap that SilverStripe took for SS4 and onwards. Being more modular and using a modern frontend stack.

I have made the switch from SS3 to SS4 while I was still working as a self-employed developer, doing everything alone. I agree with the sentiment that it was quite a big leap from SS3 to SS4… some things seemed very familiar, others have changed completely. Most notably the new frontend stack. That means, that it also resulted in an increased learning-curve, especially if you had to customize frontend and backend components (for example as a module maintainer).

I was always invested in frontend technology, that's why I already gathered some React and Webpack experience, before SS4 was a thing (building a React driven frontend with an SS3 backend). Maybe that eased the transition a bit for me…

I still believe SilverStripe is on the right track. While it might be harder for a single person to tap into all the different areas of the CMS, it also gained a lot in terms of maturity. I personally prefer a clearly defined frontend-stack based on a framework that has a huge user-base and ecosystem (React) over some self-built wrapper where every module can load/include any code it wants. In addition to this, the users expectations when it comes to frontend-tech has grown rapidly in the last years, so I'm happy that SilverStripe addressed this.

I personally believe that we'll see a lot more headless systems and sites built with JAMStack in the future and I'd much rather use SS4 than SS3 for that…

[christopherdarling]

I agree with the above, I'm not that familiar with React and don't use it on my projects but I understand the reasons behind choosing it for the CMS.

I think we're mostly just missing documentation, examples and tutorials to make it easier for those devs to get familiar with how SS uses these technologies.

Overall, I still love SilverStripe and where SS4 is going and really look forward to the GraphQL updates and speed improvements that are being worked on.

💌

[axllent]

Personally I do not use (or even like working with) React, however I understand the reasoning for choosing a solution like this to modernise the CMS. The Silverstripe 4 CMS is in my opinion a huge visual improvement compared to v3. It has however come at a technical cost, that being the push for module developers to use React, and adding a complexity in just getting stuff done for developers (as pointed out in earlier discussions). The documentation regarding this is also all over the place, and still promotes "jQuery, jQuery UI and jQuery.entwine: Our libraries of choice" together with multiple jQuery & entwine examples, so this remains confusing. I'm not particularity a fan of jQuery, but it's simple to use and functional, and more importantly universally understood.

Knowing where the CMS is headed has meant that I have shied away from creating things in the CMS that may need custom JS, and for where I absolutely need it, I still continue to use the jQuery.entwine method to fire events when the CMS section is loaded (ie: $(document).ready() will only fire once on the initial CMS page load, not when a view is reloaded after save, or clicking around in the SiteTree between pages).

So from my perspective, ripping out entwine is fine (if it is such a technical debt), as long as there is an alternate method provided for module developers to hook in regular (non-React) JavaScript functionality into the CMS, triggered when a "React-loaded page" finishes loading. My impression (correct me if I am wrong) is that the intention is to shift everything (in the CMS) to a React-only environment, and if this is true, it is potentially going to hamstring a lot of developers such as myself. I am sure that React has made Silverstripe's life easier in achieving consistency (and speed?) throughout the CMS, however React is not simple to learn, and in my opinion not simple to implement.

As a developer I want to create a CMS module, and if it requires some additional functionality, add that functionality inside a simple readable JavaScript file if I choose to. I do not want to have to deal with complete libraries, create components, set props, inject other stuff, compile bundles in node and whatnot, all to simply display a simple character counter next to an input field. My apologies if my terminology is off, but you get the picture. The CMS needs to remain flexible enough for developers to hook in other JavaScript into the ecosystem.

[bummzack]

I don't think React is inherently hard to learn/understand. Sure, it's a bit more involving when it comes to state-management and especially tooling. When it comes to CMS customization, good tooling and documentation would go a long way to make it easier for developers. I recently did some tinkering with the strapi cms and they make it really easy to replace UI modules… you just create the same folder-structure/filenames in your project folder and it will replace them. I think this works with some NormalModuleReplacementPlugin trickery…

[Acen]

I don't think React is inherently hard to learn/understand.

I'd argue for anyone coming from a vanilla JS/jQuery standpoint, anything that requires a build system is indeed hard to learn and/or understand.

My big takeaway from managing elements within the CMS is the amount of cruft I need to write within the PHP side of my models is just a tad confusing and not easily debuggable when you're needing to work out how the CMS objects relate internally to each other. ModelAdmin flags to modify the basic details on how to select how a CMS page is managed. Extensions (to load FormTransformation classes) to choose what fields I want to display/hide/modify. More extensions to modify the filtering of what content should be showing up in my data model lists. The Form class system in general (see below).

e.g. an example of modifying the content/fields in the list page for a model:

Extension w/ updateEditForm method calling this --

    /**
     * @param FormField $field
     * @return FormField|GridField
     */
    public function transform(FormField $field)
    {
        if (!$field instanceof GridField) {
            return $field;
        }
        /** @var GridField $field */
        $gridFieldConfig = $field->getConfig();
        $gridFieldConfig->removeComponentsByType(GridFieldAddNewButton::class);
        $gridFieldConfig->removeComponentsByType(GridFieldExportButton::class);
        $gridFieldConfig->removeComponentsByType(GridFieldPrintButton::class);
        /** @var ArrayList $dataColumnsArrayList */
        $dataColumnsArrayList = $gridFieldConfig->getComponentsByType(
            GridFieldDataColumns::class
        );
        /** @var GridFieldDataColumns $dataColumns */
        $dataColumns = $dataColumnsArrayList->first();

        $displayFields = $dataColumns->getDisplayFields($field);
        $displayFields['MediaURL'] = [
            'callback' => function ($record) {
                /** @var InstagramMedia $record */
                return '<img width="120" height="120" src="' . $record->MediaURL . '" />';
            },
        ];

        $dataColumns->setDisplayFields($displayFields);
        $dataColumns->setFieldCasting(['MediaURL' => [ImageField::class . '->thumbnail']]);

        return $field;
    }

[micschk]

Very happy this discussion is gaining some traction!  And thanks everyone for a lot of great comments & suggestions as well.

One point I notice is that the arguments pro React (& ecosystem) seem to be based on some combination of:

• gain in speed
• UI/UX improvements
• and/or the need to remove the tech-dept of Entwine

But comparable improvements in UI-consistency and loading & rendering speed have been achieved in (currently still) non-react areas of the CMS. Therefore I argue that these improvements are not inherently linked to react/interaction technologies but rather have to do with visual consistency and expectations (UI - if any 'tech', I'd credit Bootstrap for this). And (loading & rendering) speed for a large part to general framework improvements. Point being I hope we can separate UI & speed (huge improvement requiring no discussion at all), from the front-end technology stack replacing Entwine.

I think a lot of pro-react arguments either; take react (& co) as a given and try to 'fix' some detail (documentation, error messages, some toolchain detail), or consider react simply a neutral/necessary replacement of Entwine. Instead, I'm hoping for Silverstripe company to take a step back/zoom out, re-evaluate this choice and consider the broader implications of this tech stack. Mainly because I think some (imo much more important) strategic implications are being underestimated (eg ROI/business-wise and developer adoption/community):

• Entwine (and jQuery) are/were quite simple to get up & running with, plus much of the results were reusable (eg TagField in front-ends) – not saying Entwine didn't need to be replaced, but the stack was (and is) functional and requiring little extra effort for even PHP devs. Effect: PHP developers feel empowered and the adoption of Silverstripe benefits/community grows
• React is much more involved (toolchain/learning) and thereby makes Silverstripe require a much bigger investment of time & resources for a lot of developers (and their clients) – kind of feels like we've dragged an elephant into the room just to shoot a mosquito ;) Effect: Silverstripe becomes more niche (a lot less PHP devs who also know React out there) and (more) expensive to implement 
• The future perspective of the other areas also switching to react poses a (business) risk as stuff might stop working when the admin area switches over (or requires additional effort to develop for both stacks) – fully replacing Entwine would be a solution (but React & GraphQL not necessary the best way to go, as per previous bullet). Effect: clients & community devs 'shying away' altogether (me included) and the ecosystem of modules shrinking as well as the community(?)
• Alternatively, trying to prevent this situation beforehand encourages working around react or even fully outside the admin area to produce custom interfaces – which kind of defeats the purpose altogether and potentially introduces all kinds of issues. Effect: extra (formerly unnecessary) work gets introduced for setting up base interface functionality for each project, resulting in additional cost for the client,  and ultimately crippling the ‘competitive edge’ which used to be Silverstripe…  

Personal preferences (of course) play a role in this discussion. React for me is something I simply do not want to invest in for the reason it introduces too much overhead and complexity. And to devs arguing React is not that complex, thank you for overestimating me but it is to me (at least for the purpose of just being able to customise Silverstripe). 

That being said, I feel/hope the arguments above, as well as the discussion in general go beyond personal preferences and/or technical fancyness.

[UndefinedOffset]

I just want to jump in on the point of loosing the ability to use some of the more complex fields on the front end. I've had the pleasure of trying to make them work outside the cms and I've got to say it's a pain. It does suck to have to either fight with trying to get the core js bundles to work on the front end to the point that in some cases either I end up looking for an alternative or rolling my own. In the case of webbuilders-group/silverstripe-frontendgridfield by default it uses the old jquery code from silverstripe 3 and removes the new filter component. It has the option of using the new react bindings but it's allot of hacks basically to get it working.

The flexibility of using fields on the front end that can also be used in the back end I would say is probably essential. Yes fields like grid field are very rarely used on the front end but not never and they do sever a purpose in some projects.

[wernerkrauss]

The great, unopinionated flexibilty of SS hits us here: there is no standard way how to do your frontend stuff and for smaller sites I don't care how the backend is knitted unless it works flawlessly as I do all basic frontend fields myself or rely on standard HTML form fields.

I wonder, if the field's javascript could be so modular, that you can use it with react in the backend and with the js framework of your choice in the frontend? So that the main logic is encapsulated in js-framework agnostic code and the integration is done in glue code. Could webcomponents be a possible solution?

I've seen some calendars or sliders (well, that are not form fields) that work either standalone vanilla or with a bunch of different js libraries.

[davejtoews]

As a developer who tries to avoid the JS side of the SilverStripe admin I share some of the frustrations expressed here. Rather than weigh in on what JS tech I think should be used I'll say that in some cases I wish that the UI was less dependent on JS. I feel like a lot of my pain points with the platform come from CMS interfaces that seem more complex than they need to be.

There are a fair number of frustrating issues I run into where the CMS seems to be working if you fully refresh a page, but if you navigate to the same place without a page load things are broken, or in an odd state. Things like, the published state of a view, or content of a relationship field not displaying correctly after a save until you refresh the page. Sometimes I wish I could just force a refresh on save/publish.

Other times it just feels as if different pieces of JS are fighting each other. Problems like trying to get a field to work in an inline GridField editor, or inline editable Elemental block. Or some weird cases where fields seem to break in some ModelAdmin views.

I hope a more standardized approach to CMS JS would resolve some of this but I also hope that such an approach leaves room for CMS views not to be entirely dependent on JS to render.

[jonom]

On the choice to use React: I would say you can't build a modern, complex CMS without some kind of stateful library (React doesn't like being called a framework 🙄) like React. When I started using React it was a big paradigm shift for me - the possibilities it opens up for front end application development are amazing. React is a low-level library compared to other options which are more opinionated / batteries included. That probably does make it harder for new devs to learn, but it also means the greatest flexibility for core devs.

Long-term community health: Embracing GraphQL (and a modern tech stack in general) can make Silverstripe a viable contender as a headless CMS. Silverstripe has enjoyed a loyal following to date, but the community is relatively small and without the support of Silverstripe Ltd the product would have died (or gone stale at least) long ago. Unfortunately all the issues outlined here may be making the community shrink in the short term but I think Silverstripe is on the right path to ensure the project stays relevant and attract a new and wider developer audience in the future.

Dual-use front-end/CMS fields: As @kinglozzer said - the CMS and the front-end of your website (or whatever you are building) are different beasts, especially as the CMS becomes more modern. Reusing CMS components in the front-end could work for a React-powered website, but otherwise I don't think it's realistic in most cases. Even in SS3 days, this dual-use could mean multiple copies of jQuery loaded, or other javascript overhead, potential for conflicts, security issues etc. - basically, an un-optimised stack.

React learning curve: A lot of devs are saying they don't want to learn React just to customise the CMS. I totally get that, it takes a lot of effort to learn React. Silverstripe has a great community though, and maybe that's one part of your work you can outsource to another community member? I for one would consider focusing on this as a niche if there was demand for it 🙂. I would imagine that once you've outsourced a couple of jobs like that, you could repurpose that code on your own when you have similar requirements, and end up learning React accidentally.

Other:

I recently did some tinkering with the strapi cms and they make it really easy to replace UI modules… you just create the same folder-structure/filenames in your project folder and it will replace them

That would be awesome as an additional customisation option. If the CMS was broken in to micro-components wherever possible, that would be an easy way to make basic changes.

There are a fair number of frustrating issues I run into where the CMS seems to be working if you fully refresh a page, but if you navigate to the same place without a page load things are broken, or in an odd state. Things like, the published state of a view, or content of a relationship field not displaying correctly after a save until you refresh the page. Sometimes I wish I could just force a refresh on save/publish.

IMO, these are state issues, and these should be a thing of the past when the whole CMS is React-based. The basic premise of React is that whenever your state changes, any parts of your app that rely on that state are re-rendered, so as long as the CMS is aware that the state has changed, these issues shouldn't exist in a 100% React CMS. That said, I have experienced some issues like this even in the new assets-admin area (e.g. thumbnails not showing a published status after publishing in the detail form), but that is hopefully just an oversight that can be fixed easily.

[Cheddam]

Thanks to everyone who has contributed to this discussion - possibly the most lively thread we've had in the ecosystem since Silverstripe CMS 4 launched!

The team at Silverstripe Ltd. are reviewing the feedback here, and I'd just like to share a few specific notes.

Stability

Sam has talked about this on multiple occasions, mostly recently at StripeCon 2020, which I'd encourage everyone here to watch if they haven't already.

In short, we're really conscious that the CMS 4 upgrade cycle was tough on projects, and based on this we're looking to avoid significant breakages in 4.x upgrades going forwards. There will be some cases where we can't avoid this entirely (one example being the upcoming transition from GraphQL 3 to 4 - more detail coming early next year), but there are some changes we're pretty much ruling out in the CMS Recipe 4.x lifecycle, which doesn't currently have an end date:

• Removing Entwine / jQuery from core, or transitioning any more major features to React (e.g. the Pages section)
• Any API breakages in the standard ModelAdmin / getCMSFields patterns
  • It's worth clarifying that we don't have any plans to drop these fundamental patterns even in a hypothetical major release, but they may evolve in the future to better serve the modern stack.

This doesn't preclude the introduction of experimental replacements for CMS features that are currently based on these technologies, but those experiments wouldn't be included in CMS Recipe 4.x releases. This does mean we'll continue to retain and accrue technical debt throughout the lifecycle, but the trade-off to minimise upgrade woes has been deemed worthwhile at this stage. We encourage module developers to use the Entwine wrapper pattern to make their components compatible with both Entwine and React UIs where possible.

Documentation

The docs for the modern front-end stack are fairly monolithic, and haven't been significantly changed since their introduction. This is something we're all acutely aware of and want to see improved, and I don't think it's bold to suggest that more approachable docs would measurably improve developers' perception and adoption of this technology.

Ultimately it comes down to capacity, and when it comes to prioritisation for the Silverstripe Ltd. team, fixing bugs nearly always outweighs improving docs. It'd be awesome to see some community contributions in this space, but we'd also like to try and tackle this internally at some point (ideally before we complete the React migration!)

Migration

We've been in the 'midst' of the migration from Entwine to React for the lifetime of CMS 4, and there hasn't been much in the way of visible progress in the past year or two. To be clear, we still intend to complete this migration in the long term, and React is still the basis of our development. Introducing yet another technology, or trying to roll back to Entwine, would simply result in further fragmentation of the codebase and major toil for contributors / module developers.

Using CMS components in front-end contexts

Whilst this pattern may have been usable in CMS 3, it's not something we have the capacity or inclination to support at this stage. Silverstripe CMS is shifting towards the 'Headless CMS' paradigm that many other projects have adopted in recent times, and whilst we have no plans to drop support for SSViewer, our focus is primarily on providing a solid CMS experience and exposing a powerful GraphQL API for projects to consume content through.

It's worth noting that we have seen some success in re-use of the React components within the MFA module suite for producing a custom UI implementation, though these components are isolated from the rest of the core React suite.

Build tooling

This is a common pain point for developers picking up the modern front-end stack. I'd like to share something we've worked on to try and minimise this pain: the module skeleton.

The module skeleton repository is configured as a GitHub template, so you can generate a fresh module with only a couple of clicks, and get all of the standard configuration, build tooling, and structure laid out for you to build upon. It does need a bit of TLC, as we've shipped some updates to webpack-config over the past year, but it should still give you a functioning base to start from (and if you hit any bugs, please raise an issue.)

This doesn't cover projects and existing modules trying to adopt the modern front-end stack to customise the CMS, and unfortunately we don't have a good answer for them at this stage beyond "reference the module skeleton to set up build tools." As a general rule, I'd strongly recommend keeping the CMS build tooling separate from the tooling you use in your project themes, in order to avoid any interference when one or the other needs to be updated.

Generally speaking, unless your module needs to modify or use newly introduced JS components, you don't need to keep the build tools updated on a regular basis - the patterns we use here allow general interop between JS bundles that have been built against different minor versions.

There are exceptions, though. At some point soon we'll need to upgrade from Webpack 2 to Webpack 5, which will definitely cause some headaches for module maintainers. For better and for worse, this sort of major change reflects the cycle of the JS ecosystem. We update these libraries at a significantly slower pace than the ecosystem itself runs, for the sake of minimising maintenance effort / frequency for all involved parties. However, particularly in the case of such a major underpinning as Webpack, such upgrade cycles are inevitable. As with other changes, we'll do our best to provide an upgrade path / guide during this transition - best case scenario, modules using @silverstripe/webpack-config will be able to simply update their config files / dependencies and rebuild.

Laravel Mix has been mentioned in this thread, as an example of abstracting away the underlying tools for a simpler build tooling API. Our solution in this area has been the afore-mentioned @silverstripe/webpack-config, which allows us to share a large portion of the required Webpack configuration between modules, combined with the module skeleton, which pulls it in and scaffolds the rest. We currently have some unique requirements that would make it tricky to adopt Laravel Mix or similar tools, but it's definitely something for us to consider in the future. One question I'd like to pose here is the following: Would an explicit dependency on Node for development / deployment of Silverstripe CMS projects be acceptable? This would give us more flexibility in providing tooling that can bake together JS dependencies 'on the fly' without needing custom configuration per project / module, and could enable a similar paradigm to Strapi. (If we did go down this path, an RFC would obviously be in order, but I'm keen to get any early thoughts on this trade-off while we're all here.)

---

I'd like to end this with another shout out to everyone contributing to this discussion! Whilst I don't think tagging every visible member of the community to get their input is a sustainable pattern, it has definitely sparked some great feedback that has been brewing for a while. We'll continue watching this thread for further thoughts and ideas in these areas.

We can't make hard commitments to address many of the items raised here in the short term, but please take this as acknowledgement of them by the Silverstripe Ltd. team, and as a challenge to chip in where you can. It's important to recognise that Silverstripe CMS is an Open Source project with several orders of magnitude less commercial resources than competitors like Drupal and Wordpress. As the age-old adage goes: PRs welcome!

[Firesphere]

Some feedback on your comments @Cheddam :

TL;DR: I think with all the changes, the Product team has lost sight of what the actual devs using Silverstripe would like to see.

This doesn't preclude the introduction of experimental replacements for CMS features that are currently based on these technologies, but those experiments wouldn't be included in CMS Recipe 4.x releases. This does mean we'll continue to retain and accrue technical debt throughout the lifecycle

I beg to differ here. You are not "retaining technical debt", if you keep these features alive. These features are what made the Silverstripe CMS such a great way to start a new project. However, by removing them, you are introducing a massive migration path and technical debt for your end developers. I'm curious if this has been of any consideration? It seems the way you folks have chosen to go is "Remove any bit of technical debt, regardless of the people that use our product",

There will be some cases where we can't avoid this entirely (one example being the upcoming transition from GraphQL 3 to 4 - more detail coming early next year)

Isn't that then a new major release? Breaking things should not happen in minor releases, I think?

Using CMS components in front-end contexts

Whilst this pattern may have been usable in CMS 3, it's not something we have the capacity or inclination to support at this stage. Silverstripe CMS is shifting towards the 'Headless CMS' paradigm that many other projects have adopted in recent times, and whilst we have no plans to drop support for SSViewer, our focus is primarily on providing a solid CMS experience and exposing a powerful GraphQL API for projects to consume content through.

Although I agree and understand this is a target, it is excluding a large group of developers that "just want something". Headless is great, don't get me wrong, but far from every website would need something like a headless approach. It's pretty awesome and useful, actually. But when it comes to a plain website, no fancy mobile app etc., it's quite pointless. The previous use of CMS elements in the frontend, especially on forms, was super, because it required less work on the frontend to get things going.

It's worth noting that we have seen some success in re-use of the React components within the MFA module suite for producing a custom UI implementation, though these components are isolated from the rest of the core React suite.

Although the MFA Module is, in fact a module on its own, it is not something that developers of client website can turn to, to get help. It's still quite a complex beast. It is not a useful example on how to do things, I believe. There's nothing wrong with it in its functionality, but if you take it as an example, it immediately locks the user/developer inside the Silverstripe styling, and having to override that, adds quite some overhead.

As the age-old adage goes: PRs welcome!

That is the worst take, to me. A maintainer ending with "PR welcome", in my view, means "I can't be bothered to do this, but if you are willing to spend your time on it, go ahead", which, commonly, is followed by months and months and months of nothing happening (with either the PR or project progress regarding the comment). This is unrelated to the team, it's only a bit of a pet-peeve for me.

I have more comments, but it's also the weekend, so these are my main concerns :smile_cat:

[gorriecoe]

Well at this point I feel I'll chuck in my 2 cents. However valuable that is these days.

Tech stack

Personally I have always thought the choice to use react wasn't the best decision as it forced to write react ecosystem. I remember discussing with SS developers early on during a SS community meetup. Particularly about using react over vuejs and the only point of difference that react was built by facebook. Which wasn't a satifactory answer for me.
My main point of difference for using vuejs over react was its flexibility, particilarly in templating options. (Well described in this post)

Take the simple character counter next to a field example. Using vuejs inline templating with ssviewer you could simply update the FormField.ss to somethiing along the lines of the following.

<input $AttributesHTML('class') class="form-control $extraClass" <% include SilverStripe/Forms/AriaAttributes %> />

<small>Character count: {{ props.value.length }}</small>

The above is theoretically possible as I have done something similar on a recent project view-source:https://www.landcareresearch.co.nz/tools-and-resources/identification/what-is-this-bug/ (line 1020). I used a mix of ss and vuejs inline templating to apply filtering.

This approach could satisfy developers that need to create quick changes to UI for small projects and heck it would even work for react developers because you can initialize react components in vuejs.

On the note of creating a "community fork", the only fork I would like to see developed is a vuejs fork of silverstripe-admin. It makes sense when you look at alternative frameworks such as laravel which have multiple cms options available, both paid and community driven (It encourages healthy competition).

Laravel Mix

Laravel Mix has been mentioned in this thread, as an example of abstracting away the underlying tools for a simpler build tooling API. Our solution in this area has been the afore-mentioned @silverstripe/webpack-config

If it helps I had worked on a proof of concept for silverstripe-mix that could still work if @silverstripe/webpack-config exposes a few functions and data. If someone wants to take this further be my guest.

Dual-use front-end/CMS fields

I agree with everything @jonom has said on this point and add that regardless of framework, thought it was bad practice.

[unclecheese]

Hey, everyone. Good discussion. I'm going to weigh in a bit here.

No forking way

Can we just bury this idea of making a community fork? Look, I get the spirit of it -- it's an open source product and we're all afforded boundless opportunity to pilot it where we wish, but there's also a common obligation we have to the larger community to do what will provide the most benefit. The prospect of fragmenting the already incalculably scarce resources we have contributing to Silverstripe CMS seems like a recipe for failure, frustration and conflict to me. A community fork has some really depressing implications in my mind, including:

• A tangential, unpredictable release cycle
• Key core features and security patches never reaching some installations
• Opportunity cost of community contributions being used for stylistic and opinionated efforts

It seems to me if telling the core to get forked is the answer, we're probably asking the wrong question.

Over-Reactions

The increasing use of React in the UI has caused a lot of toil and frustration, and I think we all understand that, while and no one ever said it would be easy and painless, we also didn't think it would be this hard. However, I think there's some context missing around the genesis of that technical pathway.

This was decided many, many years ago, in 2015, when React really had yet to prove itself. It was a huge bet at the time, and we went with the best information we had, because we knew as well as anyone that you only really get one shot at this. It's years before you get a permission structure to do another massive change. I think it's fair to say that we grossly underestimated how difficult it would be to maintain Entwine and React in parallel, and also how much effort would be required to propagate React to the entire CMS. But with all that said, the questions around "why not Vue" and "did devs really want this" are kind of anachronistic. It's important we keep in mind the timeline of how this all played out, because it wasn't recent history.

It's easy to critique this decision with five years of hindsight and a vast amount of new information, but that same hindsight and information also gives us a lot of reason to praise that decision. React ended up being everything we thought it would be, and probably a lot more, and as some have pointed out, we've positioned ourselves very strategically for the future. Let's not lose sight of that.

Migrate(est) Weakness

Look, I think we're victims of our own success, here. The value proposition of Silverstripe CMS is basically that you can build out set of data models that closely align to your business requirements, you get a decent administrative UI with little effort, and customisation is done intuitively with PHP code and modules.

So while that is what people love about Silverstripe CMS (generally speaking), what people don't like about Silverstripe CMS (generally speaking) is that it's slow and lacks a modern UI.

These two conditions, in my mind, are at odds with each other, and we can't solve one without giving up some of the other. The way we're going to make the CMS faster and more modernised is through proven tooling (React/GraphQL) that we happen to already be invested in. It goes without saying that this makes extensibility much, much harder and admittedly less possible overall. There is no easy way to make this transition. We tried going halfway in to minimise the pain, but it's just made it more costly.

The future of customisation in Silverstripe CMS is probably going to be through javascript, and more specifically, through React. That's just something we're going to have to get comfortable with, and it's probably not productive to challenge those assumptions at this point given the relative value of actually figuring out how we're going to implement those assumptions.

There is no CMS that I'm aware of that runs in the client and also offers Silverstripe's level of customisation. There's a good reason for that. We're trying to bridge a massive gap that would be largely unprecedented, and it's not going to get done without some sacrifices to either side of that equation.

Upgraders of the Lost Ark

Upgrades are certainly difficult, and I can relate to all of the frustration around it, especially when trying to get clients to pay for it, but simple upgrades are also quite costly as well. A simple upgrade path hamstrings what we can do in the next release, making your clients less likely to want to pay for the upgrade. Additionally, codemod tools are extremely expensive to create and are far from perfect. Just to put that into perspective, if we skipped the upgrader tool for SS4 all together, and just said, "here's some docs.. you're on your own", we would have recovered enough dev weeks to do many of the other things of value in this thread, including, probably, rip out Entwine entirely. In my experience, most upgrades were done in the context of full site rebuilds anyway, so I'm a bit skeptical of the value of easy upgrading relative to its costs.

I think we had a golden age of customisation in Silverstripe that is probably coming to an end as the paradigms we benefitted from for so long are shifting away from us, and I think the discussion needs to be focused on how we're going to adapt to that rather than whether we should at all.

Change is hard, but we can do it. We got the damn thing to run on IIS, after all.

...we did, didn't we?

[wernerkrauss]

@unclecheese I'm so glad you (read: the team at Silverstripe) created the upgrading tool at Silverstripe. It helped me a lot upgrading different modules or projects and hopefully you keep it up to date with current changes.

I'm also no friend of a community fork and I'm not able to discuss vue vs react. I guess it's pretty much personal taste and both are pretty fine. In a recent discussion someone told me, they only used framework's ORM and file stuff but made their own cms/backend for a customer, cause it was so hard for them to get their UX wishes done with the current backend. Even this is possible, if you know how to do it.

As a PHP coder I had and still have a hard time with JavaScript, as it's not the same like PHP and sometimes behaves totally different. jQuery was cool. It saved me from "IE vs Firefox" hassles. Personally I took this also as a chance to level up (a bit) by reading e.g. the "You don't know JavaScript" books which explain very well how JS internally works. Some stuff is clearer now.

I wonder two things:

• How much of the react backend forms could be scaffolded from PHP code? Is there still a way to inject stuff to a data structure that gets rendered by the current backend? Focuspoint is such a pain point, where it was possible to set the focuspoint of an image relation in the DataObject. Currently you have to switch to FileAdmin to get the focuspoint set, which is pretty unhandy when you just uploaded the image to that DataObject.
• is it possible to have one form field doing stuff in backend with react and in frontend with a custom rendering (e.g. vue or alpine.js)? A good set of fields that still work in frontend with the preferred js would be a dream. Maybe the core functionality could be encapsulated in js-framework agnostic objects? I dunno if that's possible and practicable.

In the end I guess it's something each of us has to live with. Many people didn't like namespacing, but we got used to it. What I've seen in the last years is, that most decicions by Silverstripe first disrupted the way I used to work (e.g. composer instead of change-code-in-a-module-and-ftp) but made me become a better developer. So I assume that you had good reasons and will help us other developers find our ways to level up.

[unclecheese]

Many people didn't like namespacing, but we got used to it.

^ 💯.. this is it, right here. Usually my go-to point to illustrate why Silverstripe OSS is the way it is. We were six or seven years late to the party on namespacing. Many thought it was crazy that SS 3.0 didn't come with namespacing in 2011. It's hard to be bullish on the future when you need to keep one foot five years in the past to keep everyone happy. Our community is a very diverse coalition in that sense, and it speaks to our unique set of challenges.

A React of War

Just want to add a bit more context here about the battles we've had with React. When Silverstripe developers make the statement "React is hard/confusing/too much code", it's important to distinguish between React is hard and React in Silverstripe CMS is hard. These are very different things.

Why is React so hard in Silverstripe CMS?

When we brought on board a new frontend technology, we also brought along all of its furnishings, accessories, and implicit dependencies. We needed a build chain, a state manager, tasks, node_modules folders, etc. These are all build time tools. Client side customisations generally happen at build time. Backend customisations, like what we're used to, happen at runtime.

The easiest way to make the React layer intuitively customisable was to add a build time API, but this was immediately considered a non-starter, because we would be adding Node as an implicit dependency of the CMS, and at the time, a significant number of devs still weren't using build tools, particularly backend devs who just wanted to add a new form field.

So with that ruled out, we had to create a bespoke DI layer the likes of which we hadn't really seen anywhere before. It's probably overengineered, but the idea was that we need to make the React layer as customisable at runtime as the backend was. That added lots, and lots of complexity.

This idea of runtime customisation of Javascript relies on some really dodgy hacks and escape hatches, including pollution of the global namespace. It's analogous to SS4 coming out with full namespacing support, but having a giant PHP file that applies class_alias to everything for backward compatibility.

Will it always be this hard?

Almost certainly not! If we can get over the hump of making builds a requirement for running the CMS, it's quite a game-changer. It doesn't solve all of our problems, but things get a lot more intuitive!

I'm wondering if it's worth discussing, perhaps in a separate thread, how we envision that best working, because as stated above, I don't think it's productive to think beyond the boundaries of React being here for the long haul.

One option might be, for instance, that the admin is blank by default, until you design an app.js bootstrap.

<CMS endpoint='/graphql'>
  <LeftMenu showHelp={false} />
  <SiteTree maxTreeNodes={5} />
  <EditView ... />
</CMS>

Customisation then becomes much more transparent and intuitive, because the DI is happening in the build chain.

{
  inject: {
    LeftMenu: "my-app/src/components/LeftMenu"
  }
}

This discussion leads down a rabbit hole, and barely scratches the surface, but hopefully it's enough that you get what I mean.

[micschk]

First of all, I'd like to stress that any points in this discussion from my end are meant as constructive. I've been a fan and dedicated Silverstripe dev from since around version 2.2 on. The (core) devs & company have enabled me to build up a small but steady development shop providing a livelihood over the years.

Though I found @unclecheese's headers amusing, and they probably were meant as just that, I feel they may give a harsh tone to the discussion I didn't intend for it (eg no f*ing way, depressing, overreacting, weakness, reaction of war).

That being said, I see a few aspects being interwoven in this discussion.
I think they could be discussed more clearly when isolated, which I'll try below;

Headless CMS

From the Silverstripe ‘Future of Content Delivery’ and ‘Headless CMS with SilverStripe’ whitepapers (emphasis mine):

When we talk about a Headless CMS, the headlessness is referring to the frontend display channel being separated from the content management backend.

In my opinion (confirmed by the whitepapers), the main point of headless/decoupled is that this allows the distribution of content to various independent frontends. An example of how I understand such a system is a setup we've built for one client where they manage the content of their website as well as (partially overlapping) content for various print-publications (via PDF), online elearnings, and for multiple external distribution platforms, all from within their CMS. Except for the website, all other distribution channels are 'decoupled' and distributed/rendered/synchronized via various mechanisms (XML, JSON/REST, PDFs, all built without much problems in SS3 by the way).

I think it is important to make a distinction between decoupled frontends (makes a lot of sense) and the actual CMS itself being decoupled (of which I find it harder to see/find a practical purpose other than replacing the CMS (which of course no one would want to do)).

I imagine that in the spirit of eating your own dogfood, decoupling the CMS itself made/makes sense as a practical application of this envisioned USP. But my honest concern is that Silverstripe is heading in a direction where a lot of 'infinitely smaller capacity' gets stretched even more because decoupling the CMS has become a prestige/purpose in and on itself instead of a means to enable rapid development(?)

Besides that, it seems the whole point of going headless is about a gain of speed and flexibility on the frontend. For me and most if not all editors I have ever worked with, it's perfectly acceptable for a CMS page loading/saving to take 500 or even 1000ms, as you are operating a tool/performing a task (less so for the frontend to load in say a second, as that costs visitors). If the same CMS page now loads headless, renders and saves in 100ms via React that's nice.

But if this means it has taken and will continue to take a lot of scarce core-dev capacity, and on top of that results in costing me as developer a lot more time and effort to make the optimizations & develop specific functionality that's actually of added value to the specific organization, what have we actually won? Couldn't we instead have better focused on other strengths that make/made Silverstripe Silverstripe and set it apart (like simplicity for developers to develop quality code & value in customisations)?

And as headless imo makes a lot of sense in the frontend, maybe we should think of some practical examples to illustrate its applicability? Maybe even some part in the default theme could demo this concept, or an API frontend base module or so?

GraphQL

I think the introduction of GraphQL on itself makes a lot of sense. I've found myself working around limitations in REST/form submissions being in principle 'scoped' to a single object on more than one occasion. This seems to me a prime example of a 'problem' which could be solved by leveraging GraphQL.

React & components

(Will have to get back on this point in another post)

Dual-use of form fields

I don't get why this would be considered bad practice? What I usually do is say I have an object containing a 'Name' textfield, this field gets scaffolded and loaded in the CMS nicely. And I use the same scaffolded field maybe with some customisations via frontendFields, for use in the front-end (along with validation etc via the form controller or object).

This way, the scaffolded CMS/ModelAdmin often exists a kind of 'admin' interface and it saves me from having to duplicate common functionality for back & frontend. How would this be bad practice? (honest question)

Upgrading [CLOSED]

I actually haven't run into much problems with updates through the years and really appreciate the upgrader tool. The reason I mentioned this was because we got bit by the interface's graduate switching to React which caused us to have to refine a recent update. Only then did it occur to me that this could be an ongoing issue (meaning we cannot keep using the jQuery/Entwine patchwork we've been getting away with most of the time).

Forking 'core' [CLOSED]

This was never a serious consideration, more meant to illustrate the point that this idea almost feels more attractive then having to go through updates for some giant projects with can simply not be 'rebuilt'.

[unclecheese]

Though I found @unclecheese's headers amusing, and they probably were meant as just that,

Yeah, it's a long, intense thread, and I was just trying to lighten things up a bit. 😉

Besides that, it seems the whole point of going headless is about a gain of speed and flexibility on the frontend.

I'm not sure this is fully accurate. It's kind of conflating two different things, in my mind. Modernising the UI may have the side-effect of making the CMS faster (and it probably should), but they're not one-in-the-same.

When we talk about modernising the UI, think about something like customising the behaviour of the site tree. If you had a client who needed the site tree to do something special, your only option is to choke down a cocktail of jQuery, Entwine, and Pjax, and in all likelihood, you're just not going to do it. No one wants to do that. If someone requested a new client-side feature for sitetree in CMS, it's just not going to get worked on. It's too hard, and it's too likely to break other things.

Plus, let's keep in mind, it's not just form submissions. It's the site tree, it's modeladmins with multiple nested gridfields, autocomplete fields, etc. Those things are all really slow, and those > 1000ms interactions really get compounded over a typical user session.

But the value proposition of React isn't just that it's fast. That's part of it, but it's more that it makes architecting UIs so much easier and predictable. Granted, as said before, the current implementation of React in Silverstripe CMS is not easy to work on, and there are a number of reasons for that, but it won't necessarily always be that way.

I do wonder, in the interest of staying on the topic of modernising the UI, if we're better off focusing on what a really extensible and easy-to-work-on implementation of React / GraphQL in the CMS would look like. I'm not saying there isn't a case for questioning React/GraphQL at this point, but given how heavily we're invested in it, and that they are proven ways to modernise a UI, I think it's a pretty high bar.

[jonom]

One option might be, for instance, that the admin is blank by default, until you design an app.js bootstrap.

@unclecheese I've thought a number of times that I would love to have the flexibility to build my own CMS in this way. The CMS ships with a few distinctive (although similar) interfaces - Pages, Files, Campaigns (?), and for everything else it's basically Model Admin and/or some variant of GridField / CRUD capabilities.

I know it's possible to sub-class LeftAndMain but I don't see that done a lot (your Dashboard example comes to mind), and it seems like you're kind of on your own if you do that - the admin module doesn't ship with components or patterns (AFAIK) to make it easy to build a great UX for something that falls outside of the GridField / CRUD rows-of-objects pattern.

I've often felt that I can build anything my clients ask for (within reason) in their consumer-facing web app (powered by Silverstripe on the back-end). Where I stumble and find myself making excuses is when clients ask for a custom behaviour or interface or workflow within the CMS. So while I realise it wouldn't be great for everyone, building a 100% React CMS from à la carte components would be a dream come true for me.

I think it is important to make a distinction between decoupled frontends (makes a lot of sense) and the actual CMS itself being decoupled (of which I find it harder to see/find a practical purpose other than replacing the CMS (which of course no one would want to do))

@micschk I don't think the CMS is being decoupled.. it's kind of impossible, as you pointed out. The new parts of the CMS may talk to the back-end in a different way (e.g. GraphQL) but that doesn't mean they're any less coupled together.

it seems the whole point of going headless is about a gain of speed and flexibility on the frontend.

@micschk Sorry if I'm misreading you - but it seems like you're seeing the concept of a headless CMS and the choice to adopt React and GraphQL (and the associated CMS customisation pain) as tied to one another. But SS3 was already a capable headless CMS, because all a CMS really needs to do to be 'headless' is provide an API to access it's content. I've used SS3 headless before by just spitting out json as necessary.

You also don't need to use GraphQL to use React - SS4 didn't have to use GraphQL but is an emerging standard and great to have in place, and gives us a consistent spec to work to.

So I don't see the complexities of CMS customisation in SS4 as a byproduct of the goal of making Silverstripe 'headless'. I think React was chosen because it's a wonderful tool for creating rich user experiences, and puts the CMS in place to create UXs that would have been a nightmare to piece together in SS3.

the most valuable USP of Silverstripe used to be its simplicity & extensibility - being able to add simple custom functionality easily, also within the admin area with stuff like betterbuttons.

I think this is true, with emphasis on simple. If all you want to do with SilverStripe (in the CMS) is create fancy text fields or display static information, which is all that my CMS modules ever did, that was really easy, because the scope you were working within was so small - usually a single field. If you wanted to make deeper or more fundamental changes that could be really hard, and ultimately not worth it (no one wants to override a huge javascript file with their own and patch it every time an update comes out). I'm hoping that adopting React makes it possible to build out really complex interfaces (and ideally - be able to build these for the most part from components that ship with Silverstripe).

CMS3 was for the most part a server side rendered app which is really limiting in terms of UX possibilities and perceived performance. Adopting React has made it harder to do basic customisations, but as others have said I think it was necessary to allow the CMS to continue to evolve and enable richer content management possibilities.

---

Edit: @unclecheese bet me to the 'Comment' button, sorry for repeating some of his points 😄 Edit 2:

I'm hoping that adopting React makes it possible to build out really complex interfaces (and ideally - be able to build these for the most part from components that ship with Silverstripe)

Sanity UI just dropped and could provide a good reference point or even a partial drop-in solution for this.

[jonom]

I do wonder, in the interest of staying on the topic of modernising the UI, if we're better off focusing on what a really extensible and easy-to-work-on implementation of React / GraphQL in the CMS would look like.

Could the CMS ship pre-built, with certain component hooks available, plus the ability to swap in custom components, as a way to enable those simple field-level customisations we were used to in SS3?

Then for the devs who want to take it further, you could create your own app.js and take on the build steps?

[jonom]

Not to add fuel to the fire, but the History Viewer appears to be a good example of a new piece of functionality that looks to be complex to the point of being impractical to use in your own projects. I would have thought the most that would be required there would be to add some yml config, but you need to create a bunch of custom files and add a webpack build step to your project before you can add History Viewer to your own classes (that's how it seems from the docs anyway - I haven't tried this for myself).

Is this the kind of thing that would be much easier to use if there was a Node build step, @unclecheese? And, could the Node requirement potentially be dev-only, with built files going in to your code repository, to avoid needing Node in your production hosting environment?

[unclecheese]

Yup, great example, @jonom ... Nothing exposed this better than the versioned-snapshot-admin module, where we needed basically the same UI, with a few tweaks and a different data source. Ended up just clobbering every single component in Injector.

There is just so, so much complexity to doing dynamic graphql queries. It's very hard to work with. Building that module exposed a lot of the yet unsolved challenges we're going to be facing.

[sunnysideup]

Is the crux of the issue that js does not know about PHP model / config / settings ?

Could we do what we did between MySQL and PHP to create that 1-2-1 connection ?

On Tue, 15 Dec 2020, 10:00 am Aaron Carlino, notifications@github.com wrote:

Yup, great example, @jonom https://github.com/jonom ... Nothing exposed this better than the versioned-snapshot-admin https://github.com/silverstripe/versioned-snapshot-admin module, where we needed basically the same UI, with a few tweaks and a different data source. Ended up just clobbering every single component in Injector.

There is just so, so much complexity to doing dynamic graphql queries. It's very hard to work with. Building that module exposed a lot of the yet unsolved challenges we're going to be facing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silverstripe/silverstripe-framework/issues/6689#issuecomment-744707271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABIZ4Q6SNJA6QBYKTNPIJTSUZ4GJANCNFSM4DC57KFA .

[chillu]

Wow, what a read - thank you for raising this @micschk! Most of the discussion happened while I was on leave, hence the radio silence. I think Garion and Aaron have summarised our current position pretty well :) Accordingly, I'll try to stick to relatively highlevel comments to illustrate why we ended up where we are.

My view is that through prioritising (relatively) fast shipping, we've managed to get the CMS 4.x "big bang release" into the hands of users and developers years earlier than if we had prioritised a clean rebuild. Along the way, the main contributors gathered a lot of experience with how to build CMS UIs on modern stacks. But it has come at a cost of complexity during a transition phase that's much longer than anyone expected, and reduced the ability of the wider community to contribute. That being said: Modern web applications aren't easy to build, especially with the shackles of backward compatibility across an API surface of 10k+ symbols in our PHP code, and thousands of projects where customers are relying on their often substantial investments into Silverstripe to last them a few years.

There are fundamental challenges in retaining a PHP-centric customisation approach (getCMSFields with a bit of Entwine and CSS mixed in), while maintaining an ever more complex UI and customer expectations around how a modern web application should behave. The runtime React injection and dynamic GraphQL queries which Aaron highlighted are early manifestations of this, and in my view the main reason we've lost momentum (figuring out React GridField broke the minds of Damian, Aaron and Ingo alike).

There is definitely friction between a backend-centric developer community and a frontend-centric CMS UI approach, but I don't believe the answer is to build a CMS application like we build static websites with a dynamic component here and there. Or rather, if we wanted to build it that way, I believe we would need to redesign the CMS UI to be more simple and page centric (full page loads like Drupal). I've formed this view by spending quite likely hundreds of hours dealing with state management bugs between the tree view, breadcrumbs, form data, publish button states, etc ;)

As Sam said in his StripeCon EU talk from Oct 2020, we can't move the monolith forward in a single step every five years, it's just too risky and doesn't serve either developers or users well. Over the next year, the trick will be tactical changes to the 4.x core (modularisation, decoupling via APIs) which then allow innovation to happen in modules which you can opt-in, or we can bundle into new defaults for new projects without an upgrade path. The versioned-snapshot-admin module is a (messy) example of this direction. Given where we are right now, and the limited resources we can devote to innovation on top of preserving what we have (for everyone's benefit on this thread), I don't expect this to be a fast process.

[Firesphere]

figuring out React GridField broke the minds of Damian, Aaron and Ingo alike

Nothing like talking about yourself in third person, ey @chillu ? :laughing:

[lekoala]

When reading @chillu comments, I'm thinking that allowing "opt-in" changes is better than forcing a specific way of doing things. As far as I understand, jquery and entwine are not going away in SilverStripe 4.x (maybe in 5.x with bootstrap 5?). This means that for the time being, it should be properly supported. I still don't get why we are running a old version of jQuery and a version of entwine that rely on $.browser to exist. It's probably a minor effort to upgrade, compared to the amount of work that has been put into react.

I get that the idea is to push the community to NOT use these tools anymore (although, as I discovered in the recent 4.7, that's keeps happening because there was some changes in how validation errors are displayed in tabs using entwine... well maybe because it's a lot easier to do it that way). However, I feel that maybe it's possible to keep both approaches and everyone happy : react based components AND jquery/entwine for those that just want to bind a couple of event listeners. It feels like overkill to use react for these situations and I do enjoy, as a php developper, to simply add a plain js file to be loaded by leftAndMain.

[sunnysideup]

figuring out React GridField broke the minds of Damian, Aaron and Ingo alike

All of these people are super smart, but I wonder in all of that brain power something was lost. We have a great CMS here, but the smartest people working on the CMS can not create a list of editable records (basically the core of the CMS, together with the SiteTree and HTML Editor). This raises serious concerns about the approach and the whole project.

To me this idea of having half the CMS in React and the other half in jQuery and Entwine is fundamentally flawed. Surely, by itself making an editable list in React has been done before and should not be hard (if this is hard then React is not what it is supposed to be).

Is this one of those situations where, in hindsight, starting from scratch would have been much easier and faster? Can we still do that (copying across what works).

[ScopeyNZ]

making an editable list in React has been done before and should not be hard (if this is hard then React is not what it is supposed to be).

The complexity is not around how to make the React component, it's around how to build it in such a way where you don't lose the configurability of the PHP APIs for GridField while retaining the benefits of a React powered UI.

We've been through the process of making getCMSFields work with React (FormBuilderLoader), but we've still got work to do on that - let alone come up with a React API that works for GridField.

[sunnysideup]

Ok - so the hard part is that devs configure in PHP and that, like for like, React needs to know about that? I wonder if there would be value in a closer mapping of PHP config / models setup and React components, or is exactly trying to do this that causes all the headaches?

[Cheddam]

In short, yes. The complexity of this mapping increases with the complexity of the field / component it's trying to drive - which is part of why GridField is so difficult to port, with its massive API surface. A pared-back version would be more achievable, but would lose a lot of the flexibility developers appreciate it for (and would impact the roll out across core, modules, and projects that make use of the missing parts.)

[christopherdarling]

I know there are probably a few forbidden words here.... but has anyone taken the time to take a look at how Advanced Custom Fields Pro handles Wordpress + Gutenberg? They allow Gutenberg blocks that typically are React (I think) can be created through very simple PHP code...

[unclecheese]

It's been ages since I looked at that module, but from what I remember, it's a very denormalised schema. They basically have page_id | field_name | field_value and call it a day.

@chillu and I were actually chatting about this today. Maybe the path forward is to admit defeat and just accept that our implementation of graphql will be denormalised (it already is in Elemental Editor). 🤷‍♂️

[christopherdarling]

from what I remember, it's a very denormalised schema.

You're right there. It's a long time since I worked on a WP project and as much as the schema is a pain and I prefer Silverstripe's ORM, the editing experience of Gutenberg is pretty impressive.

edit: just wanted to add, I hope all of this discussion doesn't feel too negative or that the community isn't appreciative of all the work that SS put into the project. I do love the CMS and just hope that the input here helps.

[davejtoews]

Maybe the path forward is to admit defeat and just accept that our implementation of graphql will be denormalised (it already is in Elemental Editor).

I sure hope not. The ORM and DB structure in SilverStripe are some of my favourite things about it.

It's a long time since I worked on a WP project and as much as the schema is a pain and I prefer Silverstripe's ORM, the editing experience of Gutenberg is pretty impressive.

We still do some WordPress work at our shop, and we usually disable Gutenberg. It just doesn't work if you wan't any sort of relational, or shared data. Just a very slick rich text editor you're meant to dump a whole page's content into. Even though the db schema is still bad, at least custom fields allow some structure and relationships on your fields. You can build a faux ORM around custom fields and custom post types and still build something rather complex. We've built an internal toolset to allow us to create something like Elemental blocks, and it deliberately avoids using Gutenberg.

I see the appeal to Gutenberg for light brochurewear or blogs with minimal involvement from devs, but I see my job as delivering something more robust than that and that's why if given a choice I'm going to choose a platform like SilverStripe to do it.

[Zauberfisch]

A bit late to the party, but I felt that all the complaints I would come up with have already been voiced.

However, I've now trying to migrating my existing modules to the new react stack and within the first minute found 2 "major" bugs that basically make module development impossible for any but the most seasoned SilverStripe developers (or am I just really bad at this or have a edgecase setup?)

https://github.com/silverstripe/vendor-plugin/issues/34 https://github.com/silverstripe/silverstripe-module/issues/35

If the mechanics for developing a module and the module starter template (skeleton) are both not working out of the box, we can kiss a healthy module eco-system goodby. On top of that, we of course have the age old problem of lacking documentation. For the most part I have not worked with the "new" react stack yet. Reading the docs now, I feel like they provide a decent overview, but only limited guidance of how to actually build something.

The skeleton idea is great and definitely needed. But I think we need to make absolutely sure that things like that are well maintained and actually work.

[sunnysideup]

A bit off-topic, but perhaps relevant:

@unclecheese at al. - you may look at this: https://github.com/sunnysideup/silverstripe-sswebpack_engine_only. This is a standard webpack that, in theory, could run with any module. I have used it successfully on a number of client projects and it works really well for us.

In practice, rather than maintaining a ton of webpack installations, we just use one standard webpack install that can be used to compile any silverstripe project, while still allowing for any npm libraries to be included.

[micschk]

React & components (Will have to get back on this point in another post)

Today would be a good day for this... This past week I've (amongst other things) struggled with trying to make two community modules work in SS4; my own cropping addon to focuspoint, and the Shortcodable module. Shouldn't be very difficult I figured, those guys said React isn't too hard... Oh well.

Shortcodable So far, a few devs have made attempts ad upgrading this module but no one actually really succeeded and now a module we used in practically all our sites has basically been abandoned because it isn't working with the (spaghetti) React rendered TinyMCE anymore.

FocusPointCropper This used to bolt onto Jonoms FocusPoint module, which has now been updated to React (and turned from 2 PHP files and one JS file, to 4 PHP files and 4 JS files). I have been contemplating how to bolt onto this react rendered interface, or wether it might be possible to workaround React... After all I basically just want to add an extra field to hold the crop data, initiate cropperjs (which is plain JS anyway) & update the field data on change. I'd hate to have to learn React just to do such a simple thing which should be possible in a few lines of code. Oh but React uses a special kind of DOM, which you cannot actually use methods on like listening for changes (from outside React).

OK, so back to Shortcodable then Maybe that's simpler to set an 'old fashioned' onclick listener on and open a modal/dialog (again, should take like 10-20 lines of code?). Finally, at least something succeeded. But the dialog Silverstripe uses is not the regular TinyMCE dialog and I like to blend in. So, let's see how another button opens this nice Silverstripe dialog, maybe something simple like the 'Insert media from URL', this one:

One button, one dialog with one input and one button. Even I should be able to get that going...

Turns out this seemingly tiny & simple bit of functionality involves:

• 388 lines of PHP to generate the form (and probably some other GraphQL stuff)
• 374 lines of JS, React and... Entwine (HA!) (for the button and to insert/open the dialog)
• 199 lines of JS/React to render this specific embed modal/dialog
• and another 231 lines of JS/React to render the base modal/dialog

Since in the old days almost everything was better, I couldn't resist comparing this to the SS3 era code. Alas there was no embed button 'back then' so I looked at the 'insert link' button:

• one PHP file of which about 75 lines of code define the form (with a lot more fields btw)
• 137 lines of JS inserting not one but two buttons and opening a modal when one of them get clicked
• one JS file for the whole editor, with a lot of lines of which about 50-100 lines(?) for making the link dialog work

So less lines of code is better? My point is that the current way the UI functionality is build may be 'modern', but highly involved and I think pretty much inaccessible (or at the very least unfeasible) for a large section of developers & companies working with Silverstripe. As versatile Silverstripe is at the PHP layer, so shrink-wrapped is it becoming on the JS level.

I feel Silverstripe has spent the past ~5 years rebuilding the framework & CMS in a more modern way and now it seems to be at a point where it's feature wise basically comparable to the last SS3 versions(?) Just built in a much, much more complex way.

I'm actually sad. After this week it has become painstakingly obvious to me that this is not a viable route for me to follow Silverstripe on. We've already started creating most UIs outside the admin in Silverstripe 4 while we used to be able to create a lot of value for clients even just inside the modeladmin in Silverstripe 3. But it's become way too involved to create systems that way in SS4. And way too complex in case you ever need something non-standard or need to tweak/customise some functionality (which I'd even consider a risk business wise).

It makes me wonder though, on what's your (Silverstripe the company) view on the future of Silverstripe framework & community? If you now know how much time & effort has been poured into all these injectable, stateless, componetizable, containerizable, GraphQL/React complexity, is it worth it? And are you aware of what it's gained (or cost) you outside of the technology (community, involvement)?

When re-reading this thread I came across the perceived benefits as initially described by Sam;

CMS Authors: Faster UX

Yes, the CMS has become (slightly) faster (but files still show 'DRAFT' after publishing the $owner)

easier addition of modern approaches such as offline support, background refreshes (web sockets)

Maybe... Some day?

Community Developers: Reuse existing frontend knowledge for CMS customisations

Definitely not (at least for me)

Product developers: Faster turnaround for new UIs

Also not really I think (or did you mean Silverstripe internally, and even then not really, eg versioned-snapshot-admin?)

Product designers: More consistency and collaboration through component-based implementations (pattern library)

Hmyeah OK, but that's not really a brought on by the technology I think?

[spekulatius]

Hey @micschk,

Thanks for taking the time to put your thoughts and feelings into writing. As you know, you aren't alone with many of the points raised. If you (like myself) feel more comfy on the PHP-side and are put off by React, you should check out the webcasts for Laravel Livewire. It's not SilverStripe or even a CMS, but it is bringing many of the easy ways to do things back. It sparked the "oh wow, that's so easy" feeling I had with SS3.

Cheers, Peter